From pspacek at redhat.com Mon May 2 07:41:38 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 2 May 2016 09:41:38 +0200 Subject: [Freeipa-devel] [PATCH] Updated ipa command man page In-Reply-To: <57233E12.7000706@redhat.com> References: <57233E12.7000706@redhat.com> Message-ID: <60897f6b-7783-201d-6893-ee9bd3821c7f@redhat.com> On 29.4.2016 12:57, Abhijeet Kasurde wrote: > Hi All, > > Please review this patch. LGTM -- Petr^2 Spacek From akasurde at redhat.com Mon May 2 10:43:53 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 2 May 2016 16:13:53 +0530 Subject: [Freeipa-devel] [PATCH] Fix added to ipa-compat-manage command line help Message-ID: <57272F69.9050001@redhat.com> Hi All, Please review this patch. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0011-Fix-added-to-ipa-compat-manage-command-line-help.patch Type: text/x-patch Size: 1806 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 2 12:20:49 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 May 2016 14:20:49 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: <571DFF1D.9060607@redhat.com> References: <571DFF1D.9060607@redhat.com> Message-ID: <9ca226ac-c2a2-3ef6-8f8a-ac61bd4d4c42@redhat.com> On 04/25/2016 01:27 PM, Martin Babinsky wrote: > Hi list, > > this is my review of the > http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 design > page authored by Petr Vobornik. > > Overall the page needs some more polishing, there is a number of TODOs > and typos which need to be expanded/fixed. Todos were replaced. > > Here are some more specific points: > > 1.) there is a lengthy discussion about the interface and behavior of > server-del API command on this list.[1] The server_del description > should be updated to reflect the conclusion reached by this discussion. done > > 2.) we should also put more thought into actions which should be > performed by `server-del` regarding cleanup of leftover references to > replica's ldap/ and HTTP/ principals and DNS records. > > The thing is that the original code assumes that the cleanup is > performed under admin/Directory Manager credentials, while we should > assume that most of these tasks should be doable by host itself (see > server uninstall use-case). I shall make some more research into this. add a mention about ACIs and why it is need to contact different master from the installer. > > 3.) I would rewrite Topology graph section in Feature management because > the current text is not very readable. Also is there a plan to show > roles of an IPA master when clicking on it on the graph or is it a > stretch for 4.4? The unreadable part is reasoning. Proposal is in summary. Added a note that roles wont' be shown in topology graph in 4.4. > > [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00101.html > -- Petr Vobornik From dkupka at redhat.com Mon May 2 12:28:39 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 2 May 2016 14:28:39 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). Message-ID: https://fedorahosted.org/freeipa/ticket/2795 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0100.0-pwpolicy-Do-not-expire-passwords-when-maxlife-is-set.patch Type: text/x-patch Size: 2120 bytes Desc: not available URL: From dkupka at redhat.com Mon May 2 13:35:00 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 2 May 2016 15:35:00 +0200 Subject: [Freeipa-devel] MIT KRB5 uses 32bit time stamp Message-ID: <9c1d3858-b4ad-5524-28c7-9ee48e9fea5a@redhat.com> Hello! Recently I have touched password expiration code in ipa_kdb_password.c and noticed that we have IPAPW_END_OF_TIME set to January 1st, 2038. I thought that it's just old code that still assumes 32bit time stamp and that Kerberos surely moved to 64bit long time ago. I was really surprised when I opened /usr/include/krb5/krb5.h and found: > typedef krb5_int32 krb5_timestamp; Is there a reason why not just replace the line above with: > typedef krb5_int64 krb5_timestamp; ? I know that it may seem that we have plenty of time to address it but I don't see a reason to wait. -- David Kupka From mrogers at redhat.com Mon May 2 14:06:04 2016 From: mrogers at redhat.com (Matt Rogers) Date: Mon, 2 May 2016 10:06:04 -0400 Subject: [Freeipa-devel] MIT KRB5 uses 32bit time stamp In-Reply-To: <9c1d3858-b4ad-5524-28c7-9ee48e9fea5a@redhat.com> References: <9c1d3858-b4ad-5524-28c7-9ee48e9fea5a@redhat.com> Message-ID: <20160502140604.GA17290@mail.redhat.com> On 05/02, David Kupka wrote: > Hello! > > Recently I have touched password expiration code in ipa_kdb_password.c and > noticed that we have IPAPW_END_OF_TIME set to January 1st, 2038. I thought > that it's just old code that still assumes 32bit time stamp and that > Kerberos surely moved to 64bit long time ago. > I was really surprised when I opened /usr/include/krb5/krb5.h and found: > >typedef krb5_int32 krb5_timestamp; > > Is there a reason why not just replace the line above with: > > typedef krb5_int64 krb5_timestamp; ? > > I know that it may seem that we have plenty of time to address it but I > don't see a reason to wait. > There are some plans for addressing this upstream: http://mailman.mit.edu/pipermail/krbdev/2014-December/012239.html > -- > 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 -- Matt Rogers Red Hat, Inc From mbasti at redhat.com Mon May 2 14:26:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 May 2016 16:26:39 +0200 Subject: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure Message-ID: <5727639F.1030108@redhat.com> https://fedorahosted.org/freeipa/ticket/5820 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0471-ipactl-advertise-ignore-service-failure-option.patch Type: text/x-patch Size: 1936 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 2 15:19:30 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 May 2016 17:19:30 +0200 Subject: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure In-Reply-To: <5727639F.1030108@redhat.com> References: <5727639F.1030108@redhat.com> Message-ID: On 05/02/2016 04:26 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5820 > > Patch attached. > > Copying the err message 3 times is not very nice. It should be in a constant otherwise we risk that they will get out of sync in a future. -- Petr Vobornik From mbasti at redhat.com Mon May 2 15:27:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 May 2016 17:27:03 +0200 Subject: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure In-Reply-To: References: <5727639F.1030108@redhat.com> Message-ID: <572771C7.7000203@redhat.com> On 02.05.2016 17:19, Petr Vobornik wrote: > On 05/02/2016 04:26 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5820 >> >> Patch attached. >> >> > Copying the err message 3 times is not very nice. It should be in a > constant otherwise we risk that they will get out of sync in a future. Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0471.2-ipactl-advertise-ignore-service-failure-option.patch Type: text/x-patch Size: 1875 bytes Desc: not available URL: From sbose at redhat.com Mon May 2 15:30:33 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 2 May 2016 17:30:33 +0200 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160428185807.GC19396@mail.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> <20160428185807.GC19396@mail.redhat.com> Message-ID: <20160502153033.GI7796@p.redhat.com> On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote: > On 04/27, Matt Rogers wrote: > > On 04/27, Sumit Bose wrote: > > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > > > > On 04/26, Sumit Bose wrote: > > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Nathaniel McCallum" > > > > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > > > > enhancements, > > > > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > > > > there hurts readability. > > > > > > > > > > > > > Sure, I've attached the revised patch. > > > > > > > > > > Hi Matt, > > > > > > > > > > thank you for the patch. Currently I have the following question. > > > > > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > > > > calling ipadb_get_ldap_mod_extra_data() > > > > > > > > > > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > > > + if (kerr) { > > > > > > + goto done; > > > > > > + } > > > > > > + > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > > > entry->tl_data, > > > > > > mod_op); > > > > > > > > > > > > > > > > Why it is needed to filter this data again in > > > > > ipadb_get_ldap_mod_extra_data()? > > > > > > > > > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > > > > believe I left there in error - We decided to operate on a filtered copy > > > > of the tl_data (which filter_authind_str_attrs() handles) rather than > > > > removing it completely with krb5_dbe_set_string(). I had tested with the > > > > above code commented out but forgot to remove it with the submitted patch. > > > > > > ok, makes sense. > > > > > > Nevertheless, comments in kdb.h like: > > > > > > /* String attributes (currently stored inside tl-data) map C string keys to > > > * values. They can be set via kadmin and consumed by KDC plugins. */ > > > > > > and > > > > > > /* String attributes may not always be represented in tl-data. kadmin clients > > > * must use the get_strings and set_string RPCs. */ > > > > > > make me wonder if it is a good idea to operate on the tl-data of type > > > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well > > > so I'm not insisting to change it, I'm just wondering about the reasons. > > > > > > Would something like (error checks are missing) > > > > > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", > > > &require_auth_str); > > > > > > if (require_auth_str != NULL) { > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > } > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > entry->tl_data, > > > mod_op); > > > > > > if (require_auth_str != NULL) { > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", > > > require_auth_str); > > > } > > > > > > have the same effect with only using the recommended API (and making the > > > patch smaller)? > > > > > > > I believe that would be the same effect, just less efficient. But > > sticking to the API is probably safer in the long run. I am okay > > with changing it if you would prefer. > > > > Here's the updated patch. Thanks again for the review! Hi Matt, thank you for the new version. I played with/tested the patch with 'ipa user-mod', ldapsearch, ldapmodify and kadmin.local and all was working as expected. I only found a minor issue: > @@ -1428,6 +1512,7 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, > { > krb5_error_code kerr; > krb5_tl_data *data; > + krb5_tl_data *data_tmp = NULL; this is unused. Coverity didn't found anything else as well. Since Simo already added the new OID to https://code.engineering.redhat.com/gerrit/p/rhanana.git, ACK, if you remove data_tmp. bye, Sumit From mrogers at redhat.com Mon May 2 15:47:41 2016 From: mrogers at redhat.com (Matt Rogers) Date: Mon, 2 May 2016 11:47:41 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160502153033.GI7796@p.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> <20160428185807.GC19396@mail.redhat.com> <20160502153033.GI7796@p.redhat.com> Message-ID: <20160502154741.GC17290@mail.redhat.com> On 05/02, Sumit Bose wrote: > On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote: > > On 04/27, Matt Rogers wrote: > > > On 04/27, Sumit Bose wrote: > > > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > > > > > On 04/26, Sumit Bose wrote: > > > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Nathaniel McCallum" > > > > > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > > > > > enhancements, > > > > > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > > > > > there hurts readability. > > > > > > > > > > > > > > > Sure, I've attached the revised patch. > > > > > > > > > > > > Hi Matt, > > > > > > > > > > > > thank you for the patch. Currently I have the following question. > > > > > > > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > > > > > calling ipadb_get_ldap_mod_extra_data() > > > > > > > > > > > > > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > > > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > > > > + if (kerr) { > > > > > > > + goto done; > > > > > > > + } > > > > > > > + > > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > > > > entry->tl_data, > > > > > > > mod_op); > > > > > > > > > > > > > > > > > > > Why it is needed to filter this data again in > > > > > > ipadb_get_ldap_mod_extra_data()? > > > > > > > > > > > > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > > > > > believe I left there in error - We decided to operate on a filtered copy > > > > > of the tl_data (which filter_authind_str_attrs() handles) rather than > > > > > removing it completely with krb5_dbe_set_string(). I had tested with the > > > > > above code commented out but forgot to remove it with the submitted patch. > > > > > > > > ok, makes sense. > > > > > > > > Nevertheless, comments in kdb.h like: > > > > > > > > /* String attributes (currently stored inside tl-data) map C string keys to > > > > * values. They can be set via kadmin and consumed by KDC plugins. */ > > > > > > > > and > > > > > > > > /* String attributes may not always be represented in tl-data. kadmin clients > > > > * must use the get_strings and set_string RPCs. */ > > > > > > > > make me wonder if it is a good idea to operate on the tl-data of type > > > > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well > > > > so I'm not insisting to change it, I'm just wondering about the reasons. > > > > > > > > Would something like (error checks are missing) > > > > > > > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", > > > > &require_auth_str); > > > > > > > > if (require_auth_str != NULL) { > > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > } > > > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > entry->tl_data, > > > > mod_op); > > > > > > > > if (require_auth_str != NULL) { > > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", > > > > require_auth_str); > > > > } > > > > > > > > have the same effect with only using the recommended API (and making the > > > > patch smaller)? > > > > > > > > > > I believe that would be the same effect, just less efficient. But > > > sticking to the API is probably safer in the long run. I am okay > > > with changing it if you would prefer. > > > > > > > Here's the updated patch. Thanks again for the review! > > Hi Matt, > > thank you for the new version. I played with/tested the patch with 'ipa > user-mod', ldapsearch, ldapmodify and kadmin.local and all was working > as expected. > > I only found a minor issue: > > > @@ -1428,6 +1512,7 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, > > { > > krb5_error_code kerr; > > krb5_tl_data *data; > > + krb5_tl_data *data_tmp = NULL; > > this is unused. > > Coverity didn't found anything else as well. > > Since Simo already added the new OID to > https://code.engineering.redhat.com/gerrit/p/rhanana.git, ACK, if you remove data_tmp. > Thanks! Here's the corrected patch. > bye, > Sumit -- Matt Rogers Red Hat, Inc -------------- next part -------------- >From c46b8aa8868c77e51a4381bdb5f09bc540abf88f Mon Sep 17 00:00:00 2001 From: Matt Rogers Date: Fri, 25 Mar 2016 17:01:40 -0400 Subject: [PATCH] ipa_kdb: add krbPrincipalAuthInd handling Store and retrieve the authentication indicator "require_auth" string in the krbPrincipalAuthInd attribute. Skip storing auth indicators to krbExtraData. --- daemons/ipa-kdb/ipa_kdb_principals.c | 170 +++++++++++++++++++++++++++++++++++ install/share/60kerberos.ldif | 6 +- 2 files changed, 174 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 629f8193223c924267f6d5f39d258cfbc51c7f63..09c888ef8fb2e86f8e89572e31d4c1e06bbdafe1 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -54,6 +54,7 @@ static char *std_principal_attrs[] = { "krbLastSuccessfulAuth", "krbLastFailedAuth", "krbLoginFailedCount", + "krbPrincipalAuthInd", "krbExtraData", "krbLastAdminUnlock", "krbObjectReferences", @@ -428,6 +429,85 @@ done: return kerr; } +static void strv_free(char **strv) +{ + int i; + + if (strv == NULL) { + return; + } + + for (i = 0; strv[i] != NULL; i++) { + free(strv[i]); + } + + free(strv); +} + +static krb5_error_code ipadb_get_ldap_auth_ind(krb5_context kcontext, + LDAP *lcontext, + LDAPMessage *lentry, + krb5_db_entry *entry) +{ + krb5_error_code ret = 0; + char **authinds = NULL; + char *aistr = NULL; + char *ap = NULL; + size_t len = 0; + size_t l = 0; + int count = 0; + int i = 0; + + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "krbPrincipalAuthInd", + &authinds); + switch (ret) { + case 0: + break; + case ENOENT: + return 0; + default: + return ret; + } + + for (count = 0; authinds != NULL && authinds[count] != NULL; count++) { + len += strlen(authinds[count]) + 1; + } + + if (len == 0) { + strv_free(authinds); + return 0; + } + + aistr = malloc(len); + if (aistr == NULL) { + ret = errno; + goto cleanup; + } + + /* Create a space-separated string of authinds. */ + ap = aistr; + l = len; + for (i = 0; i < count; i++) { + ret = snprintf(ap, l, "%s ", authinds[i]); + if (ret <= 0 || ret > l) { + ret = ENOMEM; + goto cleanup; + } + ap += ret; + l -= ret; + } + aistr[len - 1] = '\0'; + + ret = krb5_dbe_set_string(kcontext, entry, "require_auth", + aistr); + +cleanup: + strv_free(authinds); + free(aistr); + + return ret; +} + static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, char *principal, LDAPMessage *lentry, @@ -611,6 +691,10 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, goto done; } + ret = ipadb_get_ldap_auth_ind(kcontext, lcontext, lentry, entry); + if (ret) + goto done; + ret = ipadb_ldap_attr_to_key_data(lcontext, lentry, "krbPrincipalKey", &res_key_data, &result, &mkvno); @@ -1649,6 +1733,62 @@ done: return kerr; } +static krb5_error_code ipadb_get_ldap_mod_auth_ind(krb5_context kcontext, + struct ipadb_mods *imods, + krb5_db_entry *entry, + int mod_op) +{ + krb5_error_code ret = 0; + char **strlist = NULL; + char *ais = NULL; + char *ai = NULL; + char *s = NULL; + size_t ai_size = 0; + int cnt = 0; + int i = 0; + + ret = krb5_dbe_get_string(kcontext, entry, "require_auth", &ais); + if (ret) { + return ret; + } + if (ais == NULL) { + return 0; + } + + ai_size = strlen(ais) + 1; + + for (i = 0; i < ai_size; i++) { + if (ais[i] != ' ') { + continue; + } + if (i > 0 && ais[i - 1] != ' ') { + cnt++; + } + } + + strlist = calloc(cnt + 2, sizeof(*strlist)); + if (strlist == NULL) { + free(ais); + return errno; + } + + cnt = 0; + ai = strtok_r(ais, " ", &s); + while (ai != NULL) { + if (ai[0] != '\0') { + strlist[cnt++] = ai; + } + ai = strtok_r(NULL, " ", &s); + } + + ret = ipadb_get_ldap_mod_str_list(imods, "krbPrincipalAuthInd", + strlist, cnt, mod_op); + + free(ais); + free(strlist); + return ret; +} + static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, struct ipadb_mods *imods, krb5_db_entry *entry, @@ -1657,6 +1797,7 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, krb5_error_code kerr; krb5_int32 time32le; int mkvno; + char *req_auth_str = NULL; /* check each mask flag in order */ @@ -1835,6 +1976,10 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, } } + kerr = ipadb_get_ldap_mod_auth_ind(kcontext, imods, entry, mod_op); + if (kerr) + goto done; + /* KADM5_TL_DATA */ if (entry->mask & KMASK_TL_DATA) { kerr = ipadb_get_tl_data(entry, @@ -1854,12 +1999,36 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, } } + kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", + &req_auth_str); + if (kerr) { + goto done; + } + + /* Do not store auth indicators from the string attribute in + * krbExtraData. Remove require_auth value from the entry temporarily. */ + if (req_auth_str != NULL) { + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); + if (kerr) { + goto done; + } + } + kerr = ipadb_get_ldap_mod_extra_data(imods, entry->tl_data, mod_op); if (kerr && kerr != ENOENT) { goto done; } + + /* Restore require_auth value */ + if (req_auth_str != NULL) { + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", + req_auth_str); + if (kerr) { + goto done; + } + } } /* KADM5_LOAD */ @@ -1937,6 +2106,7 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, kerr = 0; done: + free(req_auth_str); return kerr; } diff --git a/install/share/60kerberos.ldif b/install/share/60kerberos.ldif index 8698e3a0538fd42443f4a3221fccfb739d4c104d..45bea2aefd3993a521e8ea732f902279622f8cb8 100644 --- a/install/share/60kerberos.ldif +++ b/install/share/60kerberos.ldif @@ -266,7 +266,9 @@ attributetypes: ( 2.16.840.1.113719.1.301.4.53.1 NAME 'krbPrincContainerRef' EQU attributetypes: ( 1.3.6.1.4.1.5322.21.2.5 NAME 'krbLastAdminUnlock' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) ##### A list of services to which a service principal can delegate. attributetypes: ( 1.3.6.1.4.1.5322.21.2.4 NAME 'krbAllowedToDelegateTo' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) -######################################################################## +##### A list of authentication indicator strings, one of which must be satisfied +##### to authenticate to the principal as a service. +attributetypes: ( 2.16.840.1.113730.3.8.15.2.1 NAME 'krbPrincipalAuthInd' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) ######################################################################## # Object Class Definitions # ######################################################################## @@ -294,7 +296,7 @@ objectClasses: ( 2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP ( krbSer objectClasses: ( 2.16.840.1.113719.1.301.6.5.1 NAME 'krbPwdService' SUP ( krbService ) ) ###### The principal data auxiliary class. Holds principal information ###### and is used to store principal information for Person, Service objects. -objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo ) ) +objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo $ krbPrincipalAuthInd ) ) ###### This class is used to create additional principals and stand alone principals. objectClasses: ( 2.16.840.1.113719.1.301.6.9.1 NAME 'krbPrincipal' SUP ( top ) MUST ( krbPrincipalName ) MAY ( krbObjectReferences ) ) ###### The principal references auxiliary class. Holds all principals referred -- 2.4.3 From mbasti at redhat.com Mon May 2 16:02:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 May 2016 18:02:11 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <57239E10.9070501@redhat.com> References: <57239E10.9070501@redhat.com> Message-ID: <57277A03.2060701@redhat.com> On 29.04.2016 19:46, Petr Viktorin wrote: > Hello, > These patches concentrate on tests, and code that was added/changed > since I last looked at the FreeIPA project. > > With these patches, I'm back to getting the same errors under py2 and > py3 when in test_xmlrpc. > > > > Patch 777: Could you fix all relative imports and enable check in pylint for that? (Remove relative-import from pylintrc), IMO there is just one extra relative import in custodia module. Do you plan to use in py2 ? from__future__importabsolute_import Patch 778: LGTM Patch 779 LGTM Patch 780 LGTM Patch 781 LGTM Patch 782 Not sure, I will review it longer Patch 783 LGTM Patch 784 LGTM Patch 785 LGTM I will test it with both py2 and py3 to convert LGTM to ACK :) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon May 2 16:27:22 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 May 2016 18:27:22 +0200 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456538079.6599.460.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> <1456503624.6599.401.camel@redhat.com> <1456519442.3136.22.camel@redhat.com> <1456538079.6599.460.camel@redhat.com> Message-ID: <9a554ed0-6802-3c68-0202-2c6960ac914f@redhat.com> Hi Matt, Nathaniel and Simo, I'd like to kindly check the status of this effort therefore resurrecting this thread. First, Is the design up to date? Are there still aspects which need to be figured out? Second execution, I see that Matt is about to finish https://fedorahosted.org/freeipa/ticket/5782 Is it planned to handle CLI and Web UI as a part of ticket https://fedorahosted.org/freeipa/ticket/433? If not then I can file tickets for it. Will the rest be handled with variation of https://github.com/npmccallum/freeipa/pull/1 and https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb637f66199da7e9225 Or is an additional patch/work needed? Regards -- Petr Vobornik From sbose at redhat.com Mon May 2 16:45:51 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 2 May 2016 18:45:51 +0200 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160502154741.GC17290@mail.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> <20160428185807.GC19396@mail.redhat.com> <20160502153033.GI7796@p.redhat.com> <20160502154741.GC17290@mail.redhat.com> Message-ID: <20160502164551.GJ7796@p.redhat.com> On Mon, May 02, 2016 at 11:47:41AM -0400, Matt Rogers wrote: > On 05/02, Sumit Bose wrote: > > On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote: > > > On 04/27, Matt Rogers wrote: > > > > On 04/27, Sumit Bose wrote: > > > > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > > > > > > On 04/26, Sumit Bose wrote: > > > > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Nathaniel McCallum" > > > > > > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > > > > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > > > > > > enhancements, > > > > > > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > > > > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > > > > > > there hurts readability. > > > > > > > > > > > > > > > > > Sure, I've attached the revised patch. > > > > > > > > > > > > > > Hi Matt, > > > > > > > > > > > > > > thank you for the patch. Currently I have the following question. > > > > > > > > > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > > > > > > calling ipadb_get_ldap_mod_extra_data() > > > > > > > > > > > > > > > > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > > > > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > > > > > + if (kerr) { > > > > > > > > + goto done; > > > > > > > > + } > > > > > > > > + > > > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > > > > > entry->tl_data, > > > > > > > > mod_op); > > > > > > > > > > > > > > > > > > > > > > Why it is needed to filter this data again in > > > > > > > ipadb_get_ldap_mod_extra_data()? > > > > > > > > > > > > > > > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > > > > > > believe I left there in error - We decided to operate on a filtered copy > > > > > > of the tl_data (which filter_authind_str_attrs() handles) rather than > > > > > > removing it completely with krb5_dbe_set_string(). I had tested with the > > > > > > above code commented out but forgot to remove it with the submitted patch. > > > > > > > > > > ok, makes sense. > > > > > > > > > > Nevertheless, comments in kdb.h like: > > > > > > > > > > /* String attributes (currently stored inside tl-data) map C string keys to > > > > > * values. They can be set via kadmin and consumed by KDC plugins. */ > > > > > > > > > > and > > > > > > > > > > /* String attributes may not always be represented in tl-data. kadmin clients > > > > > * must use the get_strings and set_string RPCs. */ > > > > > > > > > > make me wonder if it is a good idea to operate on the tl-data of type > > > > > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well > > > > > so I'm not insisting to change it, I'm just wondering about the reasons. > > > > > > > > > > Would something like (error checks are missing) > > > > > > > > > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", > > > > > &require_auth_str); > > > > > > > > > > if (require_auth_str != NULL) { > > > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > > } > > > > > > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > > entry->tl_data, > > > > > mod_op); > > > > > > > > > > if (require_auth_str != NULL) { > > > > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", > > > > > require_auth_str); > > > > > } > > > > > > > > > > have the same effect with only using the recommended API (and making the > > > > > patch smaller)? > > > > > > > > > > > > > I believe that would be the same effect, just less efficient. But > > > > sticking to the API is probably safer in the long run. I am okay > > > > with changing it if you would prefer. > > > > > > > > > > Here's the updated patch. Thanks again for the review! > > > > Hi Matt, > > > > thank you for the new version. I played with/tested the patch with 'ipa > > user-mod', ldapsearch, ldapmodify and kadmin.local and all was working > > as expected. > > > > I only found a minor issue: > > > > > @@ -1428,6 +1512,7 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, > > > { > > > krb5_error_code kerr; > > > krb5_tl_data *data; > > > + krb5_tl_data *data_tmp = NULL; > > > > this is unused. > > > > Coverity didn't found anything else as well. > > > > Since Simo already added the new OID to > > https://code.engineering.redhat.com/gerrit/p/rhanana.git, ACK, if you remove data_tmp. > > > > Thanks! Here's the corrected patch. ACK bye, Sumit > > > bye, > > Sumit > > -- > Matt Rogers > Red Hat, Inc From mbasti at redhat.com Mon May 2 17:17:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 May 2016 19:17:00 +0200 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160502164551.GJ7796@p.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> <20160428185807.GC19396@mail.redhat.com> <20160502153033.GI7796@p.redhat.com> <20160502154741.GC17290@mail.redhat.com> <20160502164551.GJ7796@p.redhat.com> Message-ID: <57278B8C.1030906@redhat.com> On 02.05.2016 18:45, Sumit Bose wrote: > On Mon, May 02, 2016 at 11:47:41AM -0400, Matt Rogers wrote: >> On 05/02, Sumit Bose wrote: >>> On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote: >>>> On 04/27, Matt Rogers wrote: >>>>> On 04/27, Sumit Bose wrote: >>>>>> On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: >>>>>>> On 04/26, Sumit Bose wrote: >>>>>>>> On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Nathaniel McCallum" >>>>>>>>>> To: "Matt Rogers" , freeipa-devel at redhat.com >>>>>>>>>> Sent: Thursday, April 14, 2016 10:32:15 AM >>>>>>>>>> Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling >>>>>>>>>> >>>>>>>>>> On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The attached patch is a part of the authentication indicator >>>>>>>>>>> enhancements, >>>>>>>>>>> adding indicator value storage and retrieval for the KDB driver. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5782 >>>>>>>>>> Can you add some whitespace in next_attr()? The density of the code >>>>>>>>>> there hurts readability. >>>>>>>>>> >>>>>>>>> Sure, I've attached the revised patch. >>>>>>>> Hi Matt, >>>>>>>> >>>>>>>> thank you for the patch. Currently I have the following question. >>>>>>>> >>>>>>>> You call krb5_dbe_set_string to remove the 'require_auth' data before >>>>>>>> calling ipadb_get_ldap_mod_extra_data() >>>>>>>> >>>>>>>>> + /* Delete authinds from tl_data so it is not included in krbExtraData. */ >>>>>>>>> + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); >>>>>>>>> + if (kerr) { >>>>>>>>> + goto done; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> kerr = ipadb_get_ldap_mod_extra_data(imods, >>>>>>>>> entry->tl_data, >>>>>>>>> mod_op); >>>>>>>>> >>>>>>>> Why it is needed to filter this data again in >>>>>>>> ipadb_get_ldap_mod_extra_data()? >>>>>>>> >>>>>>> Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I >>>>>>> believe I left there in error - We decided to operate on a filtered copy >>>>>>> of the tl_data (which filter_authind_str_attrs() handles) rather than >>>>>>> removing it completely with krb5_dbe_set_string(). I had tested with the >>>>>>> above code commented out but forgot to remove it with the submitted patch. >>>>>> ok, makes sense. >>>>>> >>>>>> Nevertheless, comments in kdb.h like: >>>>>> >>>>>> /* String attributes (currently stored inside tl-data) map C string keys to >>>>>> * values. They can be set via kadmin and consumed by KDC plugins. */ >>>>>> >>>>>> and >>>>>> >>>>>> /* String attributes may not always be represented in tl-data. kadmin clients >>>>>> * must use the get_strings and set_string RPCs. */ >>>>>> >>>>>> make me wonder if it is a good idea to operate on the tl-data of type >>>>>> KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well >>>>>> so I'm not insisting to change it, I'm just wondering about the reasons. >>>>>> >>>>>> Would something like (error checks are missing) >>>>>> >>>>>> kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", >>>>>> &require_auth_str); >>>>>> >>>>>> if (require_auth_str != NULL) { >>>>>> kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); >>>>>> } >>>>>> >>>>>> kerr = ipadb_get_ldap_mod_extra_data(imods, >>>>>> entry->tl_data, >>>>>> mod_op); >>>>>> >>>>>> if (require_auth_str != NULL) { >>>>>> kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", >>>>>> require_auth_str); >>>>>> } >>>>>> >>>>>> have the same effect with only using the recommended API (and making the >>>>>> patch smaller)? >>>>>> >>>>> I believe that would be the same effect, just less efficient. But >>>>> sticking to the API is probably safer in the long run. I am okay >>>>> with changing it if you would prefer. >>>>> >>>> Here's the updated patch. Thanks again for the review! >>> Hi Matt, >>> >>> thank you for the new version. I played with/tested the patch with 'ipa >>> user-mod', ldapsearch, ldapmodify and kadmin.local and all was working >>> as expected. >>> >>> I only found a minor issue: >>> >>>> @@ -1428,6 +1512,7 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, >>>> { >>>> krb5_error_code kerr; >>>> krb5_tl_data *data; >>>> + krb5_tl_data *data_tmp = NULL; >>> this is unused. >>> >>> Coverity didn't found anything else as well. >>> >>> Since Simo already added the new OID to >>> https://code.engineering.redhat.com/gerrit/p/rhanana.git, ACK, if you remove data_tmp. >>> >> Thanks! Here's the corrected patch. > ACK > > bye, > Sumit > >>> bye, >>> Sumit >> -- >> Matt Rogers >> Red Hat, Inc Pushed to master: 8a2afcafee977675fc289acab50cc808b469a2b3 From ftweedal at redhat.com Tue May 3 07:05:58 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 3 May 2016 17:05:58 +1000 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> Message-ID: <20160503070558.GJ1237@dhcp-40-8.bne.redhat.com> On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > On 21.4.2016 05:30, Fraser Tweedale wrote: > >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > >>Hi all, > >> > >>The attached patches configure lightweight CA key replication on IPA > >>CAs, on upgrade and installation. > >> > >>Patches 0051..0052 from my other mail are also needed for the system > >>to work, but this patchset does not depend on them and can be > >>reviewed independently. > >> > >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > >>- it just puts the necessary principals/keys/configuration in place. > >> > >>Cheers, > >>Fraser > >> > >New patches attached; 0054-2 changes the service name from > >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > >principal to search server Custodia keys. > Honza, thanks for review. Comments inline. > Patch 53: > > I'm not sure about this approach - the cn of custodia keys in LDAP is a > free-form string, I would not tie it to service names, but rather try to > keep it short. > > In the key replication section of the design page, you mention "ca/$NAME", I > think this is a good template for the cn and that we should stick to it. > This scheme (or something like it, *without* '/' as the separator) is needed to satisfy the ACI that allows host principals to manage Custodia keys: add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) The CN must contain the hostname, and we must also disambiguate on key type. The current scheme is: {sig,enc}~dogtag/ e.g. enc~dogtag/f23-2.ipa.local The first separator cannot be '/' because the '*' wildcard in the ACI is not greedy - the captured text would include the servicename and fail to match any userdn. If you do not like '~' feel free to suggest a different symbol :) The alternative is to add more ACIs. > > Patch 54: > > 1) This belongs to CAInstance.configure_instance(): > > + CA = cainstance.CAInstance( > + api.env.realm, certs.NSS_DIR, host_name=api.env.host) > + CA.setup_lightweight_ca_key_retrieval() > See comments for (5). > > 2) Any ACI changes should be in a separate patch. (What happened to patch > 52?) > Patch 52 added an ACI that allowed any authenticated user to see the keys. Simo wanted it limited it to the Dogtag principal so I rescinded patch 52 and added the ACI in the same patch where the principal was added. Separate patch is no problem; I will resurrect number 52. > > 3) This is not a platform constant, just a constant: > > + PKI_GSSAPI_SERVICE_NAME = 'dogtag' > Thanks, will put it in `ipalib.constants'. > > 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please > split it into a "setup keytab" and "setup custodia" parts. > Will extract methods for next patchset. > > 5) This also belongs to CAInstance.configure_instance(): > > + if setup_ca: > + # CA was configured before Kerberos; > + # add Custodia client princ and keys now > + ca_instance.setup_lightweight_ca_key_retrieval() > > In order for that to work, you need to move the ca.install_step_1() after > krb.create_instance(), but that should be OK, since KrbInstance does not > talk to the CA. > `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which fails if called before `krb.create_instance' due to missing krb5.conf:: 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local at IPA.LOCAL -x ipa-setup-override-restrictions 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 2016-05-03T06:29:23Z DEBUG stdout= 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm Moving `ca.install_step_1()' to after `krb.create_instance()' does not help, because `CAInstance.configure_instance' is called from `ca.install_step_0()'. However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' *directly* from `ca.install_step_1' would probably work. Are you happy with putting it there, instead of `configure_instance()'? Cheers, Fraser From ldoudova at redhat.com Tue May 3 07:33:09 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 3 May 2016 09:33:09 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate Message-ID: <57285435.5020600@redhat.com> Hi, attached patch provides solution for https://fedorahosted.org/freeipa/ticket/5839 by removing all certificates added to local host during tests. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Test-fix-Cleanup-for-host-certificate.patch Type: text/x-patch Size: 2621 bytes Desc: not available URL: From mbasti at redhat.com Tue May 3 08:33:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 10:33:17 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <57285435.5020600@redhat.com> References: <57285435.5020600@redhat.com> Message-ID: <5728624D.90100@redhat.com> Hello I'm quite confused what is happening in that code, can you explain it more to me? I see duplicated code there. On 03.05.2016 09:33, Lenka Doudova wrote: > + def make_fixture_certcleanup(self, request): > + """ Fixture to cleanup certificate from local host """ > + cleanup_command = self.make_update_command( > + updates={'usercertificate':''}) > + try: > + cleanup_command() > + except errors.EmptyModlist: > + pass > + Why it is called here. > + def cleanup(): > + try: > + cleanup_command() > + except errors.EmptyModlist: > + pass > + > + request.addfinalizer(cleanup) Why it is the duplicated code called as finalizer when it was called before? > + > + return self Martin^2 From ldoudova at redhat.com Tue May 3 09:18:24 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 3 May 2016 11:18:24 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <5728624D.90100@redhat.com> References: <57285435.5020600@redhat.com> <5728624D.90100@redhat.com> Message-ID: <57286CE0.6060300@redhat.com> On 05/03/2016 10:33 AM, Martin Basti wrote: > Hello I'm quite confused what is happening in that code, can you > explain it more to me? I see duplicated code there. Sorry, that was just an unnecessary leftover. Fixed patch attached. The code is expected to remove any certificates that were added to the local host but not to try to remove the host itself. Lenka > > > Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012.1-Test-fix-Cleanup-for-host-certificate.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: From mbasti at redhat.com Tue May 3 10:15:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 12:15:34 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <57286CE0.6060300@redhat.com> References: <57285435.5020600@redhat.com> <5728624D.90100@redhat.com> <57286CE0.6060300@redhat.com> Message-ID: <57287A46.4070502@redhat.com> On 03.05.2016 11:18, Lenka Doudova wrote: > > > On 05/03/2016 10:33 AM, Martin Basti wrote: >> Hello I'm quite confused what is happening in that code, can you >> explain it more to me? I see duplicated code there. > Sorry, that was just an unnecessary leftover. Fixed patch attached. > The code is expected to remove any certificates that were added to the > local host but not to try to remove the host itself. > > Lenka >> >> >> Martin^2 > Looks better, please follow proper naming of patches according how to format patch guide. I propose following (Patch attached) changes. It looks weird to me to return self object Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-9999-proposed-changes.patch Type: text/x-patch Size: 1833 bytes Desc: not available URL: From dkupka at redhat.com Tue May 3 11:45:39 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 3 May 2016 13:45:39 +0200 Subject: [Freeipa-devel] Improving bug reporting Message-ID: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Hello everyone! I often miss proper reproducer and other important info in trac tickets. Asking for the missing info or guessing and trying is as ineffective as it sounds and costs us a lot of time and effort. I believe we can improve that. We have guidelines for reporting a bug [1] but it obviously isn't enough. I propose to prefill track ticket's description with following (or similar) template and be strict on refusing (i.e. closing as invalid) tickets that are incomplete. Any thoughts, suggestions, agreement or disagreement? [1] http://www.freeipa.org/page/Troubleshooting#Reporting_bugs --8<------------- trac-ticket-template-proposal ------------------->8-- Related SW versions: On server: {{{ $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server certmonger }}} On client: {{{ $ rpm -q freeipa-client krb5-workstation certmonger }}} Reproducible: How often the issue occurs or what special condition is required to be met. Examples: Always / Happened X times of Y tries / Only at noon 29th February when it's also Thursday / Only on Raspberry Pi Steps to reproduce: Precise description of all related steps you have done. List of commands to run is the best form. Example: {{{ # ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.TEST -U # echo Secret123 | kinit admin }}} Actual result: Description of behavior you have observed (error, unexpected warning, ...). Example: {{{ kinit: Client 'admin at EXAMPLE.TEST' not found in Kerberos database while getting initial credentials }}} Expected result: Description of behavior you have expected. Example: TGT for admin user is acquired. --8<--------------------------------------------------------------->8-- -- David Kupka From mbasti at redhat.com Tue May 3 11:52:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 13:52:13 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Message-ID: <572890ED.5070402@redhat.com> On 03.05.2016 13:45, David Kupka wrote: > Hello everyone! > > I often miss proper reproducer and other important info in trac > tickets. Asking for the missing info or guessing and trying is as > ineffective as it sounds and costs us a lot of time and effort. I > believe we can improve that. > > We have guidelines for reporting a bug [1] but it obviously isn't > enough. I propose to prefill track ticket's description with following > (or similar) template and be strict on refusing (i.e. closing as > invalid) tickets that are incomplete. > > Any thoughts, suggestions, agreement or disagreement? > > [1] http://www.freeipa.org/page/Troubleshooting#Reporting_bugs > > --8<------------- trac-ticket-template-proposal ------------------->8-- > Related SW versions: > On server: > {{{ > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server > certmonger > }}} > On client: > {{{ > $ rpm -q freeipa-client krb5-workstation certmonger > }}} > > Reproducible: > How often the issue occurs or what special condition is required to be > met. > > Examples: > Always / Happened X times of Y tries / Only at noon 29th February when > it's also Thursday / Only on Raspberry Pi > > Steps to reproduce: > Precise description of all related steps you have done. List of > commands to run is the best form. > > Example: > {{{ > # ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.TEST -U > # echo Secret123 | kinit admin > }}} > > > Actual result: > Description of behavior you have observed (error, unexpected warning, > ...). > > Example: > {{{ > kinit: Client 'admin at EXAMPLE.TEST' not found in Kerberos database > while getting initial credentials > }}} > > Expected result: > Description of behavior you have expected. > > Example: > TGT for admin user is acquired. > --8<--------------------------------------------------------------->8-- > +1 I suggest to mention also attach logs, for inspiration we may look at bind-dyndb-ldap trac. Martin^2 From ldoudova at redhat.com Tue May 3 12:08:22 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 3 May 2016 14:08:22 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <57287A46.4070502@redhat.com> References: <57285435.5020600@redhat.com> <5728624D.90100@redhat.com> <57286CE0.6060300@redhat.com> <57287A46.4070502@redhat.com> Message-ID: <572894B6.3020301@redhat.com> On 05/03/2016 12:15 PM, Martin Basti wrote: > > > On 03.05.2016 11:18, Lenka Doudova wrote: >> >> >> On 05/03/2016 10:33 AM, Martin Basti wrote: >>> Hello I'm quite confused what is happening in that code, can you >>> explain it more to me? I see duplicated code there. >> Sorry, that was just an unnecessary leftover. Fixed patch attached. >> The code is expected to remove any certificates that were added to >> the local host but not to try to remove the host itself. >> >> Lenka >>> >>> >>> Martin^2 >> > Looks better, please follow proper naming of patches according how to > format patch guide. > I propose following (Patch attached) changes. It looks weird to me to > return self object > > Martin > Ok, fixed patch attached. Thanks, Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012.2-Test-fix-Cleanup-for-host-certificate.patch Type: text/x-patch Size: 2455 bytes Desc: not available URL: From ldoudova at redhat.com Tue May 3 12:26:51 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 3 May 2016 14:26:51 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <572894B6.3020301@redhat.com> References: <57285435.5020600@redhat.com> <5728624D.90100@redhat.com> <57286CE0.6060300@redhat.com> <57287A46.4070502@redhat.com> <572894B6.3020301@redhat.com> Message-ID: <5728990B.5000107@redhat.com> On 05/03/2016 02:08 PM, Lenka Doudova wrote: > > > On 05/03/2016 12:15 PM, Martin Basti wrote: >> >> >> On 03.05.2016 11:18, Lenka Doudova wrote: >>> >>> >>> On 05/03/2016 10:33 AM, Martin Basti wrote: >>>> Hello I'm quite confused what is happening in that code, can you >>>> explain it more to me? I see duplicated code there. >>> Sorry, that was just an unnecessary leftover. Fixed patch attached. >>> The code is expected to remove any certificates that were added to >>> the local host but not to try to remove the host itself. >>> >>> Lenka >>>> >>>> >>>> Martin^2 >>> >> Looks better, please follow proper naming of patches according how to >> format patch guide. >> I propose following (Patch attached) changes. It looks weird to me to >> return self object >> >> Martin >> > Ok, fixed patch attached. > > Thanks, > Lenka > > And one more small change. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0012.3-Test-fix-Cleanup-for-host-certificate.patch Type: text/x-patch Size: 2525 bytes Desc: not available URL: From pspacek at redhat.com Tue May 3 12:56:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 14:56:42 +0200 Subject: [Freeipa-devel] [PATCH 0103] DNS installer: accept --auto-forwarders option in unattended mode Message-ID: Hello, DNS installer: accept --auto-forwarders option in unattended mode https://fedorahosted.org/freeipa/ticket/5869 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0103-DNS-installer-accept-auto-forwarders-option-in-unatt.patch Type: text/x-patch Size: 1383 bytes Desc: not available URL: From pspacek at redhat.com Tue May 3 12:59:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 14:59:59 +0200 Subject: [Freeipa-devel] [PATCH 0104-0109] DNS upgrade: change forwarding policy to "only" if private IPs are used Message-ID: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> Hello, DNS upgrade: change forwarding policy to "only" if private IPs are used. https://fedorahosted.org/freeipa/ticket/5710 This is the upgrade part. I will add one more patch to print a warning in dnsforwardzone* commands to avoid surprises. Please do not close the ticket yet. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0104-Add-ipaDNSVersion-option-to-dnsconfig-commands-and-u.patch Type: text/x-patch Size: 14457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0105-DNS-upgrade-separate-backup-logic-to-make-it-reusabl.patch Type: text/x-patch Size: 9408 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0106-Add-function-ipapython.dnsutil.related_to_auto_empty.patch Type: text/x-patch Size: 1825 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0107-DNS-upgrade-change-forwarding-policy-to-only-for-con.patch Type: text/x-patch Size: 6125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0108-DNS-upgrade-change-global-forwarding-policy-in-LDAP-.patch Type: text/x-patch Size: 4185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0109-DNS-upgrade-change-global-forwarding-policy-in-named.patch Type: text/x-patch Size: 7753 bytes Desc: not available URL: From pspacek at redhat.com Tue May 3 13:01:09 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 15:01:09 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <57239EA7.6050902@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> Message-ID: <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> On 29.4.2016 19:49, Petr Viktorin wrote: > On 04/12/2016 12:52 PM, Petr Spacek wrote: >> On 19.2.2016 13:50, Petr Viktorin wrote: >>> Is it time yet? >>> >>> This patch switches /usr/bin/ipa to Python 3 for >>> - the in-tree ./ipa command >>> - RPMs, when built with_python3 >> >> NACK, the change in 'ipa' command broke ipa dnszone-find: >> >> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found >> >> The same command works when I switch python3->python2 in the 'ipa' command. > > That error is now fixed, could you please re-review? ACK, I did not find any breakage (when combined with other Py3 patches). -- Petr^2 Spacek From pspacek at redhat.com Tue May 3 13:02:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 15:02:20 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <57277A03.2060701@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> Message-ID: <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> On 2.5.2016 18:02, Martin Basti wrote: > > > On 29.04.2016 19:46, Petr Viktorin wrote: >> Hello, >> These patches concentrate on tests, and code that was added/changed >> since I last looked at the FreeIPA project. >> >> With these patches, I'm back to getting the same errors under py2 and >> py3 when in test_xmlrpc. >> >> >> >> > Patch 777: > Could you fix all relative imports and enable check in pylint for that? > (Remove relative-import from pylintrc), IMO there is just one extra relative > import in custodia module. > > Do you plan to use in py2 ? > from__future__importabsolute_import > > Patch 778: > LGTM > > Patch 779 > LGTM > > Patch 780 > LGTM > > Patch 781 > LGTM > > Patch 782 > Not sure, I will review it longer > > Patch 783 > LGTM > > Patch 784 > LGTM > > Patch 785 > LGTM > > I will test it with both py2 and py3 to convert LGTM to ACK :) Functional ACK, I did not find any breakage (when combined with other Py3 patches). -- Petr^2 Spacek From pspacek at redhat.com Tue May 3 13:04:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 15:04:35 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <20160425081256.GC8197@10.4.128.1> References: <571A0B03.9030402@redhat.com> <20160425072916.GA8197@10.4.128.1> <571DC895.6050206@redhat.com> <40e66788-c252-4739-5619-6c6eaa64fdb2@redhat.com> <20160425081256.GC8197@10.4.128.1> Message-ID: On 25.4.2016 10:12, Lukas Slebodnik wrote: > On (25/04/16 09:59), Jan Cholasta wrote: >> On 25.4.2016 09:34, Petr Spacek wrote: >>> On 25.4.2016 09:29, Lukas Slebodnik wrote: >>>> On (25/04/16 07:23), Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 22.4.2016 13:29, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> Makefile: add sed to BuildRequires >>>>>> >>>>>> It was requried since forever but we did not explicitly mention it. >>>>> >>>>> IIRC sed is part of the minimum build environemnt and as such should not be >>>>> explicitly required in the spec file. I personally don't care, but this is >>>>> the likely reason why it wan't there from the beginning. >>>>> >>>> +1 >>>> >>>> It is part of group "@buildsys-build". >>>> and fedora packaging guidelines does not recommend to list >>>> packages from this group in BuildRequires. >>> >>> I consider this piece of Fedora guidelines brain-dead as "explicit is better >>> than implicit". Anyway, feel free to NACK it so the status of the patch is >>> clear and this thread can die. I do not insist on it. >> >> I can't find it in the guidelines anymore, so LGTM. >> > It seems that it was changed since I read it last time. > > There is vague description of which packages should be there. > http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 > It is important that your package list all necessary build dependencies > using the BuildRequires?: > tag. You may assume that enough of an environment exists for RPM to function > and execute basic shell scripts, but you should not assume any other packages > are present as RPM dependencies and anything brought into the buildroot > by the build system may change over time. > > But utility fedora-review still complains if you list packages from group > "@buildsys-build" So, should I drop the patch from my queue or not? I still think that it is brain-dead not to list dependencies explicitly but you tell me if I should remove the patch from my waiting-for-review-queue or not. -- Petr^2 Spacek From pspacek at redhat.com Tue May 3 13:20:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 15:20:21 +0200 Subject: [Freeipa-devel] [PATCH] Fix added to ipa-compat-manage command line help In-Reply-To: <57272F69.9050001@redhat.com> References: <57272F69.9050001@redhat.com> Message-ID: <950a6605-0b34-7a83-437f-81e882d96e28@redhat.com> On 2.5.2016 12:43, Abhijeet Kasurde wrote: > Hi All, > > Please review this patch. ACK -- Petr^2 Spacek From pspacek at redhat.com Tue May 3 13:21:32 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 May 2016 15:21:32 +0200 Subject: [Freeipa-devel] [PATCH] Updated ipa command man page In-Reply-To: <60897f6b-7783-201d-6893-ee9bd3821c7f@redhat.com> References: <57233E12.7000706@redhat.com> <60897f6b-7783-201d-6893-ee9bd3821c7f@redhat.com> Message-ID: <20c832df-9035-eaa2-dc74-98790a6bae9a@redhat.com> On 2.5.2016 09:41, Petr Spacek wrote: > On 29.4.2016 12:57, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review this patch. > > LGTM Okay, so I applied it! ACK ;-) -- Petr^2 Spacek From jhrozek at redhat.com Tue May 3 13:35:47 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 May 2016 15:35:47 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Message-ID: <20160503133547.GD7741@hendrix> On Tue, May 03, 2016 at 01:45:39PM +0200, David Kupka wrote: > Hello everyone! > > I often miss proper reproducer and other important info in trac tickets. > Asking for the missing info or guessing and trying is as ineffective as it > sounds and costs us a lot of time and effort. I believe we can improve that. > > We have guidelines for reporting a bug [1] but it obviously isn't enough. I > propose to prefill track ticket's description with following (or similar) > template and be strict on refusing (i.e. closing as invalid) tickets that > are incomplete. > > Any thoughts, suggestions, agreement or disagreement? I'll just throw the sssd page we have on the subject: https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs I would at least add the note about security-sensitive bugs to the freeipa page, we really don't want CVEs being reported to trac :-) From redhatrises at gmail.com Tue May 3 13:41:41 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 3 May 2016 07:41:41 -0600 Subject: [Freeipa-devel] [PATCH 0068] Use ipareplica-ca-install.log instead of ipaserver-ca-install.log Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5727. Per comment #7, this removes ipaserver-ca-install.log and uses ipareplica-ca-install.log. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0068-Use-ipareplica-ca-install.log-instead-of-ipaserver-c.patch Type: text/x-patch Size: 1880 bytes Desc: not available URL: From pviktori at redhat.com Tue May 3 13:52:21 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 3 May 2016 15:52:21 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> Message-ID: <5728AD15.10502@redhat.com> On 05/03/2016 03:02 PM, Petr Spacek wrote: > On 2.5.2016 18:02, Martin Basti wrote: >> >> >> On 29.04.2016 19:46, Petr Viktorin wrote: >>> Hello, >>> These patches concentrate on tests, and code that was added/changed >>> since I last looked at the FreeIPA project. >>> >>> With these patches, I'm back to getting the same errors under py2 and >>> py3 when in test_xmlrpc. >>> >>> >>> >>> >> Patch 777: >> Could you fix all relative imports and enable check in pylint for that? >> (Remove relative-import from pylintrc), IMO there is just one extra relative >> import in custodia module. Would it be OK if I do that in a separate patch, in the next batch? This one is fixing the tests. (I have the change in my worktree, so I won't forget when I next sit down to work on IPA.) >> Do you plan to use in py2 ? >> from__future__importabsolute_import I think that's unnecessary boilerplate; the errors this catches are easily found by other means. And it doesn't guard against someone forgetting the __future__ import itself in a new file. The pylint check will be much better. >> >> Patch 778: >> LGTM >> >> Patch 779 >> LGTM >> >> Patch 780 >> LGTM >> >> Patch 781 >> LGTM >> >> Patch 782 >> Not sure, I will review it longer >> >> Patch 783 >> LGTM >> >> Patch 784 >> LGTM >> >> Patch 785 >> LGTM >> >> I will test it with both py2 and py3 to convert LGTM to ACK :) > > Functional ACK, I did not find any breakage (when combined with other Py3 > patches). > -- Petr Viktorin From akasurde at redhat.com Tue May 3 13:53:21 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 3 May 2016 19:23:21 +0530 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160503133547.GD7741@hendrix> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503133547.GD7741@hendrix> Message-ID: <5728AD51.9020508@redhat.com> On 05/03/2016 07:05 PM, Jakub Hrozek wrote: > On Tue, May 03, 2016 at 01:45:39PM +0200, David Kupka wrote: >> Hello everyone! >> >> I often miss proper reproducer and other important info in trac tickets. >> Asking for the missing info or guessing and trying is as ineffective as it >> sounds and costs us a lot of time and effort. I believe we can improve that. >> >> We have guidelines for reporting a bug [1] but it obviously isn't enough. I >> propose to prefill track ticket's description with following (or similar) >> template and be strict on refusing (i.e. closing as invalid) tickets that >> are incomplete. >> >> Any thoughts, suggestions, agreement or disagreement? > I'll just throw the sssd page we have on the subject: > https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs > > I would at least add the note about security-sensitive bugs to the > freeipa page, we really don't want CVEs being reported to trac :-) > Is there any automated script which can do this for us, something like sosreport ? If not then it would be good idea to invest time and efforts to have one script to gather all logs and reports. Thanks, Abhijeet Kasurde From patrice.duc.jacquet at gmail.com Tue May 3 14:01:50 2016 From: patrice.duc.jacquet at gmail.com (Patrice Duc-Jacquet) Date: Tue, 3 May 2016 16:01:50 +0200 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> Message-ID: Hi everyone this is my first patch. So I may have done thhings nor in a proper way. Please let me know if something is wrong in the proceess I followed. With regards Pat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pducjac-0001-Add-more-information-regarding-where-to-find-revocat.patch Type: text/x-patch Size: 7122 bytes Desc: not available URL: From mbasti at redhat.com Tue May 3 14:13:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 16:13:37 +0200 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> Message-ID: <5728B211.8080101@redhat.com> On 03.05.2016 16:01, Patrice Duc-Jacquet wrote: > Hi everyone > this is my first patch. So I may have done thhings nor in a proper > way. Please let me know if something is wrong in the proceess I > followed. With regards > > Pat > > Hello, thank you for your patch. Please remove changes in .po and .pot files from the patch, these files are generated automatically from zanata. thank you Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue May 3 14:31:17 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 3 May 2016 08:31:17 -0600 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: <5728B211.8080101@redhat.com> References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> <5728B211.8080101@redhat.com> Message-ID: Hello, Thank you for your patch as well. >- doc=_('Reason for revoking the certificate (0-10)'), >+ doc=_('Reason for revoking the certificate (0-10). See RFC 5280 (paragraph 5.3.1) for reason details'), Rather than just specifying the RFC with the paragraph to go look up, can you either add the revocation options or say something like: + doc=_('Reason for revoking the certificate (0-10). See \'ipa help cert\' for revocation reason details.'), IMO, it is a little annoying to go look up revocation reasons when those reasons can either be added to the help output or exist already in `ipa help cert`. Thanks, Gabe On Tue, May 3, 2016 at 8:13 AM, Martin Basti wrote: > > > On 03.05.2016 16:01, Patrice Duc-Jacquet wrote: > > Hi everyone > this is my first patch. So I may have done thhings nor in a proper way. > Please let me know if something is wrong in the proceess I followed. With > regards > > Pat > > > Hello, > > thank you for your patch. Please remove changes in .po and .pot files from > the patch, these files are generated automatically from zanata. > > thank you > > Martin > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 3 14:31:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 16:31:26 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <5728AD15.10502@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> <5728AD15.10502@redhat.com> Message-ID: <5728B63E.30704@redhat.com> On 03.05.2016 15:52, Petr Viktorin wrote: > On 05/03/2016 03:02 PM, Petr Spacek wrote: >> On 2.5.2016 18:02, Martin Basti wrote: >>> >>> On 29.04.2016 19:46, Petr Viktorin wrote: >>>> Hello, >>>> These patches concentrate on tests, and code that was added/changed >>>> since I last looked at the FreeIPA project. >>>> >>>> With these patches, I'm back to getting the same errors under py2 and >>>> py3 when in test_xmlrpc. >>>> >>>> >>>> >>>> >>> Patch 777: >>> Could you fix all relative imports and enable check in pylint for that? >>> (Remove relative-import from pylintrc), IMO there is just one extra relative >>> import in custodia module. > Would it be OK if I do that in a separate patch, in the next batch? This > one is fixing the tests. > (I have the change in my worktree, so I won't forget when I next sit > down to work on IPA.) It is okay to send it in a next patch :) ACK on this patch then >>> Do you plan to use in py2 ? >>> from__future__importabsolute_import > I think that's unnecessary boilerplate; the errors this catches are > easily found by other means. > And it doesn't guard against someone forgetting the __future__ import > itself in a new file. The pylint check will be much better. Ok, just FYI pylint has check that prevents forgetting this import (disabled in IPA) >>> Patch 778: >>> LGTM >>> >>> Patch 779 >>> LGTM >>> >>> Patch 780 >>> LGTM >>> >>> Patch 781 >>> LGTM >>> >>> Patch 782 >>> Not sure, I will review it longer >>> >>> Patch 783 >>> LGTM >>> >>> Patch 784 >>> LGTM >>> >>> Patch 785 >>> LGTM >>> >>> I will test it with both py2 and py3 to convert LGTM to ACK :) >> Functional ACK, I did not find any breakage (when combined with other Py3 >> patches). >> > Hold your horses :D, I probably find something in tests I run ipa-run-tests with xmlrpc tests under python2 and python3, please note the different count of tests and errors in py3 platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini collecting ... collected 1835 items platform linux -- Python 3.5.1, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 -- /bin/python3 rootdir: /usr/lib/python3.5/site-packages/ipatests, inifile: pytest.ini collecting ... collected 1694 items / 7 errors Collecting failed on following import errors: test_xmlrpc/test_add_remove_cert_cmd.py:13: in ipatests.test_xmlrpc.testcert import get_testcert xmlrpc/testcert.py:34: in ipaserver.plugins import rabase ImportError: No module named 'ipaserver' And I found more errors, but they may be unrelated I have to investigate more Martin^2 From rcritten at redhat.com Tue May 3 14:41:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 3 May 2016 10:41:44 -0400 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> <5728B211.8080101@redhat.com> Message-ID: <5728B8A8.6070608@redhat.com> Gabe Alford wrote: > Hello, > > Thank you for your patch as well. > > >- doc=_('Reason for revoking the certificate (0-10)'), > >+ doc=_('Reason for revoking the certificate (0-10). See > RFC 5280 (paragraph 5.3.1) for reason details'), > > Rather than just specifying the RFC with the paragraph to go look up, > can you either add the revocation options or say something like: > > + doc=_('Reason for revoking the certificate (0-10). See > \'ipa help cert\' for revocation reason details.'), > > IMO, it is a little annoying to go look up revocation reasons when those > reasons can either be added to the help output or exist already in `ipa > help cert`. FTR I added it to the top level help because the reasons are used in multiple places and didn't want to duplicate them, and adding them to a specific option help would overload it big time IMHO. rob From mbasti at redhat.com Tue May 3 15:14:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 17:14:17 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0012] Provide cleanup for host certificate In-Reply-To: <5728990B.5000107@redhat.com> References: <57285435.5020600@redhat.com> <5728624D.90100@redhat.com> <57286CE0.6060300@redhat.com> <57287A46.4070502@redhat.com> <572894B6.3020301@redhat.com> <5728990B.5000107@redhat.com> Message-ID: <5728C049.6060806@redhat.com> On 03.05.2016 14:26, Lenka Doudova wrote: > > > On 05/03/2016 02:08 PM, Lenka Doudova wrote: >> >> >> On 05/03/2016 12:15 PM, Martin Basti wrote: >>> >>> >>> On 03.05.2016 11:18, Lenka Doudova wrote: >>>> >>>> >>>> On 05/03/2016 10:33 AM, Martin Basti wrote: >>>>> Hello I'm quite confused what is happening in that code, can you >>>>> explain it more to me? I see duplicated code there. >>>> Sorry, that was just an unnecessary leftover. Fixed patch attached. >>>> The code is expected to remove any certificates that were added to >>>> the local host but not to try to remove the host itself. >>>> >>>> Lenka >>>>> >>>>> >>>>> Martin^2 >>>> >>> Looks better, please follow proper naming of patches according how >>> to format patch guide. >>> I propose following (Patch attached) changes. It looks weird to me >>> to return self object >>> >>> Martin >>> >> Ok, fixed patch attached. >> >> Thanks, >> Lenka >> >> > And one more small change. > Lenka > > ACK Pushed to: ipa-4-3: c8330a9b09c1999d2721f3fb2b2170b3c1568b22 master: 847c950408b3c00ce3a4625709cadcddf39af6a5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrice.duc.jacquet at gmail.com Tue May 3 15:35:21 2016 From: patrice.duc.jacquet at gmail.com (Patrice Duc-Jacquet) Date: Tue, 3 May 2016 17:35:21 +0200 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: <5728B8A8.6070608@redhat.com> References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> <5728B211.8080101@redhat.com> <5728B8A8.6070608@redhat.com> Message-ID: On 05/03/2016 04:41 PM, Rob Crittenden wrote: > Gabe Alford wrote: >> Hello, >> >> Thank you for your patch as well. >> >> >- doc=_('Reason for revoking the certificate (0-10)'), >> >+ doc=_('Reason for revoking the certificate (0-10). See >> RFC 5280 (paragraph 5.3.1) for reason details'), >> >> Rather than just specifying the RFC with the paragraph to go look up, >> can you either add the revocation options or say something like: >> >> + doc=_('Reason for revoking the certificate (0-10). See >> \'ipa help cert\' for revocation reason details.'), >> >> IMO, it is a little annoying to go look up revocation reasons when those >> reasons can either be added to the help output or exist already in `ipa >> help cert`. > > FTR I added it to the top level help because the reasons are used in > multiple places and didn't want to duplicate them, and adding them to > a specific option help would overload it big time IMHO. > > rob > Hi everyone thanks for your valuable comments. I fully agree that it is not recommended to duplicate this information. So as Rob suggested, I should avoid to add this information to cert_revoke option and thus I plan to modify the help message as follow: doc=_('Reason for revoking the certificate (0-10). Type "ipa help cert" for reason details'), Do you agree with that modification? Thanks in advance and regards Pat From mbasti at redhat.com Tue May 3 15:43:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 May 2016 17:43:01 +0200 Subject: [Freeipa-devel] [PATCH] Updated ipa command man page In-Reply-To: <20c832df-9035-eaa2-dc74-98790a6bae9a@redhat.com> References: <57233E12.7000706@redhat.com> <60897f6b-7783-201d-6893-ee9bd3821c7f@redhat.com> <20c832df-9035-eaa2-dc74-98790a6bae9a@redhat.com> Message-ID: <5728C705.7010209@redhat.com> On 03.05.2016 15:21, Petr Spacek wrote: > On 2.5.2016 09:41, Petr Spacek wrote: >> On 29.4.2016 12:57, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please review this patch. >> LGTM > Okay, so I applied it! > > ACK ;-) > trac ticket (#5871) added to commit message Pushed to: master: 7d46fd15f84ee31b4141ed3fc53b4ddb3fbe4167 ipa-4-3: 2c0c7bece2f90dba568a39db68b835e99ccbc9ba From npmccallum at redhat.com Tue May 3 16:11:32 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 03 May 2016 12:11:32 -0400 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <9a554ed0-6802-3c68-0202-2c6960ac914f@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> <1456503624.6599.401.camel@redhat.com> <1456519442.3136.22.camel@redhat.com> <1456538079.6599.460.camel@redhat.com> <9a554ed0-6802-3c68-0202-2c6960ac914f@redhat.com> Message-ID: <1462291892.2517.6.camel@redhat.com> On Mon, 2016-05-02 at 18:27 +0200, Petr Vobornik wrote: > Hi Matt, Nathaniel and Simo, > > I'd like to kindly check the status of this effort therefore > resurrecting this thread. > > First, Is the design up to date? Are there still aspects which need > to > be figured out? I do not believe there are any remaining design decisions. > Second execution, I see that Matt is about to finish > https://fedorahosted.org/freeipa/ticket/5782 +1 > Is it planned to handle CLI and Web UI as a part of ticket > https://fedorahosted.org/freeipa/ticket/433? If not then I can file > tickets for it. I plan on doing the CLI work. We need a ticket for UI. This should hopefully be a trivial change. > Will the rest be handled with variation of > https://github.com/npmccallum/freeipa/pull/1 and > https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb6 > 37f66199da7e9225 > Or is an additional patch/work needed? One additional patch is needed for CLI. UI also needs a patch. I will work on the CLI patch and clean up the existing patches. They should be on the list shortly. From pviktori at redhat.com Tue May 3 16:14:39 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 3 May 2016 18:14:39 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <5728B63E.30704@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> <5728AD15.10502@redhat.com> <5728B63E.30704@redhat.com> Message-ID: <5728CE6F.5060202@redhat.com> On 05/03/2016 04:31 PM, Martin Basti wrote: > > > On 03.05.2016 15:52, Petr Viktorin wrote: >> On 05/03/2016 03:02 PM, Petr Spacek wrote: >>> On 2.5.2016 18:02, Martin Basti wrote: >>>> >>>> On 29.04.2016 19:46, Petr Viktorin wrote: >>>>> Hello, >>>>> These patches concentrate on tests, and code that was added/changed >>>>> since I last looked at the FreeIPA project. >>>>> >>>>> With these patches, I'm back to getting the same errors under py2 and >>>>> py3 when in test_xmlrpc. >>>>> >>>>> >>>>> >>>>> >>>> Patch 777: >>>> Could you fix all relative imports and enable check in pylint for that? >>>> (Remove relative-import from pylintrc), IMO there is just one extra >>>> relative >>>> import in custodia module. >> Would it be OK if I do that in a separate patch, in the next batch? This >> one is fixing the tests. >> (I have the change in my worktree, so I won't forget when I next sit >> down to work on IPA.) > It is okay to send it in a next patch :) > ACK on this patch then >>>> Do you plan to use in py2 ? >>>> from__future__importabsolute_import >> I think that's unnecessary boilerplate; the errors this catches are >> easily found by other means. >> And it doesn't guard against someone forgetting the __future__ import >> itself in a new file. The pylint check will be much better. > Ok, just FYI pylint has check that prevents forgetting this import > (disabled in IPA) > >>>> Patch 778: >>>> LGTM >>>> >>>> Patch 779 >>>> LGTM >>>> >>>> Patch 780 >>>> LGTM >>>> >>>> Patch 781 >>>> LGTM >>>> >>>> Patch 782 >>>> Not sure, I will review it longer >>>> >>>> Patch 783 >>>> LGTM >>>> >>>> Patch 784 >>>> LGTM >>>> >>>> Patch 785 >>>> LGTM >>>> >>>> I will test it with both py2 and py3 to convert LGTM to ACK :) >>> Functional ACK, I did not find any breakage (when combined with other >>> Py3 >>> patches). >>> >> > Hold your horses :D, I probably find something in tests > > I run ipa-run-tests with xmlrpc tests under python2 and python3, please > note the different count of tests and errors in py3 > > platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 > -- /usr/bin/python > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > collecting ... collected 1835 items > > platform linux -- Python 3.5.1, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 -- > /bin/python3 > rootdir: /usr/lib/python3.5/site-packages/ipatests, inifile: pytest.ini > collecting ... collected 1694 items / 7 errors > > > Collecting failed on following import errors: > test_xmlrpc/test_add_remove_cert_cmd.py:13: in > ipatests.test_xmlrpc.testcert import get_testcert > xmlrpc/testcert.py:34: in > ipaserver.plugins import rabase > ImportError: No module named 'ipaserver' > > And I found more errors, but they may be unrelated I have to investigate > more > Martin^2 Right, some of the xmlrpc tests use ipaserver, which isn't fully ported yet, and the python3-ipaserver RPM isn't even built. The parts of ipaserver needed for these tests will be my next goal. -- Petr Viktorin From pvoborni at redhat.com Tue May 3 16:20:58 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 3 May 2016 18:20:58 +0200 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1462291892.2517.6.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> <1456503624.6599.401.camel@redhat.com> <1456519442.3136.22.camel@redhat.com> <1456538079.6599.460.camel@redhat.com> <9a554ed0-6802-3c68-0202-2c6960ac914f@redhat.com> <1462291892.2517.6.camel@redhat.com> Message-ID: <3e6cde7b-cefa-1e8c-976e-e35a8eda8d0f@redhat.com> On 05/03/2016 06:11 PM, Nathaniel McCallum wrote: > On Mon, 2016-05-02 at 18:27 +0200, Petr Vobornik wrote: >> Hi Matt, Nathaniel and Simo, >> >> I'd like to kindly check the status of this effort therefore >> resurrecting this thread. >> >> First, Is the design up to date? Are there still aspects which need >> to >> be figured out? > > I do not believe there are any remaining design decisions. > >> Second execution, I see that Matt is about to finish >> https://fedorahosted.org/freeipa/ticket/5782 > > +1 > >> Is it planned to handle CLI and Web UI as a part of ticket >> https://fedorahosted.org/freeipa/ticket/433? If not then I can file >> tickets for it. > > I plan on doing the CLI work. We need a ticket for UI. This should > hopefully be a trivial change. > >> Will the rest be handled with variation of >> https://github.com/npmccallum/freeipa/pull/1 and >> https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39f28eb6 >> 37f66199da7e9225 >> Or is an additional patch/work needed? > > One additional patch is needed for CLI. UI also needs a patch. > > I will work on the CLI patch and clean up the existing patches. They > should be on the list shortly. > Thanks Nathaniel. Web UI ticket created: https://fedorahosted.org/freeipa/ticket/5872 I expect that it will be implemented by me or Pavel V. -- Petr Vobornik From rharwood at redhat.com Tue May 3 16:29:28 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Tue, 03 May 2016 12:29:28 -0400 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Message-ID: David Kupka writes: > --8<------------- trac-ticket-template-proposal ------------------->8-- > Related SW versions: > On server: > {{{ > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server > certmonger > }}} > On client: > {{{ > $ rpm -q freeipa-client krb5-workstation certmonger > }}} I think this is a good idea. However, we are on Debian/family as well now, and I think we want to accept bugs that come from these users as well. So, in the interest of completeness, I believe the corresponding invocations are: > $ dpkg-query -W freeipa-server pki-base 389-ds-base bind9 samba \ > krb5-kdc krb5-admin-server krb5-kpropd Note the split on the krb5 packaging; depending on what piece(s) you're checking for in the RPM krb5-server, this list is probably reducible. > $ dpkg-query -W freeipa-client krb5-user certmonger To give an example of what output of these looks like, here's a run of the server command on a machine that's missing some packages: > rharwood at thriss:~$ dpkg-query -W freeipa-server pki-base 389-ds-base \ > bind9 samba krb5-kdc krb5-admin-server krb5-kpropd > bind9 > krb5-admin-server 1.13.2+dfsg-5 > krb5-kdc 1.13.2+dfsg-5 > samba 2:4.3.8+dfsg-1 > dpkg-query: no packages found matching freeipa-server > dpkg-query: no packages found matching pki-base > dpkg-query: no packages found matching 389-ds-base > dpkg-query: no packages found matching krb5-kpropd > rharwood at thriss:~$ i.e., it has bind9, krb5-admin-server, krb5-kdc, and samba, but is missing the rest of the requested packages. Thanks, --Robbie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 3 16:40:05 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 3 May 2016 18:40:05 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Message-ID: <2cea6550-52af-1f26-f3bf-b9ec4873016f@redhat.com> On 05/03/2016 01:45 PM, David Kupka wrote: > Hello everyone! > > I often miss proper reproducer and other important info in trac tickets. > Asking for the missing info or guessing and trying is as ineffective as > it sounds and costs us a lot of time and effort. I believe we can > improve that. > > We have guidelines for reporting a bug [1] but it obviously isn't > enough. I propose to prefill track ticket's description with following > (or similar) template and be strict on refusing (i.e. closing as > invalid) tickets that are incomplete. > > Any thoughts, suggestions, agreement or disagreement? > > [1] http://www.freeipa.org/page/Troubleshooting#Reporting_bugs > > --8<------------- trac-ticket-template-proposal ------------------->8-- > Related SW versions: > On server: > {{{ > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server > certmonger > }}} > On client: > {{{ > $ rpm -q freeipa-client krb5-workstation certmonger > }}} > > Reproducible: > How often the issue occurs or what special condition is required to be met. > > Examples: > Always / Happened X times of Y tries / Only at noon 29th February when > it's also Thursday / Only on Raspberry Pi > > Steps to reproduce: > Precise description of all related steps you have done. List of commands > to run is the best form. > > Example: > {{{ > # ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.TEST -U > # echo Secret123 | kinit admin > }}} > > > Actual result: > Description of behavior you have observed (error, unexpected warning, ...). > > Example: > {{{ > kinit: Client 'admin at EXAMPLE.TEST' not found in Kerberos database while > getting initial credentials > }}} > > Expected result: > Description of behavior you have expected. > > Example: > TGT for admin user is acquired. > --8<--------------------------------------------------------------->8-- > +1 I would also consider section "Impact". Sometimes it is not clear if the reported just saw a error message but it works otherwise or something doesn't not work at all. Or that an issue blocks half of integration test suite. -- Petr Vobornik From simo at redhat.com Tue May 3 16:53:36 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 May 2016 12:53:36 -0400 Subject: [Freeipa-devel] External trust to AD In-Reply-To: <20160302191103.GQ4492@redhat.com> References: <20160302101333.GI4492@redhat.com> <56D70768.7030907@redhat.com> <20160302191103.GQ4492@redhat.com> Message-ID: <1462294416.3624.26.camel@redhat.com> On Wed, 2016-03-02 at 21:11 +0200, Alexander Bokovoy wrote: > On Wed, 02 Mar 2016, Petr Vobornik wrote: > >On 03/02/2016 11:13 AM, Alexander Bokovoy wrote: > >>Hi, > >> > >>http://www.freeipa.org/page/V4/External_trust_to_AD documents a design > >>for external trust to AD feature. > >> > >>The text is included below for easier review. > >>----------------------------------------------------------------------- > >>{{Feature|version=TODO|ticket=TODO|author=Ab}} > >> > >>== Overview == > >>Support for external trust to a domain from Active Directory forest > >> > >>An external trust is a trust relationship between Active Directory > >>domains that are in different Active Directory forests. While forest > >>trust always requires to establish trust between root domains of the > >>Active Directory forests, external trust can be established to any > >>domain within the forest. > >> > >>== Use Cases == > >> > >>As an Active Directory domain admin, I want to establish trust between > >>IPA and my domain only. The trust between IPA and an external Active > >>Directory domain will be non-transitive as no users or groups from other > >>Active Directory domains will have access to IPA resources. > >> > >>== Design== > >> > >>External trust between Active Directory domains is by definition > >>non-transitive and enforces SID filtering between the domain boundaries. > >>This means only users and groups with SIDs from the trusted domain can > >>use the resources and be visible on IPA systems. None of other users and > >>groups from domains the trusted domain trusts within its own Active > >>Directory forest or other externally trusted domains will be allowed to > >>access IPA resources. > >> > >>== Implementation == > >> > >>External trust feature re-uses existing forest trust infrastructure. > >>There are several specific changes to allow supporting external trust: > >>* '''Non-transitivity''': since external trust is non-transitive by > >>* definition, any attempt to set transitivity feature of the trust link > >>* with LSA SetInformationTrustedDomain() command will fail. Thus, there > >>* is no need to set transitivity for the external trust. > > > >Sounds very simple :) > > > >Do I get it right that it is possible to do it today? Because now the > >code just do: > > root_logger.error('unable to set trust to transitive: %s' % (str(e))) > > pass > I have a patchset to add this support already. I want to clean up some > parts of it, namely, reporting of the resulting trust type, but it all works. > > > > >>* '''Trust attributes''': external trust can be detected by looking into > >>* absense of ipaNTTrustAttributes LDAP attribute of the trusted domain > >>* object. > >> > >>== Feature Management == > >> > >>=== UI === > >>An option 'external trust' needs to be added to Web UI, corresponding to > >>'--external' flag in 'trust-add' command in CLI. > >> > >>=== CLI === > >>An external trust creation can be requested by passing additional flag > >>'--external=true' to the 'trust-add' command. The flag defaults to > >>'false', e.g. no external trust would be created. > >> > >>{| class="wikitable" > >>|- > >>! Command > >>! Options > >>|- > >>| trust-add > >>| --external=true/false > >>|} > > > >We should also add 'external' param to output of trust_find and > >trust_show + corresponding change in Web UI and CLI. > It will be part of trust type string, not a separate param. I reviewed the design and associated tickts, and all checks out for me. I have only one nitpick that is not spelled out. What happens if someone has a forest trust and tries to also set up an external trust with a child domain of the existing forest trust ? Do we need to add code to prevent it, or should we allow it ? Secondary nitpick that came to mind right now, will one-way external trust also be allowed/supported in the first implementation ? I have some ideas on the answers to the above questions, but I think they should be put in the design as considerations and explained there. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue May 3 17:02:13 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 May 2016 20:02:13 +0300 Subject: [Freeipa-devel] External trust to AD In-Reply-To: <1462294416.3624.26.camel@redhat.com> References: <20160302101333.GI4492@redhat.com> <56D70768.7030907@redhat.com> <20160302191103.GQ4492@redhat.com> <1462294416.3624.26.camel@redhat.com> Message-ID: <20160503170213.o65cgwnpx76wqafs@redhat.com> On Tue, 03 May 2016, Simo Sorce wrote: >On Wed, 2016-03-02 at 21:11 +0200, Alexander Bokovoy wrote: >> On Wed, 02 Mar 2016, Petr Vobornik wrote: >> >On 03/02/2016 11:13 AM, Alexander Bokovoy wrote: >> >>Hi, >> >> >> >>http://www.freeipa.org/page/V4/External_trust_to_AD documents a design >> >>for external trust to AD feature. >> >> >> >>The text is included below for easier review. >> >>----------------------------------------------------------------------- >> >>{{Feature|version=TODO|ticket=TODO|author=Ab}} >> >> >> >>== Overview == >> >>Support for external trust to a domain from Active Directory forest >> >> >> >>An external trust is a trust relationship between Active Directory >> >>domains that are in different Active Directory forests. While forest >> >>trust always requires to establish trust between root domains of the >> >>Active Directory forests, external trust can be established to any >> >>domain within the forest. >> >> >> >>== Use Cases == >> >> >> >>As an Active Directory domain admin, I want to establish trust between >> >>IPA and my domain only. The trust between IPA and an external Active >> >>Directory domain will be non-transitive as no users or groups from other >> >>Active Directory domains will have access to IPA resources. >> >> >> >>== Design== >> >> >> >>External trust between Active Directory domains is by definition >> >>non-transitive and enforces SID filtering between the domain boundaries. >> >>This means only users and groups with SIDs from the trusted domain can >> >>use the resources and be visible on IPA systems. None of other users and >> >>groups from domains the trusted domain trusts within its own Active >> >>Directory forest or other externally trusted domains will be allowed to >> >>access IPA resources. >> >> >> >>== Implementation == >> >> >> >>External trust feature re-uses existing forest trust infrastructure. >> >>There are several specific changes to allow supporting external trust: >> >>* '''Non-transitivity''': since external trust is non-transitive by >> >>* definition, any attempt to set transitivity feature of the trust link >> >>* with LSA SetInformationTrustedDomain() command will fail. Thus, there >> >>* is no need to set transitivity for the external trust. >> > >> >Sounds very simple :) >> > >> >Do I get it right that it is possible to do it today? Because now the >> >code just do: >> > root_logger.error('unable to set trust to transitive: %s' % (str(e))) >> > pass >> I have a patchset to add this support already. I want to clean up some >> parts of it, namely, reporting of the resulting trust type, but it all works. >> >> > >> >>* '''Trust attributes''': external trust can be detected by looking into >> >>* absense of ipaNTTrustAttributes LDAP attribute of the trusted domain >> >>* object. >> >> >> >>== Feature Management == >> >> >> >>=== UI === >> >>An option 'external trust' needs to be added to Web UI, corresponding to >> >>'--external' flag in 'trust-add' command in CLI. >> >> >> >>=== CLI === >> >>An external trust creation can be requested by passing additional flag >> >>'--external=true' to the 'trust-add' command. The flag defaults to >> >>'false', e.g. no external trust would be created. >> >> >> >>{| class="wikitable" >> >>|- >> >>! Command >> >>! Options >> >>|- >> >>| trust-add >> >>| --external=true/false >> >>|} >> > >> >We should also add 'external' param to output of trust_find and >> >trust_show + corresponding change in Web UI and CLI. >> It will be part of trust type string, not a separate param. > > >I reviewed the design and associated tickts, and all checks out for me. >I have only one nitpick that is not spelled out. > >What happens if someone has a forest trust and tries to also set up an >external trust with a child domain of the existing forest trust ? > >Do we need to add code to prevent it, or should we allow it ? I think we should prevent it. This is currently a bit unclear because I'm trying to come to a common ground in understanding trust namespace conflicts with Samba AD DC and Windows. The way Metze implemented conflict checking in Samba AD DC is against Windows rules and I plan to clear it during SambaXP so that we have common logic. Once the logic is defined, I can run verification using the algorithm implemented in Samba. >Secondary nitpick that came to mind right now, will one-way external >trust also be allowed/supported in the first implementation ? Yes, it will -- the implementation I currently have is orthogonal to one-way/two-way trust types. >I have some ideas on the answers to the above questions, but I think >they should be put in the design as considerations and explained there. I agree, I'll add clarifications once everything is clear. -- / Alexander Bokovoy From lslebodn at redhat.com Tue May 3 21:24:41 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 3 May 2016 23:24:41 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> Message-ID: <20160503212440.GB9681@10.4.128.1> On (03/05/16 12:29), Robbie Harwood wrote: >David Kupka writes: > >> --8<------------- trac-ticket-template-proposal ------------------->8-- >> Related SW versions: >> On server: >> {{{ >> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >> certmonger >> }}} >> On client: >> {{{ >> $ rpm -q freeipa-client krb5-workstation certmonger >> }}} > >I think this is a good idea. However, we are on Debian/family as well >now, and I think we want to accept bugs that come from these users as >well. So, in the interest of completeness, I believe the corresponding >invocations are: > >> $ dpkg-query -W freeipa-server pki-base 389-ds-base bind9 samba \ >> krb5-kdc krb5-admin-server krb5-kpropd > >Note the split on the krb5 packaging; depending on what piece(s) you're >checking for in the RPM krb5-server, this list is probably reducible. > >> $ dpkg-query -W freeipa-client krb5-user certmonger > >To give an example of what output of these looks like, here's a run of >the server command on a machine that's missing some packages: > >> rharwood at thriss:~$ dpkg-query -W freeipa-server pki-base 389-ds-base \ >> bind9 samba krb5-kdc krb5-admin-server krb5-kpropd >> bind9 >> krb5-admin-server 1.13.2+dfsg-5 >> krb5-kdc 1.13.2+dfsg-5 >> samba 2:4.3.8+dfsg-1 >> dpkg-query: no packages found matching freeipa-server >> dpkg-query: no packages found matching pki-base >> dpkg-query: no packages found matching 389-ds-base >> dpkg-query: no packages found matching krb5-kpropd >> rharwood at thriss:~$ > >i.e., it has bind9, krb5-admin-server, krb5-kdc, and samba, but is >missing the rest of the requested packages. > FreeIPA is heavily patched on debian and has quite old version there 4.0.5. The better would be recommend to reproduce with upstream version (fedora/CentOS). LS From rharwood at redhat.com Tue May 3 22:48:26 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Tue, 03 May 2016 18:48:26 -0400 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160503212440.GB9681@10.4.128.1> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> Message-ID: Lukas Slebodnik writes: > On (03/05/16 12:29), Robbie Harwood wrote: >>David Kupka writes: >> >>> --8<------------- trac-ticket-template-proposal ------------------->8-- >>> Related SW versions: >>> On server: >>> {{{ >>> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >> >> I think this is a good idea. However, we are on Debian/family as >> well now, and I think we want to accept bugs that come from these >> users as well. > > FreeIPA is heavily patched on debian and has quite old version there > 4.0.5. > > The better would be recommend to reproduce with upstream version > (fedora/CentOS). (FreeIPA 4.1.4 is available on Debian, but your point still stands.) In summary: I don't like that upstream is conflated with fedora/CentOS. Of course I understand that this was done to ease development and not out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be less of an afterthought because I believe we can attract users to our product. I believe this to be especially true with working freeipa-client on those distros, which we now have and I am very happy about. Ultimately, it's not a huge issue. Users who are able to build from source very likely also know their package manager and how to translate the invocations. And if they're not building from source, then the bug should go downstream first regardless. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 4 00:21:22 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 4 May 2016 10:21:22 +1000 Subject: [Freeipa-devel] #5836 [RFE] Allow profile to specify default CA Message-ID: <20160504002122.GL1237@dhcp-40-8.bne.redhat.com> Continuing the discussion for #5836[1] as requested from triage session. [1] https://fedorahosted.org/freeipa/ticket/5836 IMO it is not important for FreeIPA 4.4. It is nice to have but I doubt it will make it. Honza suggested it should be the other way around, i.e. CA specifies default profile rather than profile specifies default CA. The fact (also raised by Christian) is that multiple profiles may be used with a single CA, and vice-versa. CA ACLs will govern what combinations are acceptable. Thinking from user perspective, there are a couple of things to consider: - Currently, to request a particular kind of cert, user must specify a profile ID. - It is more natural to ask for a particular profile and have the request dispatched to a profile-specified default CA, than to ask for a cert issued by a particular CA, and a CA-specified default profile will be used. Given these points, I am strongly in favour of having the profile indicate the default CA - not the other way around. Cheers, Fraser From redhatrises at gmail.com Wed May 4 00:32:31 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 3 May 2016 18:32:31 -0600 Subject: [Freeipa-devel] [PATCH] 0001 provide more information for "ipa cert-revoke -h" In-Reply-To: References: <72b3ecbf-68bb-cf4a-26e4-855568064f2e@gmail.com> <5728B211.8080101@redhat.com> <5728B8A8.6070608@redhat.com> Message-ID: On Tue, May 3, 2016 at 9:35 AM, Patrice Duc-Jacquet < patrice.duc.jacquet at gmail.com> wrote: > On 05/03/2016 04:41 PM, Rob Crittenden wrote: > > Gabe Alford wrote: >> >>> Hello, >>> >>> Thank you for your patch as well. >>> >>> >- doc=_('Reason for revoking the certificate (0-10)'), >>> >+ doc=_('Reason for revoking the certificate (0-10). See >>> RFC 5280 (paragraph 5.3.1) for reason details'), >>> >>> Rather than just specifying the RFC with the paragraph to go look up, >>> can you either add the revocation options or say something like: >>> >>> + doc=_('Reason for revoking the certificate (0-10). See >>> \'ipa help cert\' for revocation reason details.'), >>> >>> IMO, it is a little annoying to go look up revocation reasons when those >>> reasons can either be added to the help output or exist already in `ipa >>> help cert`. >>> >> >> FTR I added it to the top level help because the reasons are used in >> multiple places and didn't want to duplicate them, and adding them to a >> specific option help would overload it big time IMHO. >> >> rob >> >> Hi everyone > thanks for your valuable comments. I fully agree that it is not > recommended to duplicate this information. So as Rob suggested, I should > avoid to add this information to cert_revoke option and thus I plan to > modify the help message as follow: > > doc=_('Reason for revoking the certificate (0-10). Type "ipa help cert" > for reason details'), > > Do you agree with that modification? Thanks in advance and regards > I think the modification is fine. One nitpick that I would have is to say "for revocation reason details." rather than "for reason details." Also, don't forget a period after the word "details". :) Gabe > > Pat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed May 4 03:47:41 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 3 May 2016 21:47:41 -0600 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5857 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0069-ipa-nis-manage-enable-change-service-name-from-portm.patch Type: text/x-patch Size: 1990 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 4 04:04:05 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 4 May 2016 14:04:05 +1000 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <20160503070558.GJ1237@dhcp-40-8.bne.redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> <20160503070558.GJ1237@dhcp-40-8.bne.redhat.com> Message-ID: <20160504040405.GN1237@dhcp-40-8.bne.redhat.com> On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: > On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > > On 21.4.2016 05:30, Fraser Tweedale wrote: > > >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > > >>Hi all, > > >> > > >>The attached patches configure lightweight CA key replication on IPA > > >>CAs, on upgrade and installation. > > >> > > >>Patches 0051..0052 from my other mail are also needed for the system > > >>to work, but this patchset does not depend on them and can be > > >>reviewed independently. > > >> > > >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > > >>- it just puts the necessary principals/keys/configuration in place. > > >> > > >>Cheers, > > >>Fraser > > >> > > >New patches attached; 0054-2 changes the service name from > > >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > > >principal to search server Custodia keys. > > > Honza, thanks for review. Comments inline. > > > Patch 53: > > > > I'm not sure about this approach - the cn of custodia keys in LDAP is a > > free-form string, I would not tie it to service names, but rather try to > > keep it short. > > > > In the key replication section of the design page, you mention "ca/$NAME", I > > think this is a good template for the cn and that we should stick to it. > > > This scheme (or something like it, *without* '/' as the separator) > is needed to satisfy the ACI that allows host principals to manage > Custodia keys: > > add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > The CN must contain the hostname, and we must also disambiguate on > key type. The current scheme is: > > {sig,enc}~dogtag/ > e.g. > enc~dogtag/f23-2.ipa.local > > The first separator cannot be '/' because the '*' wildcard in the > ACI is not greedy - the captured text would include the servicename > and fail to match any userdn. > > If you do not like '~' feel free to suggest a different symbol :) > The alternative is to add more ACIs. > > > > > Patch 54: > > > > 1) This belongs to CAInstance.configure_instance(): > > > > + CA = cainstance.CAInstance( > > + api.env.realm, certs.NSS_DIR, host_name=api.env.host) > > + CA.setup_lightweight_ca_key_retrieval() > > > See comments for (5). > > > > > 2) Any ACI changes should be in a separate patch. (What happened to patch > > 52?) > > > Patch 52 added an ACI that allowed any authenticated user to see the > keys. Simo wanted it limited it to the Dogtag principal so I > rescinded patch 52 and added the ACI in the same patch where the > principal was added. > > Separate patch is no problem; I will resurrect number 52. > > > > > 3) This is not a platform constant, just a constant: > > > > + PKI_GSSAPI_SERVICE_NAME = 'dogtag' > > > Thanks, will put it in `ipalib.constants'. > > > > > 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please > > split it into a "setup keytab" and "setup custodia" parts. > > > Will extract methods for next patchset. > > > > > 5) This also belongs to CAInstance.configure_instance(): > > > > + if setup_ca: > > + # CA was configured before Kerberos; > > + # add Custodia client princ and keys now > > + ca_instance.setup_lightweight_ca_key_retrieval() > > > > In order for that to work, you need to move the ca.install_step_1() after > > krb.create_instance(), but that should be OK, since KrbInstance does not > > talk to the CA. > > > `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which > fails if called before `krb.create_instance' due to missing > krb5.conf:: > > 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local at IPA.LOCAL -x ipa-setup-override-restrictions > 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 > 2016-05-03T06:29:23Z DEBUG stdout= > 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm > > Moving `ca.install_step_1()' to after `krb.create_instance()' does > not help, because `CAInstance.configure_instance' is called from > `ca.install_step_0()'. > > However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' > *directly* from `ca.install_step_1' would probably work. Are you > happy with putting it there, instead of `configure_instance()'? > > Cheers, > Fraser > Updated patches attached, include bringing back 0052-2 for the ACI change. Cheers, Fraser -------------- next part -------------- From 3d047e3dc1e7f700751c0f52f26326764b70d94d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 3 May 2016 13:22:39 +1000 Subject: [PATCH] Allow Dogtag service principals to read Custodia keys The "dogtag/$HOSTNAME@$REALM" service principal uses Custodia to retrieve lightweight CA signing keys, and therefore needs search and read access to Custodia keys. Add an ACI to permit this. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/updates/20-aci.update | 3 +++ 1 file changed, 3 insertions(+) diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 4802ae0458e8b870bf3127764ebabac1a48f7cf2..2e9a36da442c392c9161861615b1744eeb6b799c 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -136,3 +136,6 @@ add:aci: (target = "ldap:///cn=replication,cn=etc,$SUFFIX")(targetattr = "nsDS5R dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# Dogtag service principals can search Custodia keys +add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Dogtag service principals can search Custodia keys"; allow(read, search, compare) userdn = "ldap:///krbprincipalname=dogtag/*@$REALM,cn=services,cn=accounts,$SUFFIX";) -- 2.5.5 -------------- next part -------------- From b303284245627e4214d1ba3d03bdb06fc89c3a53 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 12:42:35 +1000 Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs Lightweight CAs support introduces new service principals for Dogtag, with Custodia keys. The current Custodia key creation uses a DN that contains only they key type and the hostname, so keys for multiple services on the same host cannot be created. Add the 'generate_keys' method to generate keys for a host or an arbitrary service. When a service name is given, include the service name in the DN. This change does not affect searching because all searching is done using the ipaKeyUsage and memberPrincipal attributes. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipapython/secrets/kem.py | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py index 1025ed7980f055c82c602634e8845fa490cf0514..533121779241d30e19fef4c050bb69c55d29ec22 100644 --- a/ipapython/secrets/kem.py +++ b/ipapython/secrets/kem.py @@ -105,10 +105,11 @@ class KEMLdap(iSecLdap): encoding=serialization.Encoding.DER, format=serialization.PublicFormat.SubjectPublicKeyInfo) - def set_key(self, usage, host, principal, key): + def set_key(self, usage, servicename, host, principal, key): public_key = self._format_public_key(key) conn = self.connect() - name = '%s/%s' % (KEY_USAGE_MAP[usage], host) + service_segment = '~' + servicename if servicename else '' + name = '%s%s/%s' % (KEY_USAGE_MAP[usage], service_segment, host) dn = 'cn=%s,%s' % (name, self.keysbase) try: mods = [('objectClass', ['nsContainer', @@ -170,15 +171,18 @@ class IPAKEMKeys(KEMKeysStore): return conn.get_key(usage, kid) def generate_server_keys(self): - principal = 'host/%s@%s' % (self.host, self.realm) + self.generate_keys() + + def generate_keys(self, servicename=None): + principal = '%s/%s@%s' % (servicename or 'host', self.host, self.realm) # Neutralize the key with read if any self._server_keys = None # Generate private key and store it pubkeys = newServerKeys(self.config['server_keys'], principal) # Store public key in LDAP ldapconn = KEMLdap(self.ldap_uri) - ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) - ldapconn.set_key(KEY_USAGE_ENC, self.host, principal, pubkeys[1]) + ldapconn.set_key(KEY_USAGE_SIG, servicename, self.host, principal, pubkeys[0]) + ldapconn.set_key(KEY_USAGE_ENC, servicename, self.host, principal, pubkeys[1]) @property def server_keys(self): -- 2.5.5 -------------- next part -------------- From d38f29d48da644d9cdb9455384ee4ae107e9acc0 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 16:47:33 +1000 Subject: [PATCH 54/54] Setup lightweight CA key retrieval on install/upgrade To configure Dogtag lightweight CA key replication on installation and upgrade: - add the 'dogtag/$HOSTNAME' service principal - create the pricipal's Custodia keys - retrieve keytab - configure the IPACustodiaKeyRetriever in CS.cfg Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipalib/constants.py | 1 + ipaserver/install/ca.py | 9 ++++++- ipaserver/install/cainstance.py | 52 +++++++++++++++++++++++++++++++++++++ ipaserver/install/server/install.py | 6 ++--- ipaserver/install/server/upgrade.py | 6 ++++- 5 files changed, 69 insertions(+), 5 deletions(-) diff --git a/ipalib/constants.py b/ipalib/constants.py index 021f18cd366b821427bdbfcc5e354d2047ef39b1..d544595898e52d3910cff94fc3cc0276fe099a98 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -261,3 +261,4 @@ REPL_AGMT_STRIP_ATTRS = ('modifiersName', DOMAIN_SUFFIX_NAME = 'domain' CA_SUFFIX_NAME = 'ca' +PKI_GSSAPI_SERVICE_NAME = 'dogtag' diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py index acc54334e1b6e64a0b2d4b097e7464c95988f3f5..4d25af5870ce7a130c996d1e7de4a05c2167d494 100644 --- a/ipaserver/install/ca.py +++ b/ipaserver/install/ca.py @@ -182,7 +182,7 @@ def install_step_1(standalone, replica_config, options): basedn = ipautil.realm_to_suffix(realm_name) - ca = cainstance.CAInstance(realm_name, certs.NSS_DIR) + ca = cainstance.CAInstance(realm_name, certs.NSS_DIR, host_name=host_name) if standalone: ca.stop('pki-tomcat') @@ -193,6 +193,13 @@ def install_step_1(standalone, replica_config, options): # This is done within stopped_service context, which restarts CA ca.enable_client_auth_to_db(paths.CA_CS_CFG_PATH) + # Lightweight CA key retrieval is configured in step 1 instead + # of CAInstance.configure_instance (which is invoked from step + # 0) because kadmin_addprinc fails until krb5.conf is installed + # by krb.create_instance. + # + ca.setup_lightweight_ca_key_retrieval() + if standalone and replica_config is None: serverid = installutils.realm_to_serverid(realm_name) dirname = dsinstance.config_dirname(serverid) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a21f7d2671461dfb99797d39fc7ee5706317241f..ec31283972d84f0b682bea444a70286585fa489e 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -45,6 +45,7 @@ from six.moves.configparser import ConfigParser, RawConfigParser from ipalib import api from ipalib import pkcs10, x509 from ipalib import errors +import ipalib.constants from ipaplatform import services from ipaplatform.constants import constants @@ -59,6 +60,7 @@ from ipapython.certdb import get_ca_nickname from ipapython.dn import DN from ipapython.ipa_log_manager import log_mgr,\ standard_logging_setup, root_logger +from ipapython.secrets.kem import IPAKEMKeys from ipaserver.install import certs from ipaserver.install import dsinstance @@ -66,6 +68,7 @@ from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import replication from ipaserver.install import service +from ipaserver.install import sysupgrade from ipaserver.install.dogtaginstance import (export_kra_agent_pem, DogtagInstance) from ipaserver.plugins import ldap2 @@ -1356,11 +1359,60 @@ class CAInstance(DogtagInstance): self.step("updating IPA configuration", update_ipa_conf) self.step("Restart HTTP server to pick up changes", self.__restart_http_instance) + self.step("Configure lightweight CA key retrieval", + self.setup_lightweight_ca_key_retrieval) self.step("enabling CA instance", self.__enable_instance) self.start_creation(runtime=210) + def setup_lightweight_ca_key_retrieval(self): + if sysupgrade.get_upgrade_state('dogtag', 'setup_lwca_key_retrieval'): + return + + root_logger.info('[Set up lightweight CA key retrieval]') + + self.__setup_lightweight_ca_key_retrieval_kerberos() + self.__setup_lightweight_ca_key_retrieval_custodia() + + root_logger.info('Configuring key retriever') + installutils.set_directive( + paths.CA_CS_CFG_PATH, + 'features.authority.keyRetrieverClass', + 'com.netscape.ca.IPACustodiaKeyRetriever', + quotes=False, separator='=') + + sysupgrade.set_upgrade_state('dogtag', 'setup_lwca_key_retieval', True) + + def __setup_lightweight_ca_key_retrieval_kerberos(self): + service = ipalib.constants.PKI_GSSAPI_SERVICE_NAME + principal = '{}/{}@{}'.format(service, api.env.host, self.realm) + pent = pwd.getpwnam(constants.PKI_USER) + + root_logger.info('Creating principal') + installutils.kadmin_addprinc(principal) + self.suffix = ipautil.realm_to_suffix(self.realm) + if not self.admin_conn: + self.ldap_connect() + self.move_service(principal) + + root_logger.info('Retrieving keytab') + keytab = os.path.join(paths.PKI_TOMCAT, service + '.keytab') + installutils.create_keytab(keytab, principal) + os.chmod(keytab, 0o600) + os.chown(keytab, pent.pw_uid, pent.pw_gid) + + def __setup_lightweight_ca_key_retrieval_custodia(self): + service = ipalib.constants.PKI_GSSAPI_SERVICE_NAME + pent = pwd.getpwnam(constants.PKI_USER) + + root_logger.info('Creating Custodia keys') + keyfile = os.path.join(paths.PKI_TOMCAT, service + '.keys') + keystore = IPAKEMKeys({'server_keys': keyfile}) + keystore.generate_keys(service) + os.chmod(keyfile, 0o600) + os.chown(keyfile, pent.pw_uid, pent.pw_gid) + def replica_ca_install_check(config): if not config.setup_ca: diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index 2d71b3837214683566f37644c41a680953a64207..9f5219887c671f2663a791068d6383ab18443265 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -891,9 +891,6 @@ def install(installer): # we now need to enable ssl on the ds ds.enable_ssl() - if setup_ca: - ca.install_step_1(False, None, options) - krb = krbinstance.KrbInstance(fstore) if options.pkinit_cert_files: krb.create_instance(realm_name, host_name, domain_name, @@ -907,6 +904,9 @@ def install(installer): setup_pkinit=not options.no_pkinit, subject_base=options.subject) + if setup_ca: + ca.install_step_1(False, None, options) + # The DS instance is created before the keytab, add the SSL cert we # generated ds.add_cert_to_service() diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 4f3a2cb065319a26bfa517b4d1d2cb4b41fb486d..f2e01b546d4be0177eeee1e6a264586321646015 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1467,7 +1467,8 @@ def upgrade_configuration(): if subject_base: sub_dict['SUBJECT_BASE'] = subject_base - ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) + ca = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) with installutils.stopped_service('pki-tomcatd', 'pki-tomcat'): # Dogtag must be stopped to be able to backup CS.cfg config @@ -1663,6 +1664,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + ca.setup_lightweight_ca_key_retrieval() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 From akasurde at redhat.com Wed May 4 05:17:57 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 4 May 2016 10:47:57 +0530 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: Message-ID: <57298605.60203@redhat.com> Hi Gabe, I am wondering, how are we handling "CalledProcessError" exception ? On 05/04/2016 09:17 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5857 > > Thanks, > > Gabe > > Thanks, Abhijeet Kasurde -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Wed May 4 06:35:35 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 4 May 2016 08:35:35 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> Message-ID: <20160504063535.GA13751@10.4.128.1> On (03/05/16 18:48), Robbie Harwood wrote: >Lukas Slebodnik writes: > >> On (03/05/16 12:29), Robbie Harwood wrote: >>>David Kupka writes: >>> >>>> --8<------------- trac-ticket-template-proposal ------------------->8-- >>>> Related SW versions: >>>> On server: >>>> {{{ >>>> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >>> >>> I think this is a good idea. However, we are on Debian/family as >>> well now, and I think we want to accept bugs that come from these >>> users as well. >> >> FreeIPA is heavily patched on debian and has quite old version there >> 4.0.5. >> >> The better would be recommend to reproduce with upstream version >> (fedora/CentOS). > >(FreeIPA 4.1.4 is available on Debian, but your point still stands.) > 4.1.4 is only in experimental. and sid(ustable) has only 4.0.5 Neither of these versions has long term support from upstream point of view. And try to look into patches http://anonscm.debian.org/cgit/pkg-freeipa/freeipa.git/tree/debian/patches >In summary: I don't like that upstream is conflated with fedora/CentOS. >Of course I understand that this was done to ease development and not >out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be >less of an afterthought because I believe we can attract users to our >product. I believe this to be especially true with working >freeipa-client on those distros, which we now have and I am very happy >about. > If freeipa get to the state that there will not be any non-upstream patches in distibutions then we will not consider Fedora as upstream. It might easily happen that non-upstream patch caused a bug. BTW sssd is already in such state. Therefore we needn't care about distribution; we just need to know the version of sssd. Fell free to send patches if you want to have debian as 1st class citizen for freeipa-server. LS From patduc38 at gmail.com Wed May 4 07:35:56 2016 From: patduc38 at gmail.com (Patrice Duc-Jacquet) Date: Wed, 4 May 2016 09:35:56 +0200 Subject: [Freeipa-devel] [PATCH] 0001 (update 2) provide more information for "ipa cert-revoke -h" Message-ID: <0ffbca59-c6ad-3f82-a4c6-127f0b8365e6@gmail.com> Hi everyone this is a second update that take into account review feedback. In case the proposal fix is K what are the next step to commit this change. I'm not sure to really understand the process. Thanks and regards Pat -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pducjac-0001-2-Add-more-information-regarding-where-to-find-revocat.patch Type: text/x-patch Size: 1952 bytes Desc: not available URL: From abokovoy at redhat.com Wed May 4 08:05:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 May 2016 11:05:50 +0300 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> Message-ID: <20160504080550.x2ilcs6vdvyac3a2@redhat.com> On Tue, 03 May 2016, Robbie Harwood wrote: >Lukas Slebodnik writes: > >> On (03/05/16 12:29), Robbie Harwood wrote: >>>David Kupka writes: >>> >>>> --8<------------- trac-ticket-template-proposal ------------------->8-- >>>> Related SW versions: >>>> On server: >>>> {{{ >>>> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >>> >>> I think this is a good idea. However, we are on Debian/family as >>> well now, and I think we want to accept bugs that come from these >>> users as well. >> >> FreeIPA is heavily patched on debian and has quite old version there >> 4.0.5. >> >> The better would be recommend to reproduce with upstream version >> (fedora/CentOS). > >(FreeIPA 4.1.4 is available on Debian, but your point still stands.) > >In summary: I don't like that upstream is conflated with fedora/CentOS. >Of course I understand that this was done to ease development and not >out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be >less of an afterthought because I believe we can attract users to our >product. I believe this to be especially true with working >freeipa-client on those distros, which we now have and I am very happy >about. I think you miss context here. There was huge amount of work done in last couple months to get FreeIPA 4.3 running on Ubuntu and Debian. It made to Ubuntu 16.04. It didn't make to Debian proper yet for a single reason: FreeIPA tarball ships with a minified JS code for parts of the web UI framework which is against some of Debian policies and therefore FreeIPA is blocked from entering Debian. There are people like Timo Aaltonen who work on the Debian/Ubuntu support but they cannot do everything on their own. JS code issue is unique to Debian so ideally someone would need to contribute fixes that are right from Debian point of view but nobody did it so far. You are welcome. -- / Alexander Bokovoy From lslebodn at redhat.com Wed May 4 08:41:23 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 4 May 2016 10:41:23 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160504080550.x2ilcs6vdvyac3a2@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> <20160504080550.x2ilcs6vdvyac3a2@redhat.com> Message-ID: <20160504084123.GB21729@10.4.128.1> On (04/05/16 11:05), Alexander Bokovoy wrote: >On Tue, 03 May 2016, Robbie Harwood wrote: >> Lukas Slebodnik writes: >> >> > On (03/05/16 12:29), Robbie Harwood wrote: >> > > David Kupka writes: >> > > >> > > > --8<------------- trac-ticket-template-proposal ------------------->8-- >> > > > Related SW versions: >> > > > On server: >> > > > {{{ >> > > > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >> > > >> > > I think this is a good idea. However, we are on Debian/family as >> > > well now, and I think we want to accept bugs that come from these >> > > users as well. >> > >> > FreeIPA is heavily patched on debian and has quite old version there >> > 4.0.5. >> > >> > The better would be recommend to reproduce with upstream version >> > (fedora/CentOS). >> >> (FreeIPA 4.1.4 is available on Debian, but your point still stands.) >> >> In summary: I don't like that upstream is conflated with fedora/CentOS. >> Of course I understand that this was done to ease development and not >> out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be >> less of an afterthought because I believe we can attract users to our >> product. I believe this to be especially true with working >> freeipa-client on those distros, which we now have and I am very happy >> about. >I think you miss context here. There was huge amount of work done in >last couple months to get FreeIPA 4.3 running on Ubuntu and Debian. It >made to Ubuntu 16.04. It didn't make to Debian proper yet for a single >reason: FreeIPA tarball ships with a minified JS code for parts of the >web UI framework which is against some of Debian policies and therefore >FreeIPA is blocked from entering Debian. > I think you misses context here. The porpose of reporting bugs to upstream is to file bugs to upstream version. If the downstream version is patched with non-upstream patches then you need to find out wheter bug is in upstream or downstream caused by non-upstream patches. And it should be task of reporter to ensure that bug is in upstream. ATM the easiest way is to test with fedora. >There are people like Timo Aaltonen who work on the Debian/Ubuntu >support but they cannot do everything on their own. JS code issue is >unique to Debian so ideally someone would need to contribute fixes that >are right from Debian point of view but nobody did it so far. You are >welcome. > I contributed in past :-) but into C related code. As I mentioned in previous mail. If freeipa get to the state that debian has pure upstream version then we can recommend to report bugs + exact version with dpkg-query The purpose of David's mail was to simplify job for developers and developers life will not be easier if developer need to find out wheter bug is in upstream or it's caused by downstream patches. LS From pspacek at redhat.com Wed May 4 08:43:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 4 May 2016 10:43:21 +0200 Subject: [Freeipa-devel] [PATCH 0110] DNS: Warn if forwarding policy conflicts with automatic empty zone Message-ID: <44b60702-e8cb-364f-39bc-114404349972@redhat.com> Hello, DNS: Warn if forwarding policy conflicts with automatic empty zones Forwarding policy "first" or "none" may conflicts with some automatic empty zones. Queries for zones specified by RFC 6303 will ignore forwarding and recursion and always result in NXDOMAIN answers. This is not detected and warned about. Global forwarding is equivalent to forward zone ".". Example: Forward zone 1.10.in-addr.arpa with policy "first" will not forward anything because BIND will automatically prefer automatic empty zone "10.in-addr.arpa." which is authoritative. https://fedorahosted.org/freeipa/ticket/5710 This is last patch in the series so the ticket can be closed when all relevant patches are pushed. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0110-DNS-Warn-if-forwarding-policy-conflicts-with-automat.patch Type: text/x-patch Size: 4999 bytes Desc: not available URL: From abokovoy at redhat.com Wed May 4 09:56:29 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 May 2016 12:56:29 +0300 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160504084123.GB21729@10.4.128.1> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> <20160504080550.x2ilcs6vdvyac3a2@redhat.com> <20160504084123.GB21729@10.4.128.1> Message-ID: <20160504095629.fisi6bdvwvyiiyvv@redhat.com> On Wed, 04 May 2016, Lukas Slebodnik wrote: >On (04/05/16 11:05), Alexander Bokovoy wrote: >>On Tue, 03 May 2016, Robbie Harwood wrote: >>> Lukas Slebodnik writes: >>> >>> > On (03/05/16 12:29), Robbie Harwood wrote: >>> > > David Kupka writes: >>> > > >>> > > > --8<------------- trac-ticket-template-proposal ------------------->8-- >>> > > > Related SW versions: >>> > > > On server: >>> > > > {{{ >>> > > > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >>> > > >>> > > I think this is a good idea. However, we are on Debian/family as >>> > > well now, and I think we want to accept bugs that come from these >>> > > users as well. >>> > >>> > FreeIPA is heavily patched on debian and has quite old version there >>> > 4.0.5. >>> > >>> > The better would be recommend to reproduce with upstream version >>> > (fedora/CentOS). >>> >>> (FreeIPA 4.1.4 is available on Debian, but your point still stands.) >>> >>> In summary: I don't like that upstream is conflated with fedora/CentOS. >>> Of course I understand that this was done to ease development and not >>> out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be >>> less of an afterthought because I believe we can attract users to our >>> product. I believe this to be especially true with working >>> freeipa-client on those distros, which we now have and I am very happy >>> about. >>I think you miss context here. There was huge amount of work done in >>last couple months to get FreeIPA 4.3 running on Ubuntu and Debian. It >>made to Ubuntu 16.04. It didn't make to Debian proper yet for a single >>reason: FreeIPA tarball ships with a minified JS code for parts of the >>web UI framework which is against some of Debian policies and therefore >>FreeIPA is blocked from entering Debian. >> >I think you misses context here. :) No, I'm not. >The porpose of reporting bugs to upstream is to file bugs to upstream version. >If the downstream version is patched with non-upstream patches >then you need to find out wheter bug is in upstream or downstream >caused by non-upstream patches. And it should be task of reporter >to ensure that bug is in upstream. It is business as usual -- people would file bug where they want, not where you want them to file regardless how you propose them to deal with it. So far, we have by far many more requests/bugs about Debian/Ubuntu integration than Fedora on the mailing list exactly because Debian/Ubuntu versions people tend to run with are known to contain incomplete support. So for these it does not matter where they are filed because downstreams aren't going to fix the bugs in, say, Ubuntu 12.04 or 14.04 apart from what Timo provides with existing PPAs. Reporting proper information is good and I think our upstream page that David proposed should have subsections per distro flavor (and links to SSSD troubleshooting guides too) but don't put much hope in them, people who were not able to find out existing PPAs or solutions on the list, will not be searching for FreeIPA wiki page to know how to report bugs either. >As I mentioned in previous mail. >If freeipa get to the state that debian has pure upstream version >then we can recommend to report bugs + exact version with dpkg-query > >The purpose of David's mail was to simplify job for developers >and developers life will not be easier if developer need to >find out wheter bug is in upstream or it's caused by downstream patches. It is easy: if it is a bug on Fedora/RHEL/CentOS -- it is bug for Fedora and RHEL maintainers to review and decide to forward or fix, if needed. If the bug on Debian/Ubuntu and reported there -- it is bug for Debian/Ubuntu maintainers to decide to forward or fix, if needed. If these two groups of people are overlapping with FreeIPA/SSSD upstreams, there is no problem as they would know how to handle the situation. If bugs were filed FreeIPA/SSSD upstream and reported issues are at a specific downstream, it would probably make sense to engage with the downstream maintainers anyway -- I'd rather CC: someone and ask a question than crack my head on whether this is an issue upstream/downstream. In other words, spread the work, if possible. :) -- / Alexander Bokovoy From placko at redhat.com Wed May 4 11:36:54 2016 From: placko at redhat.com (Peter Lacko) Date: Wed, 4 May 2016 07:36:54 -0400 (EDT) Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <5722198D.2040305@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> Message-ID: <432295761.50029794.1462361814653.JavaMail.zimbra@redhat.com> Hi! Thanks for the review, should be OK now. I won't change this email's subject, so adding it to the body only and will include it in subject of next patch. [PATCH 0001] Regards, Peter Lacko ----- Original Message ----- From: "Martin Basti" To: "Peter Lacko" , freeipa-devel at redhat.com Sent: Thursday, April 28, 2016 4:09:17 PM Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way On 08.04.2016 10:32, Peter Lacko wrote: > > Hello, I have a few comments: 1) Please set up your git name and email correctly (consistently for all patches) this is not right From: root 2) -# Copyright (C) 2012 Red Hat +# Copyright (C) 2016 Red Hat leave there both years please +# Copyright (C) 2012, 2016 Red Hat 3) Please put the patch number to the email subject, it is easier to find correct patch for us Otherwise LGTM and works for me. Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0001-2-Ping-module-tests.patch Type: text/x-patch Size: 2966 bytes Desc: not available URL: From mbasti at redhat.com Wed May 4 11:55:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 4 May 2016 13:55:26 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <5728CE6F.5060202@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> <5728AD15.10502@redhat.com> <5728B63E.30704@redhat.com> <5728CE6F.5060202@redhat.com> Message-ID: <5729E32E.6050103@redhat.com> On 03.05.2016 18:14, Petr Viktorin wrote: > On 05/03/2016 04:31 PM, Martin Basti wrote: >> >> On 03.05.2016 15:52, Petr Viktorin wrote: >>> On 05/03/2016 03:02 PM, Petr Spacek wrote: >>>> On 2.5.2016 18:02, Martin Basti wrote: >>>>> On 29.04.2016 19:46, Petr Viktorin wrote: >>>>>> Hello, >>>>>> These patches concentrate on tests, and code that was added/changed >>>>>> since I last looked at the FreeIPA project. >>>>>> >>>>>> With these patches, I'm back to getting the same errors under py2 and >>>>>> py3 when in test_xmlrpc. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Patch 777: >>>>> Could you fix all relative imports and enable check in pylint for that? >>>>> (Remove relative-import from pylintrc), IMO there is just one extra >>>>> relative >>>>> import in custodia module. >>> Would it be OK if I do that in a separate patch, in the next batch? This >>> one is fixing the tests. >>> (I have the change in my worktree, so I won't forget when I next sit >>> down to work on IPA.) >> It is okay to send it in a next patch :) >> ACK on this patch then >>>>> Do you plan to use in py2 ? >>>>> from__future__importabsolute_import >>> I think that's unnecessary boilerplate; the errors this catches are >>> easily found by other means. >>> And it doesn't guard against someone forgetting the __future__ import >>> itself in a new file. The pylint check will be much better. >> Ok, just FYI pylint has check that prevents forgetting this import >> (disabled in IPA) >> >>>>> Patch 778: >>>>> LGTM >>>>> >>>>> Patch 779 >>>>> LGTM >>>>> >>>>> Patch 780 >>>>> LGTM >>>>> >>>>> Patch 781 >>>>> LGTM >>>>> >>>>> Patch 782 >>>>> Not sure, I will review it longer >>>>> >>>>> Patch 783 >>>>> LGTM >>>>> >>>>> Patch 784 >>>>> LGTM >>>>> >>>>> Patch 785 >>>>> LGTM >>>>> >>>>> I will test it with both py2 and py3 to convert LGTM to ACK :) >>>> Functional ACK, I did not find any breakage (when combined with other >>>> Py3 >>>> patches). >>>> >> Hold your horses :D, I probably find something in tests >> >> I run ipa-run-tests with xmlrpc tests under python2 and python3, please >> note the different count of tests and errors in py3 >> >> platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 >> -- /usr/bin/python >> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >> collecting ... collected 1835 items >> >> platform linux -- Python 3.5.1, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 -- >> /bin/python3 >> rootdir: /usr/lib/python3.5/site-packages/ipatests, inifile: pytest.ini >> collecting ... collected 1694 items / 7 errors >> >> >> Collecting failed on following import errors: >> test_xmlrpc/test_add_remove_cert_cmd.py:13: in >> ipatests.test_xmlrpc.testcert import get_testcert >> xmlrpc/testcert.py:34: in >> ipaserver.plugins import rabase >> ImportError: No module named 'ipaserver' >> >> And I found more errors, but they may be unrelated I have to investigate >> more >> Martin^2 > Right, some of the xmlrpc tests use ipaserver, which isn't fully ported > yet, and the python3-ipaserver RPM isn't even built. The parts of > ipaserver needed for these tests will be my next goal. > OK However I see errors under py3 in cert tests =================================== FAILURES =================================== _______________________ test_cert.test_0003_service_show _______________________ self = def test_0003_service_show(self): """ Verify that service-show has the right certificate using service-show. """ global cert res = api.Command['service_show'](self.service_princ)['result'] > assert base64.b64encode(res['usercertificate'][0]) == cert E assert b'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBq x4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' == 'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3 Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBqx4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' E + where b'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bh fBqx4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' = (b'0\x82\x04\xa00\x82\x03\x88\xa0\x03\x02\x01\x02\x02\x01\x120\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x000Q1/0-\x06\x0...x e6W~\x17\x8cfZ\xd5i8>n\x17\xc1\xab\x1e$\xb8\xbd\xb6w)\xd6?\x8e\x9b\xd6\x00\x8al\x1b\xb8k\xbb\xd8g{l\x8bvL%oP)\xab\xa4') E + where = base64.b64encode test_xmlrpc/test_cert_plugin.py:161: AssertionError _______________________ test_cert.test_0004_service_find _______________________ self = def test_0004_service_find(self): """ Verify that service-find has the right certificate using service-find. """ global cert # Assume there is only one service res = api.Command['service_find'](self.service_princ)['result'] > assert base64.b64encode(res[0]['usercertificate'][0]) == cert E assert b'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBq x4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' == 'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3 Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBqx4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' E + where b'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bh fBqx4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' = (b'0\x82\x04\xa00\x82\x03\x88\xa0\x03\x02\x01\x02\x02\x01\x120\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x000Q1/0-\x06\x0...x e6W~\x17\x8cfZ\xd5i8>n\x17\xc1\xab\x1e$\xb8\xbd\xb6w)\xd6?\x8e\x9b\xd6\x00\x8al\x1b\xb8k\xbb\xd8g{l\x8bvL%oP)\xab\xa4') E + where = base64.b64encode test_xmlrpc/test_cert_plugin.py:171: AssertionError _______________________ test_cert.test_0006_service_show _______________________ self = def test_0006_service_show(self): """ Verify the new certificate with service-show. """ global cert, newcert res = api.Command['service_show'](self.service_princ)['result'] # Both the old and the new certs should be listed as certificates now certs_encoded = (base64.b64encode(cert) for cert in res['usercertificate']) > assert set(certs_encoded) == set([cert, newcert]) E assert {b'MIIEoDCCA4...ysM/XwYCpO0C'} == {'MIIEoDCCA4ig...ysM/XwYCpO0C'} E Extra items in the left set: E b'MIIEoDCCA4igAwIBAgIBEzANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...6cf8VNCcZVjc+GwFZF55/q+iRv0OcN2sN2uSxAkPWeOLtVvTw/VEgWc5AX+rZqAoZHE5++XmMRrTEp7e 3tN9b0GcN6tE/2QsuRPCrWb5y7ysM/XwYCpO0C' E b'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwG...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBqx4kuL 22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' E Extra items in the right set: E 'MIIEoDCCA4igAwIBAgIBEzANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA...6cf8VNCcZVjc+GwFZF55/q+iRv0OcN2sN2uSxAkPWeOLtVvTw/VEgWc5AX+rZqAoZHE5++XmMRrTEp7e 3tN9b0GcN6tE/2QsuRPCrWb5y7ysM/XwYCpO0C' E 'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA...upSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBqx4kuL 22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk' E Full diff: E + {'MIIEoDCCA4igAwIBAgIBEjANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDUwNDA4MDQ1M1oXDTE4MDUwNTA4MDQ1M1owb jEvMC0GA1UECgwmRE9NLTAxMi5BQkMuSURNLkxBQi5FTkcuQlJRLlJFREhBVC5DT00xOzA5BgNVBAMMMmlwYXRlc3RjZXJ0LmRvbS0wMTIuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVeHWfqGobn/oQiirros XqKmGcq4P1AEiA84MANxM+U0E057IekptebrUN+qEDvgm00gXRSZtLHglp2K1U4oNHLA7rgvY1wki3UYOMC4GnW7HZz0i78BH6fD4JWjcBSxZzc+yDhmZDU1mhCP5SNzN8O8yylHlo11kcf8x5+oQflJxzgsFRfDsarrLagPc4R7mZq2FqsUcuDOnMZuIMixdAiFgVQWEzYOouqhxZt z0uXn1c396xzDahmBozns38hHKHbxsqjmGvdyCwz2U2PHq0jLKq4dE8vJOH1K05n8SE/8tJKROpHdAJzzAK34cFjTzRrXQAhVBcPS62I/z9wQTwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAUDezOZz5UOmhahXf2DYDrBvzXk+IwWAYIKwYBBQUHAQEETDBKMEgGCCsGAQUFBzABhjxodHRwOi8vaXBhLWNhLmRvbS0wMTIuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCBlAYDVR0fBIGMMIGJMIGGoE6gTIZKaHR0cDovL2lwYS1jYS5kb20tMDEyLmFiYy5pZG0ubGFiLmVuZy5icnEucmVkaGF0LmNvbS9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFNP41fcPT46+iZkQj/N5iGJ5WAuzMA0GCSqGSIb3DQEBCwUAA4IBAQAlarorG+udWl5xWNcXduXhy22qfn/qmyLTOxiHS/Eos7cNnm8/I0zXFmBwl59q/75ouhHmdvBvHfQwig8pP0YEMZM/2g7UfUV2Xngv2WKskIkGoC91bBd2hJ16yqXceHT/kQPRJw9vIPsOY0/5hBjS/E4oybkyf0zubNRCWgIhVzGIKMIVOnSw1wq2893pPLJ/JFSk232fpbdkKiBGtzv1sgYLfA2HGTupSCr/8sWoLTmDxcmiE0DhXfCqatdLBBN2AoZi0dx3Md07Pn+8wrmYW+ZXfheMZlrVaTg+bhfBqx4kuL22dynWP46b1gCKbBu4a7vYZ3tsi3ZMJW9QKauk', E + 'MIIEoDCCA4igAwIBAgIBEzANBgkqhkiG9w0BAQsFADBRMS8wLQYDVQQKDCZET00tMDEyLkFCQy5JRE0uTEFCLkVORy5CUlEuUkVESEFULkNPTTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDUwNDA4MDQ1NVoXDTE4MDUwNTA4MDQ1NVowbjEvMC0GA1UECgwmRE9NLTAxMi5BQkMuSURNLkxBQi5FTkcuQlJRLlJFREhBVC5DT00xOzA5BgNVBAMMMmlwYXRlc3RjZXJ0LmRvbS0wMTIuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxhIU7Oabo4GFQ+464LKMHa0bImj71uJKgaa4vrHBrgC8G6RlXxfvBBMR30IYq8Ms4O2mUAbP8JoHswf67MpGkYBSREsr9CTg9M+U8Uq3PuUpuLeypmbU2iTy1lpxSX4TEp95Hb2Xf4Q1M2uAEv6diTbx9i2VlcqAF2Gf+2VDhKupWix38pLyj8ndW56hsQaZZGYLXibi9KVoML7Ohe8NwmNdWLt6J93kjFXCMGlHA4re+zH2kpFZak0lkehcemDeZ6zqtWD72yFfHCGr1YBHbgVARQOsqChc+GhH6M/BuffeGmuixkJO2zAk9hFDXjv9aU6UOyNHGAIkIrfYVeZNAwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAUDezOZz5UOmhahXf2DYDrBvzXk+IwWAYIKwYBBQUHAQEETDBKMEgGCCsGAQUFBzABhjxodHRwOi8vaXBhLWNhLmRvbS0wMTIuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCBlAYDVR0fBIGMMIGJMIGGoE6gTIZKaHR0cDovL2lwYS1jYS5kb20tMDEyLmFiYy5pZG0ubGFiLmVuZy5icnEucmVkaGF0LmNvbS9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFFTQLniQgZH+FS0LxSJHPCIgE0DrMA0GCSqGSIb3DQEBCwUAA4IBAQAH3BobYXnJbsW+YmJwfxudAAG5GNqf91K67hLFnbDmMTiKYqOi5Qr3kKy017OCYNGIpq7MX/1NtYCV1tqA25uxYYoFkrK6xAdzzKtJFAgAaicIJPa1yQ1kca8yJdiwp7LQaW4yeN8cnNCIabQEZrR4uZ0WB0iWQiISu5FKn6j2NCnUYqxbkObGebLwLspcohjmZhRcbqjq+ipAlFQuFqyOPpuzGWuwjy6cf8VNCcZVjc+GwFZF55/q+iRv0OcN2sN2uSxAkPWeOLtVvTw/VEgWc5AX+rZqAoZHE5++XmMRrTEp7e3tN9b0GcN6tE/2QsuRPCrWb5y7ysM/XwYCpO0C'} E Detailed information truncated (42 more lines), use "-vv" to show From tbordaz at redhat.com Wed May 4 12:20:57 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 4 May 2016 14:20:57 +0200 Subject: [Freeipa-devel] Provisioning throughput Message-ID: <5729E929.6010307@redhat.com> Hello, I have been doing some tests/measures using https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. The tool creates a set of typical users/hosts/groups... to import with a ldapadd. I wrote down some finding in http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. I still have to do some cleanup around the performance but the basic of a possible improvement is to do provisioning in several steps (disabling plugins, provisioning, enabling plugin, running fixup tasks). Before going further in the design I wanted to share those ideas and know if it raise any concern. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed May 4 12:30:06 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 4 May 2016 06:30:06 -0600 Subject: [Freeipa-devel] [PATCH] 0001 (update 2) provide more information for "ipa cert-revoke -h" In-Reply-To: <0ffbca59-c6ad-3f82-a4c6-127f0b8365e6@gmail.com> References: <0ffbca59-c6ad-3f82-a4c6-127f0b8365e6@gmail.com> Message-ID: On Wed, May 4, 2016 at 1:35 AM, Patrice Duc-Jacquet wrote: > Hi everyone > > this is a second update that take into account review feedback. > > In case the proposal fix is K what are the next step to commit this > change. I'm not sure to really understand the process. Thanks and regards > If the fix is good, you receive an ack and a core member of the FreeIPA team will take your ack'ed patch and push it to the official git repository. ACK from me Gabe Pat > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed May 4 13:04:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 4 May 2016 15:04:05 +0200 Subject: [Freeipa-devel] [PATCH 0096] Batch command: avoid accessing potentially undefined context.principa In-Reply-To: <571A0AD3.3090507@redhat.com> References: <571A0AD3.3090507@redhat.com> Message-ID: <4e5bc6fe-d0d1-c331-7651-32224d6b5f4b@redhat.com> Hi, On 22.4.2016 13:28, Petr Spacek wrote: > Hello, > > Batch command: avoid accessing potentially undefined context.principal > > This might happen when the command is called directly in Python, > e.g. in installers and so on. > > Pylint pylint-1.5.5-1.fc24.noarch caught this. > > https://fedorahosted.org/freeipa/ticket/5838 LGTM, but please use 'UNKNOWN' as the default value, for consistency with ipalib.rpcserver code. Honza -- Jan Cholasta From redhatrises at gmail.com Wed May 4 13:14:52 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 4 May 2016 07:14:52 -0600 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: <57298605.60203@redhat.com> References: <57298605.60203@redhat.com> Message-ID: On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde wrote: > Hi Gabe, > > I am wondering, how are we handling "CalledProcessError" exception ? > I am not sure 100% what you are asking, but from what I understand, the "CalledProcessError" exception is when a process returns a non-zero exit status. However when running 'ipa-nis-manage enable', an exception is never hit even if portmap is not installed, hence portmap always being enabled. So it seems that if the process is not installed, "CalledProcessError" doesn't catch an error. Gabe > On 05/04/2016 09:17 AM, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5857 > > Thanks, > > Gabe > > > Thanks, > Abhijeet Kasurde > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed May 4 13:39:55 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 4 May 2016 15:39:55 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: References: Message-ID: On 05/02/2016 02:28 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/2795 That patch looks suspiciously short given the struggles I saw in http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html :-) Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid filling "krbPasswordExpiration" attribute at all, i.e. have password *without* expiration? Or is krbPasswordExpiration mandatory? From mbasti at redhat.com Wed May 4 14:28:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 4 May 2016 16:28:48 +0200 Subject: [Freeipa-devel] [PATCH 0472] fix stageuser-find test Message-ID: <572A0720.2010009@redhat.com> https://fedorahosted.org/freeipa/ticket/5281 I forgot to send patch that fixes also stageuser tests with current changes in has_keytab and has_password attributes. Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0472-fix-stageuser-tests-removal-of-has_keytab-and-has_pa.patch Type: text/x-patch Size: 1841 bytes Desc: not available URL: From ssorce at redhat.com Wed May 4 14:36:00 2016 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 04 May 2016 10:36:00 -0400 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: References: Message-ID: <1462372560.3624.62.camel@redhat.com> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: > On 05/02/2016 02:28 PM, David Kupka wrote: > > https://fedorahosted.org/freeipa/ticket/2795 > > That patch looks suspiciously short given the struggles I saw in > http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html > :-) > > Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid filling > "krbPasswordExpiration" attribute at all, i.e. have password *without* > expiration? Or is krbPasswordExpiration mandatory? So I looked at the MIT code, and it seem like they are coping just fine with a missing (ie value = 0 internally) pw_expiration attribute. So if we make our code cope with omitting any expiration if the attribute is missing then yes, we can mark no expiration with simply removing (or not setting) the krbPasswordExpiration attribute. The attribute itself is optional and can be omitted. I think this is a good idea, and is definitely better than inventing a a magic value. Simo. From pvomacka at redhat.com Wed May 4 15:22:28 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 4 May 2016 17:22:28 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <1462372560.3624.62.camel@redhat.com> References: <1462372560.3624.62.camel@redhat.com> Message-ID: <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> On 05/04/2016 04:36 PM, Simo Sorce wrote: > On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >> On 05/02/2016 02:28 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/2795 >> That patch looks suspiciously short given the struggles I saw in >> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >> :-) >> >> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid filling >> "krbPasswordExpiration" attribute at all, i.e. have password *without* >> expiration? Or is krbPasswordExpiration mandatory? > So I looked at the MIT code, and it seem like they are coping just fine > with a missing (ie value = 0 internally) pw_expiration attribute. > > So if we make our code cope with omitting any expiration if the > attribute is missing then yes, we can mark no expiration with simply > removing (or not setting) the krbPasswordExpiration attribute. > The attribute itself is optional and can be omitted. > > I think this is a good idea, and is definitely better than inventing a a > magic value. > > Simo. > Just a note: I tested David's patch and it actually doesn't work when the new password policy for ipausers group is created (priority = 0, which should be the highest priority). The maxlife and minlife values are empty. Even if I set the new password policy maxlife and minlife to 0 the result was that password will expire in 90 days. The patch worked correctly when I changed value of maxlife and minlife to 0 in 'global_policy'. Then the password expiration was set to 2038-01-01. From lslebodn at redhat.com Wed May 4 16:22:55 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 4 May 2016 18:22:55 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160504095629.fisi6bdvwvyiiyvv@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> <20160504080550.x2ilcs6vdvyac3a2@redhat.com> <20160504084123.GB21729@10.4.128.1> <20160504095629.fisi6bdvwvyiiyvv@redhat.com> Message-ID: <20160504162254.GA12788@10.4.128.1> On (04/05/16 12:56), Alexander Bokovoy wrote: >On Wed, 04 May 2016, Lukas Slebodnik wrote: >> On (04/05/16 11:05), Alexander Bokovoy wrote: >> > On Tue, 03 May 2016, Robbie Harwood wrote: >> > > Lukas Slebodnik writes: >> > > >> > > > On (03/05/16 12:29), Robbie Harwood wrote: >> > > > > David Kupka writes: >> > > > > >> > > > > > --8<------------- trac-ticket-template-proposal ------------------->8-- >> > > > > > Related SW versions: >> > > > > > On server: >> > > > > > {{{ >> > > > > > $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server >> > > > > >> > > > > I think this is a good idea. However, we are on Debian/family as >> > > > > well now, and I think we want to accept bugs that come from these >> > > > > users as well. >> > > > >> > > > FreeIPA is heavily patched on debian and has quite old version there >> > > > 4.0.5. >> > > > >> > > > The better would be recommend to reproduce with upstream version >> > > > (fedora/CentOS). >> > > >> > > (FreeIPA 4.1.4 is available on Debian, but your point still stands.) >> > > >> > > In summary: I don't like that upstream is conflated with fedora/CentOS. >> > > Of course I understand that this was done to ease development and not >> > > out of malice. But longer term I would like Debian/Ubuntu FreeIPA to be >> > > less of an afterthought because I believe we can attract users to our >> > > product. I believe this to be especially true with working >> > > freeipa-client on those distros, which we now have and I am very happy >> > > about. >> > I think you miss context here. There was huge amount of work done in >> > last couple months to get FreeIPA 4.3 running on Ubuntu and Debian. It >> > made to Ubuntu 16.04. It didn't make to Debian proper yet for a single >> > reason: FreeIPA tarball ships with a minified JS code for parts of the >> > web UI framework which is against some of Debian policies and therefore >> > FreeIPA is blocked from entering Debian. >> > >> I think you misses context here. >:) No, I'm not. > >> The porpose of reporting bugs to upstream is to file bugs to upstream version. >> If the downstream version is patched with non-upstream patches >> then you need to find out wheter bug is in upstream or downstream >> caused by non-upstream patches. And it should be task of reporter >> to ensure that bug is in upstream. >It is business as usual -- people would file bug where they want, not >where you want them to file regardless how you propose them to deal with >it. So far, we have by far many more requests/bugs about Debian/Ubuntu >integration than Fedora on the mailing list exactly because >Debian/Ubuntu versions people tend to run with are known to contain >incomplete support. So for these it does not matter where they are >filed because downstreams aren't going to fix the bugs in, say, Ubuntu >12.04 or 14.04 apart from what Timo provides with existing PPAs. > >Reporting proper information is good and I think our upstream page that >David proposed should have subsections per distro flavor (and links to >SSSD troubleshooting guides too) but don't put much hope in them, people >who were not able to find out existing PPAs or solutions on the list, >will not be searching for FreeIPA wiki page to know how to report bugs >either. > >> As I mentioned in previous mail. >> If freeipa get to the state that debian has pure upstream version >> then we can recommend to report bugs + exact version with dpkg-query >> >> The purpose of David's mail was to simplify job for developers >> and developers life will not be easier if developer need to >> find out wheter bug is in upstream or it's caused by downstream patches. >It is easy: if it is a bug on Fedora/RHEL/CentOS -- it is bug for Fedora >and RHEL maintainers to review and decide to forward or fix, if needed. > >If the bug on Debian/Ubuntu and reported there -- it is bug for >Debian/Ubuntu maintainers to decide to forward or fix, if needed. > >If these two groups of people are overlapping with FreeIPA/SSSD >upstreams, there is no problem as they would know how to handle the >situation. > >If bugs were filed FreeIPA/SSSD upstream and reported issues are at a >specific downstream, it would probably make sense to engage with the >downstream maintainers anyway -- I'd rather CC: someone and ask a >question than crack my head on whether this is an issue >upstream/downstream. > >In other words, spread the work, if possible. :) > I'm sorry but it was a TL;DR mail without any useful information to the topic. The topic is "Improving bug reporting". I do not care much how downstreams handle bug reports. I like David proposal with template. But I do not like proposal for debian; because there isn't an upstream version. therefore I proposed to add recommendation to test with upstream version of FreeIPA (fedora) We should be very kind to users of other distributions but it happen to me that my direct reports to upstream were closed because fedora had patched version of packages. I did't like this way but I understant why it was closed in upstream. I did not propose to directly close tickets reported for non-upstream versions. I proposed to add an recommendation to the template to test with upstream version. BTW We also suggest such way also in sssd. We have some users who had problems with sssd due to buggy version of sssd in downstram (el7.1). We fixed many bugs in upstream but they were not fixed in downstream. Therefore we started to build upstream versions of sssd to older distributions[1]. We *SAVED* a lot of time due to this recommendation. This is a best practice which we use also for reports from ubuntu 14.04. There is buggy version of sssd-1.11.5.1 and it does not worth to spend a time with investigation unless bug is confirmed with latest upstream version. Fortunately, Timo has latest upstream version of sssd in ppa. If there wasn't a ppa I would prepare it myself. LS [1] https://copr.fedorainfracloud.org/groups/g/sssd/coprs/ From rcritten at redhat.com Wed May 4 17:22:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 4 May 2016 13:22:44 -0400 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <20160504162254.GA12788@10.4.128.1> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> <20160504080550.x2ilcs6vdvyac3a2@redhat.com> <20160504084123.GB21729@10.4.128.1> <20160504095629.fisi6bdvwvyiiyvv@redhat.com> <20160504162254.GA12788@10.4.128.1> Message-ID: <572A2FE4.9040604@redhat.com> Lukas Slebodnik wrote: > On (04/05/16 12:56), Alexander Bokovoy wrote: > I'm sorry but it was a TL;DR mail without any useful information > to the topic. > > The topic is "Improving bug reporting". I do not care much > how downstreams handle bug reports. > > I like David proposal with template. But I do not like > proposal for debian; because there isn't an upstream version. > therefore I proposed to add recommendation to test with upstream version > of FreeIPA (fedora) > > We should be very kind to users of other distributions but it happen > to me that my direct reports to upstream were closed because > fedora had patched version of packages. I did't like this way > but I understant why it was closed in upstream. > > I did not propose to directly close tickets reported for non-upstream versions. > I proposed to add an recommendation to the template to test with upstream > version. > > BTW We also suggest such way also in sssd. We have some users who had problems > with sssd due to buggy version of sssd in downstram (el7.1). We fixed many bugs > in upstream but they were not fixed in downstream. Therefore we started > to build upstream versions of sssd to older distributions[1]. > We *SAVED* a lot of time due to this recommendation. This is a best practice > which we use also for reports from ubuntu 14.04. There is buggy version of > sssd-1.11.5.1 and it does not worth to spend a time with investigation unless > bug is confirmed with latest upstream version. Fortunately, Timo has latest > upstream version of sssd in ppa. If there wasn't a ppa I would prepare > it myself. I don't think sssd is something to measure against in this case. IPA has so many more moving parts it has taken quite a lot longer to get near the same point as sssd. Debian support has almost literally been a one-man operation. IPA as a server didn't work in any real way until Timo got 4.3.1 built because without replication it's an interesting but non-production exercise. So IMHO any existing server builds on old platforms are not supportable. The same is probably true for the client packages which had all sorts of gotchas. Timo has done an terrific job getting his patches upstream, quite a few of which have been specifically to make IPA more distro agnostic. So honestly, I think a new line should be drawn using 4.3.1 as the starting point and provide just best-effort support for older releases. So workarounds only and probably no patches unless you can show it also affects the latest, and if Timo wants to backport then that's up to him. As for the template, part of the problem with the trac tickets is it is often developers filing bugs against things they see and I know I've filed a ton of awful, no details bugs thinking I'd get to it "real soon" and then not. A template might help at least remind what is necessary, but that is just as easily ignorable as the almost identical template in bugzilla. So I'd say it's up to the first round of triage to push back on poorly filed tickets. Maybe give Petr a ban hammer to close any incomplete tickets when they come in. I think devs would get the idea pretty quickly. He could be gentler with user-reported issues. rob From npmccallum at redhat.com Wed May 4 21:33:55 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 04 May 2016 17:33:55 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators Message-ID: <1462397635.1537.70.camel@redhat.com> This series of patches implements authentication indicator insertion, evaluation and management in FreeIPA. Besides these patches, two other patches are needed to round out support. First, we need a UI patch:?https://fedorahosted.org/freeipa/ticket/5872 Second, we need a SSSD patch to handle the new case where multiple responders are set (when either 1FA or 2FA can be used). Please note that the last patch in this series (0093) is untested and simply represents my desire to get these patches off of my hard disk before I take a long weekend. This patch also requires mrogers' patch 0001 (already merged to master). Also worthy of note is the need for an OID for the authentication control. Hopefully Simo can assign this after we agree that this control method is sufficient. One question I had was whether or not it would be possible to send the control only on UNIX sockets (0089; report_auth_method()). Please review the approaches taken here. I plan to hit this hard on Monday. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0093-Enable-managing-authentication-indicators-on-service.patch Type: text/x-patch Size: 5716 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0092-Enable-authentication-indicators-for-OTP-and-RADIUS.patch Type: text/x-patch Size: 1941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0091-Return-password-only-preauth-if-passwords-are-allowe.patch Type: text/x-patch Size: 1631 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0090-Validate-the-auth-method-control-in-ipa-otpd.patch Type: text/x-patch Size: 3113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0089-Return-an-LDAP-control-indicating-the-auth-method.patch Type: text/x-patch Size: 5418 bytes Desc: not available URL: From jcholast at redhat.com Thu May 5 05:48:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 5 May 2016 07:48:05 +0200 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <20160504040405.GN1237@dhcp-40-8.bne.redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> <20160503070558.GJ1237@dhcp-40-8.bne.redhat.com> <20160504040405.GN1237@dhcp-40-8.bne.redhat.com> Message-ID: <35b15cbc-dc68-56ab-92d8-6cbbef69103c@redhat.com> On 4.5.2016 06:04, Fraser Tweedale wrote: > On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: >> On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: >>> On 21.4.2016 05:30, Fraser Tweedale wrote: >>>> On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: >>>>> Hi all, >>>>> >>>>> The attached patches configure lightweight CA key replication on IPA >>>>> CAs, on upgrade and installation. >>>>> >>>>> Patches 0051..0052 from my other mail are also needed for the system >>>>> to work, but this patchset does not depend on them and can be >>>>> reviewed independently. >>>>> >>>>> There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 >>>>> - it just puts the necessary principals/keys/configuration in place. >>>>> >>>>> Cheers, >>>>> Fraser >>>>> >>>> New patches attached; 0054-2 changes the service name from >>>> 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the >>>> principal to search server Custodia keys. >>> >> Honza, thanks for review. Comments inline. >> >>> Patch 53: >>> >>> I'm not sure about this approach - the cn of custodia keys in LDAP is a >>> free-form string, I would not tie it to service names, but rather try to >>> keep it short. >>> >>> In the key replication section of the design page, you mention "ca/$NAME", I >>> think this is a good template for the cn and that we should stick to it. >>> >> This scheme (or something like it, *without* '/' as the separator) >> is needed to satisfy the ACI that allows host principals to manage >> Custodia keys: >> >> add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") >> (version 3.0; acl "IPA server hosts can create own Custodia secrets"; >> allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" >> and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) >> >> The CN must contain the hostname, and we must also disambiguate on >> key type. The current scheme is: >> >> {sig,enc}~dogtag/ >> e.g. >> enc~dogtag/f23-2.ipa.local >> >> The first separator cannot be '/' because the '*' wildcard in the >> ACI is not greedy - the captured text would include the servicename >> and fail to match any userdn. >> >> If you do not like '~' feel free to suggest a different symbol :) >> The alternative is to add more ACIs. I would rather add a new ACI than have one super-ACI for everything. That way you don't have to invent any complicated naming schemes *and* it will be more apparent what the ACI does. BTW I'm a little bit confused as to what Dogtag keys will actually be stored in Custodia. My naive understanding is that it would be the CA signing key of each CA, but seeing how there's a host name and key usage in the name, I'm not so sure. Could you clarify this, or point me to a design where it is explained? >>> >>> 5) This also belongs to CAInstance.configure_instance(): >>> >>> + if setup_ca: >>> + # CA was configured before Kerberos; >>> + # add Custodia client princ and keys now >>> + ca_instance.setup_lightweight_ca_key_retrieval() >>> >>> In order for that to work, you need to move the ca.install_step_1() after >>> krb.create_instance(), but that should be OK, since KrbInstance does not >>> talk to the CA. >>> >> `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which >> fails if called before `krb.create_instance' due to missing >> krb5.conf:: >> >> 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local at IPA.LOCAL -x ipa-setup-override-restrictions >> 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 >> 2016-05-03T06:29:23Z DEBUG stdout= >> 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm >> >> Moving `ca.install_step_1()' to after `krb.create_instance()' does >> not help, because `CAInstance.configure_instance' is called from >> `ca.install_step_0()'. Right. *slaps forehead* >> >> However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' >> *directly* from `ca.install_step_1' would probably work. Are you >> happy with putting it there, instead of `configure_instance()'? Works for me. >> >> Cheers, >> Fraser >> > Updated patches attached, include bringing back 0052-2 for the ACI > change. > > Cheers, > Fraser > -- Jan Cholasta From jcholast at redhat.com Thu May 5 06:16:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 5 May 2016 08:16:17 +0200 Subject: [Freeipa-devel] #5836 [RFE] Allow profile to specify default CA In-Reply-To: <20160504002122.GL1237@dhcp-40-8.bne.redhat.com> References: <20160504002122.GL1237@dhcp-40-8.bne.redhat.com> Message-ID: Hi, On 4.5.2016 02:21, Fraser Tweedale wrote: > Continuing the discussion for #5836[1] as requested from triage > session. > > [1] https://fedorahosted.org/freeipa/ticket/5836 > > IMO it is not important for FreeIPA 4.4. It is nice to have but I > doubt it will make it. +1 > > Honza suggested it should be the other way around, i.e. CA specifies > default profile rather than profile specifies default CA. > > The fact (also raised by Christian) is that multiple profiles may be > used with a single CA, and vice-versa. CA ACLs will govern what > combinations are acceptable. > > Thinking from user perspective, there are a couple of things to > consider: > > - Currently, to request a particular kind of cert, user must specify > a profile ID. > > - It is more natural to ask for a particular profile and have the > request dispatched to a profile-specified default CA, than to ask > for a cert issued by a particular CA, and a CA-specified default > profile will be used. > > Given these points, I am strongly in favour of having the profile > indicate the default CA - not the other way around. My worry is how will this work when external CA support comes into the picture (I outlined a possible solution at [1]). Right now there is only Dogtag, so all profiles work for all CAs, but once there are different types of CAs, this will no longer be true, because profiles are inherently CA implementation-specific. I'm not against profiles having a default CA per-se, I would just like the design to take the possibility of external CAs into account, so that it does not create issues for us in the future. Honza [1] certmonger everywhere, -- Jan Cholasta From ftweedal at redhat.com Thu May 5 06:52:29 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 May 2016 16:52:29 +1000 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <35b15cbc-dc68-56ab-92d8-6cbbef69103c@redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> <20160503070558.GJ1237@dhcp-40-8.bne.redhat.com> <20160504040405.GN1237@dhcp-40-8.bne.redhat.com> <35b15cbc-dc68-56ab-92d8-6cbbef69103c@redhat.com> Message-ID: <20160505065229.GU1237@dhcp-40-8.bne.redhat.com> On Thu, May 05, 2016 at 07:48:05AM +0200, Jan Cholasta wrote: > On 4.5.2016 06:04, Fraser Tweedale wrote: > >On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: > >>On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > >>>On 21.4.2016 05:30, Fraser Tweedale wrote: > >>>>On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > >>>>>Hi all, > >>>>> > >>>>>The attached patches configure lightweight CA key replication on IPA > >>>>>CAs, on upgrade and installation. > >>>>> > >>>>>Patches 0051..0052 from my other mail are also needed for the system > >>>>>to work, but this patchset does not depend on them and can be > >>>>>reviewed independently. > >>>>> > >>>>>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > >>>>>- it just puts the necessary principals/keys/configuration in place. > >>>>> > >>>>>Cheers, > >>>>>Fraser > >>>>> > >>>>New patches attached; 0054-2 changes the service name from > >>>>'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > >>>>principal to search server Custodia keys. > >>> > >>Honza, thanks for review. Comments inline. > >> > >>>Patch 53: > >>> > >>>I'm not sure about this approach - the cn of custodia keys in LDAP is a > >>>free-form string, I would not tie it to service names, but rather try to > >>>keep it short. > >>> > >>>In the key replication section of the design page, you mention "ca/$NAME", I > >>>think this is a good template for the cn and that we should stick to it. > >>> > >>This scheme (or something like it, *without* '/' as the separator) > >>is needed to satisfy the ACI that allows host principals to manage > >>Custodia keys: > >> > >> add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > >> (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > >> allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > >> and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > >> > >>The CN must contain the hostname, and we must also disambiguate on > >>key type. The current scheme is: > >> > >> {sig,enc}~dogtag/ > >> e.g. > >> enc~dogtag/f23-2.ipa.local > >> > >>The first separator cannot be '/' because the '*' wildcard in the > >>ACI is not greedy - the captured text would include the servicename > >>and fail to match any userdn. > >> > >>If you do not like '~' feel free to suggest a different symbol :) > >>The alternative is to add more ACIs. > > I would rather add a new ACI than have one super-ACI for everything. That > way you don't have to invent any complicated naming schemes *and* it will be > more apparent what the ACI does. > OK, I'll simplify the scheme and create corresponding ACIs. > BTW I'm a little bit confused as to what Dogtag keys will actually be stored > in Custodia. My naive understanding is that it would be the CA signing key > of each CA, but seeing how there's a host name and key usage in the name, > I'm not so sure. Could you clarify this, or point me to a design where it is > explained? > Dogtag lightweight CA signing keys are stored in Dogtag's NSSDB (/etc/pki/pki-tomcat/alias), alongside the "main" CA signing key, subsystem keys, etc. Custodia provides access to those keys, but those are not the keys that this patchset creates. The keys being dealt with in this patchset are keys for the Custodia client - running as pkiuser - to authenticate to a Custodia client, and for encrypting the response. They serve no other purpose. It is explained at [1] (note: the design page still refers to the old principal name 'dogtag-ipa-custodia'). [1] http://www.freeipa.org/page/V4/Sub-CAs#Authenticating_to_Custodia > >>> > >>>5) This also belongs to CAInstance.configure_instance(): > >>> > >>>+ if setup_ca: > >>>+ # CA was configured before Kerberos; > >>>+ # add Custodia client princ and keys now > >>>+ ca_instance.setup_lightweight_ca_key_retrieval() > >>> > >>>In order for that to work, you need to move the ca.install_step_1() after > >>>krb.create_instance(), but that should be OK, since KrbInstance does not > >>>talk to the CA. > >>> > >>`setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which > >>fails if called before `krb.create_instance' due to missing > >>krb5.conf:: > >> > >> 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local at IPA.LOCAL -x ipa-setup-override-restrictions > >> 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 > >> 2016-05-03T06:29:23Z DEBUG stdout= > >> 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm > >> > >>Moving `ca.install_step_1()' to after `krb.create_instance()' does > >>not help, because `CAInstance.configure_instance' is called from > >>`ca.install_step_0()'. > > Right. *slaps forehead* > > >> > >>However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' > >>*directly* from `ca.install_step_1' would probably work. Are you > >>happy with putting it there, instead of `configure_instance()'? > > Works for me. > Cool, thanks. From ftweedal at redhat.com Thu May 5 07:05:30 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 May 2016 17:05:30 +1000 Subject: [Freeipa-devel] [PATCH] 0056 Add custodia store for lightweight CA key replication Message-ID: <20160505070530.GW1237@dhcp-40-8.bne.redhat.com> G'day team, This patch implements a new Custodia store type to be used for LWCA keys. Simo gave a preliminary review a couple weeks ago (I was holding off because required Dogtag bits were not yet merged... they are now, so here's the patch ^_^) Cheers, Fraser -------------- next part -------------- From 42ad22dddf4ea05792a64dbab8ff810fa4a075f2 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 19 Apr 2016 11:47:29 +1000 Subject: [PATCH] Add custodia store for lightweight CA key replication Due to limitations in Dogtag's use of NSSDB, importing private keys must be done by the Dogtag Java process itself. This requires a PKIArchiveOptions format (signing key wrapped with host CA key) - PKCS #12 cannot be used because that would require decrypting the key in Dogtag's memory, albeit temporarily. Add a new custodia store that executes a 'pki' command to acquire the wrapped key. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipaplatform/base/paths.py | 1 + ipapython/secrets/store.py | 53 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index ca7eb6cf47b4442fa538a47c74846e13c25e02e8..bbd95a327971c2c1d75102bdef125dc81327ddff 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -214,6 +214,7 @@ class BasePathNamespace(object): NTPD = "/usr/sbin/ntpd" PKIDESTROY = "/usr/sbin/pkidestroy" PKISPAWN = "/usr/sbin/pkispawn" + PKI = "/usr/bin/pki" REMOVE_DS_PL = "/usr/sbin/remove-ds.pl" RESTORECON = "/usr/sbin/restorecon" SELINUXENABLED = "/usr/sbin/selinuxenabled" diff --git a/ipapython/secrets/store.py b/ipapython/secrets/store.py index 26dcc468863dd758154c820cc4365418abe3eca8..94edd2dd9105e20e3dcd1069fd166d7863c65e44 100644 --- a/ipapython/secrets/store.py +++ b/ipapython/secrets/store.py @@ -51,6 +51,53 @@ def HTTPD_password_callback(): return password +class NSSWrappedCertDB(DBMAPHandler): + ''' + Store that extracts private keys from an NSSDB, wrapped with the + private key of the primary CA. + ''' + + def __init__(self, config, dbmap, nickname): + if 'path' not in dbmap: + raise ValueError('Configuration does not provide NSSDB path') + if 'pwcallback' not in dbmap: + raise ValueError('Configuration does not provide Password Calback') + if 'wrap_nick' not in dbmap: + raise ValueError('Configuration does not provide nickname of wrapping key') + self.nssdb_path = dbmap['path'] + self.nssdb_password = dbmap['pwcallback']() + self.wrap_nick = dbmap['wrap_nick'] + self.target_nick = nickname + + def export_key(self): + tdir = tempfile.mkdtemp(dir=paths.TMP) + try: + nsspwfile = os.path.join(tdir, 'nsspwfile') + with open(nsspwfile, 'w+') as f: + f.write(self.nssdb_password) + wrapped_key_file = os.path.join(tdir, 'wrapped_key') + certificate_file = os.path.join(tdir, 'certificate') + ipautil.run([ + paths.PKI, '-d', self.nssdb_path, '-C', nsspwfile, + 'ca-authority-key-export', + '--wrap-nickname', self.wrap_nick, + '--target-nickname', self.target_nick, + '-o', wrapped_key_file]) + ipautil.run([ + paths.CERTUTIL, '-d', self.nssdb_path, + '-L', '-n', self.target_nick, + '-a', '-o', certificate_file]) + with open(wrapped_key_file, 'r') as f: + wrapped_key = f.read() + with open(certificate_file, 'r') as f: + certificate = f.read() + finally: + shutil.rmtree(tdir) + return json_encode({ + 'wrapped_key': b64encode(wrapped_key), + 'certificate': certificate}) + + class NSSCertDB(DBMAPHandler): def __init__(self, config, dbmap, nickname): @@ -148,6 +195,12 @@ NAME_DB_MAP = { 'handler': NSSCertDB, 'pwcallback': PKI_TOMCAT_password_callback, }, + 'ca_wrapped': { + 'handler': NSSWrappedCertDB, + 'path': paths.PKI_TOMCAT_ALIAS_DIR, + 'pwcallback': PKI_TOMCAT_password_callback, + 'wrap_nick': 'caSigningCert cert-pki-ca', + }, 'ra': { 'type': 'NSSDB', 'path': paths.HTTPD_ALIAS_DIR, -- 2.5.5 From lslebodn at redhat.com Thu May 5 07:56:29 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 5 May 2016 09:56:29 +0200 Subject: [Freeipa-devel] Improving bug reporting In-Reply-To: <572A2FE4.9040604@redhat.com> References: <9f04032d-b28b-1218-b55d-9f7e70273a17@redhat.com> <20160503212440.GB9681@10.4.128.1> <20160504080550.x2ilcs6vdvyac3a2@redhat.com> <20160504084123.GB21729@10.4.128.1> <20160504095629.fisi6bdvwvyiiyvv@redhat.com> <20160504162254.GA12788@10.4.128.1> <572A2FE4.9040604@redhat.com> Message-ID: <20160505075629.GA6327@10.4.128.1> On (04/05/16 13:22), Rob Crittenden wrote: >Lukas Slebodnik wrote: >> On (04/05/16 12:56), Alexander Bokovoy wrote: >> I'm sorry but it was a TL;DR mail without any useful information >> to the topic. >> >> The topic is "Improving bug reporting". I do not care much >> how downstreams handle bug reports. >> >> I like David proposal with template. But I do not like >> proposal for debian; because there isn't an upstream version. >> therefore I proposed to add recommendation to test with upstream version >> of FreeIPA (fedora) >> >> We should be very kind to users of other distributions but it happen >> to me that my direct reports to upstream were closed because >> fedora had patched version of packages. I did't like this way >> but I understant why it was closed in upstream. >> >> I did not propose to directly close tickets reported for non-upstream versions. >> I proposed to add an recommendation to the template to test with upstream >> version. >> >> BTW We also suggest such way also in sssd. We have some users who had problems >> with sssd due to buggy version of sssd in downstram (el7.1). We fixed many bugs >> in upstream but they were not fixed in downstream. Therefore we started >> to build upstream versions of sssd to older distributions[1]. >> We *SAVED* a lot of time due to this recommendation. This is a best practice >> which we use also for reports from ubuntu 14.04. There is buggy version of >> sssd-1.11.5.1 and it does not worth to spend a time with investigation unless >> bug is confirmed with latest upstream version. Fortunately, Timo has latest >> upstream version of sssd in ppa. If there wasn't a ppa I would prepare >> it myself. > >I don't think sssd is something to measure against in this case. IPA has so >many more moving parts it has taken quite a lot longer to get near the same >point as sssd. Debian support has almost literally been a one-man operation. > This is yet another reason to test with upstream version of FreeIPA (or with version which is more tested) before reporing a bug. There are projects which test on more platforms(debian, centos, fedora) in upstream (cockpit, sssd ...). It would be good if FreeIP get to this state but we are not there yet. Therefore if we want to have a reasonable bug report we shoudl recommend to test with better supported version. sssd was just an example how it is helpful to test with latest upstream version before reporting a bug. The same applies to any project. >IPA as a server didn't work in any real way until Timo got 4.3.1 built >because without replication it's an interesting but non-production exercise. >So IMHO any existing server builds on old platforms are not supportable. The >same is probably true for the client packages which had all sorts of gotchas. > >Timo has done an terrific job getting his patches upstream, quite a few of >which have been specifically to make IPA more distro agnostic. > >So honestly, I think a new line should be drawn using 4.3.1 as the starting >point and provide just best-effort support for older releases. So workarounds >only and probably no patches unless you can show it also affects the latest, >and if Timo wants to backport then that's up to him. > FreeIPA 4.3 branch is not branch with long term support from upstrem point of view. I would wait for 4.4. >As for the template, part of the problem with the trac tickets is it is often >developers filing bugs against things they see and I know I've filed a ton of >awful, no details bugs thinking I'd get to it "real soon" and then not. A >template might help at least remind what is necessary, but that is just as >easily ignorable as the almost identical template in bugzilla. > >So I'd say it's up to the first round of triage to push back on poorly filed >tickets. Maybe give Petr a ban hammer to close any incomplete tickets when >they come in. I think devs would get the idea pretty quickly. He could be >gentler with user-reported issues. > +1 LS From dkupka at redhat.com Thu May 5 11:36:43 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 5 May 2016 13:36:43 +0200 Subject: [Freeipa-devel] [PATCH 0472] fix stageuser-find test In-Reply-To: <572A0720.2010009@redhat.com> References: <572A0720.2010009@redhat.com> Message-ID: <07c08ae2-b3f1-f91f-d329-e5223b9631b4@redhat.com> On 04/05/16 16:28, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5281 > > I forgot to send patch that fixes also stageuser tests with current > changes in has_keytab and has_password attributes. > > Patch attached > > Stageuser test suite is passing again, ACK. test_xmlrpc/test_stageuser_plugin.py ............................................................................. -- David Kupka From mkubik at redhat.com Thu May 5 12:58:07 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 5 May 2016 14:58:07 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5707C9F2.8060903@redhat.com> References: <5707C9F2.8060903@redhat.com> Message-ID: On 04/08/2016 05:10 PM, Martin Babinsky wrote: > Hi list, > > I have put together a draft [1] outlining the effort to reimplement > the handling of Kerberos principals in both backend and frontend > layers of FreeIPA so that we may have multiple aliases per user, host > or service and thus implement stuff like > https://fedorahosted.org/freeipa/ticket/3961 and > https://fedorahosted.org/freeipa/ticket/5413 . > > Since much of the plumbing was already implemented,[2] the document > mainly describes what the patches do. Some parts required by other use > cases may be missing so please point these out. > > I would also be happy if you could correct all factual inacurracies, I > did research on this issue a long time ago and my knowledge turned a > bit rusty. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > [2] > https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > Hi! I went through the design document and the related email thread here on the list and I have few questions: 1. Is there any progress on what's to happen if MODRDN would colide with an existing alias on a different entry? 2. How does this RFE change the behavior of stage user plugin? Is the principal (as in the canonical name) assigned at this stage of user lifetime? 3. Will there be any constraints on what string can be used as an alias? (The document mentions email address as one use case) 4. Will this RFE have any impact on AD trust (possibility of cross realm routing, RFC 6806 section 9) Otherwise the document looks good from my POV as QE. Regards, -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 5 13:22:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 May 2016 09:22:22 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0472] fix stageuser-find test In-Reply-To: <07c08ae2-b3f1-f91f-d329-e5223b9631b4@redhat.com> Message-ID: <1471102420.48781241.1462454542264.JavaMail.zimbra@redhat.com> On 05.05.2016 13:36, David Kupka wrote: On 04/05/16 16:28, Martin Basti wrote:
https://fedorahosted.org/freeipa/ticket/5281 I forgot to send patch that fixes also stageuser tests with current changes in has_keytab and has_password attributes. Patch attached Stageuser test suite is passing again, ACK. test_xmlrpc/test_stageuser_plugin.py .............................................................................
Pushed to master: b87a825d7448f87ea1f94da5fc9d6b211cd1334f -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu May 5 13:44:41 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 5 May 2016 15:44:41 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5729E929.6010307@redhat.com> References: <5729E929.6010307@redhat.com> Message-ID: On 05/04/2016 02:20 PM, thierry bordaz wrote: > Hello, > > I have been doing some tests/measures using > https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. > The tool creates a set of typical users/hosts/groups... to import with a > ldapadd. > > I wrote down some finding in > http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. > I still have to do some cleanup around the performance but the basic of a > possible improvement is to do provisioning in several steps (disabling > plugins, provisioning, enabling plugin, running fixup tasks). > > Before going further in the design I wanted to share those ideas and know if > it raise any concern. > > thanks > thierry > Hi Thierry, Thanks for the analysis. Very nice. Knowing this will help us suggesting workarounds also for old releases. Couple questions: Have you tested retrCL disabled with memberOf enabled. It seems that it would eliminate 550K adds and 0.8M searches. What would be the time improvement? Do you know what is the time when memberof is enabled but slapi-nis and retroCL are disabled? >From the text it was not clear to me, if you find or investigate possible improvements in memberof plugin which would improve the performance without stopping and starting DS. -- Petr Vobornik From pviktori at redhat.com Thu May 5 13:53:27 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 5 May 2016 15:53:27 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <5729E32E.6050103@redhat.com> References: <57239E10.9070501@redhat.com> <57277A03.2060701@redhat.com> <81e1f975-e4f8-99f3-ebde-402fcb4746bf@redhat.com> <5728AD15.10502@redhat.com> <5728B63E.30704@redhat.com> <5728CE6F.5060202@redhat.com> <5729E32E.6050103@redhat.com> Message-ID: <572B5057.1020007@redhat.com> On 05/04/2016 01:55 PM, Martin Basti wrote: > > > On 03.05.2016 18:14, Petr Viktorin wrote: >> On 05/03/2016 04:31 PM, Martin Basti wrote: >>> >>> On 03.05.2016 15:52, Petr Viktorin wrote: >>>> On 05/03/2016 03:02 PM, Petr Spacek wrote: >>>>> On 2.5.2016 18:02, Martin Basti wrote: >>>>>> On 29.04.2016 19:46, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> These patches concentrate on tests, and code that was added/changed >>>>>>> since I last looked at the FreeIPA project. >>>>>>> >>>>>>> With these patches, I'm back to getting the same errors under py2 >>>>>>> and >>>>>>> py3 when in test_xmlrpc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Patch 777: >>>>>> Could you fix all relative imports and enable check in pylint for >>>>>> that? >>>>>> (Remove relative-import from pylintrc), IMO there is just one extra >>>>>> relative >>>>>> import in custodia module. >>>> Would it be OK if I do that in a separate patch, in the next batch? >>>> This >>>> one is fixing the tests. >>>> (I have the change in my worktree, so I won't forget when I next sit >>>> down to work on IPA.) >>> It is okay to send it in a next patch :) >>> ACK on this patch then >>>>>> Do you plan to use in py2 ? >>>>>> from__future__importabsolute_import >>>> I think that's unnecessary boilerplate; the errors this catches are >>>> easily found by other means. >>>> And it doesn't guard against someone forgetting the __future__ import >>>> itself in a new file. The pylint check will be much better. >>> Ok, just FYI pylint has check that prevents forgetting this import >>> (disabled in IPA) >>> >>>>>> Patch 778: >>>>>> LGTM >>>>>> >>>>>> Patch 779 >>>>>> LGTM >>>>>> >>>>>> Patch 780 >>>>>> LGTM >>>>>> >>>>>> Patch 781 >>>>>> LGTM >>>>>> >>>>>> Patch 782 >>>>>> Not sure, I will review it longer >>>>>> >>>>>> Patch 783 >>>>>> LGTM >>>>>> >>>>>> Patch 784 >>>>>> LGTM >>>>>> >>>>>> Patch 785 >>>>>> LGTM >>>>>> >>>>>> I will test it with both py2 and py3 to convert LGTM to ACK :) >>>>> Functional ACK, I did not find any breakage (when combined with other >>>>> Py3 >>>>> patches). >>>>> >>> Hold your horses :D, I probably find something in tests >>> >>> I run ipa-run-tests with xmlrpc tests under python2 and python3, please >>> note the different count of tests and errors in py3 >>> >>> platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 >>> -- /usr/bin/python >>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>> collecting ... collected 1835 items >>> >>> platform linux -- Python 3.5.1, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 -- >>> /bin/python3 >>> rootdir: /usr/lib/python3.5/site-packages/ipatests, inifile: pytest.ini >>> collecting ... collected 1694 items / 7 errors >>> >>> >>> Collecting failed on following import errors: >>> test_xmlrpc/test_add_remove_cert_cmd.py:13: in >>> ipatests.test_xmlrpc.testcert import get_testcert >>> xmlrpc/testcert.py:34: in >>> ipaserver.plugins import rabase >>> ImportError: No module named 'ipaserver' >>> >>> And I found more errors, but they may be unrelated I have to investigate >>> more >>> Martin^2 >> Right, some of the xmlrpc tests use ipaserver, which isn't fully ported >> yet, and the python3-ipaserver RPM isn't even built. The parts of >> ipaserver needed for these tests will be my next goal. >> > OK > > However I see errors under py3 in cert tests > > [...] For me, those tests don't pass under Python 2 either, but I'll keep looking. Is this blocking the other patches? -- Petr Viktorin From ofayans at redhat.com Thu May 5 14:10:09 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 May 2016 16:10:09 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Certs_in_ID_overrides Message-ID: <572B5441.6090103@redhat.com> Hi, The document looks fine. Would be nice if it had some link on a HOWTO page about generation of a user certificate to use for AD-originated users. Apart from that - everything is pretty clear -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Thu May 5 14:28:31 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 May 2016 16:28:31 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Server_Roles Message-ID: <572B588F.5080400@redhat.com> The document is perfect. No remarks from QE side: ready for testplan design -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From thozza at redhat.com Thu May 5 14:44:39 2016 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 5 May 2016 16:44:39 +0200 Subject: [Freeipa-devel] [PATCH 0391-0392] Add missing return value checks to pthread operations & replace strcmp(var, "") with strlen(var) to workaround Clang bug 20144 In-Reply-To: <56D59AE9.1040004@redhat.com> References: <56D59AE9.1040004@redhat.com> Message-ID: On 03/01/2016 02:36 PM, Petr Spacek wrote: > Hello, > > Add missing return value checks to pthread operations. > Detected by clang 3.8 -O2 -Wunused-value. > > Replace strcmp(var, "") with strlen(var) to workaround Clang bug 20144. > https://llvm.org/bugs/show_bug.cgi?id=20144 > ACK. I was not able to reproduce the issues. However the changes look good to me. I tested the plugin on Fedora 24 with basic tasks (query, zone transfer, DNS update) without DNSSEC signing. Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com From mbasti at redhat.com Thu May 5 14:45:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 May 2016 10:45:17 -0400 (EDT) Subject: [Freeipa-devel] Another batch of Python 3 patches In-Reply-To: <572B5057.1020007@redhat.com> Message-ID: <951715715.48843327.1462459517282.JavaMail.zimbra@redhat.com> On 05.05.2016 15:53, Petr Viktorin wrote: On 05/04/2016 01:55 PM, Martin Basti wrote:
On 03.05.2016 18:14, Petr Viktorin wrote:
On 05/03/2016 04:31 PM, Martin Basti wrote:
On 03.05.2016 15:52, Petr Viktorin wrote:
On 05/03/2016 03:02 PM, Petr Spacek wrote:
On 2.5.2016 18:02, Martin Basti wrote:
On 29.04.2016 19:46, Petr Viktorin wrote:
Hello, These patches concentrate on tests, and code that was added/changed since I last looked at the FreeIPA project. With these patches, I'm back to getting the same errors under py2 and py3 when in test_xmlrpc. Patch 777: Could you fix all relative imports and enable check in pylint for that? (Remove relative-import from pylintrc), IMO there is just one extra relative import in custodia module.
Would it be OK if I do that in a separate patch, in the next batch? This one is fixing the tests. (I have the change in my worktree, so I won't forget when I next sit down to work on IPA.)
It is okay to send it in a next patch :) ACK on this patch then
Do you plan to use in py2 ? from__future__importabsolute_import
I think that's unnecessary boilerplate; the errors this catches are easily found by other means. And it doesn't guard against someone forgetting the __future__ import itself in a new file. The pylint check will be much better.
Ok, just FYI pylint has check that prevents forgetting this import (disabled in IPA)
Patch 778: LGTM Patch 779 LGTM Patch 780 LGTM Patch 781 LGTM Patch 782 Not sure, I will review it longer Patch 783 LGTM Patch 784 LGTM Patch 785 LGTM I will test it with both py2 and py3 to convert LGTM to ACK :)
Functional ACK, I did not find any breakage (when combined with other Py3 patches).
Hold your horses :D, I probably find something in tests I run ipa-run-tests with xmlrpc tests under python2 and python3, please note the different count of tests and errors in py3 platform linux2 -- Python 2.7.11, pytest-2.8.7, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini collecting ... collected 1835 items platform linux -- Python 3.5.1, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 -- /bin/python3 rootdir: /usr/lib/python3.5/site-packages/ipatests, inifile: pytest.ini collecting ... collected 1694 items / 7 errors Collecting failed on following import errors: test_xmlrpc/test_add_remove_cert_cmd.py:13: in ipatests.test_xmlrpc.testcert import get_testcert xmlrpc/testcert.py:34: in ipaserver.plugins import rabase ImportError: No module named 'ipaserver' And I found more errors, but they may be unrelated I have to investigate more Martin^2
Right, some of the xmlrpc tests use ipaserver, which isn't fully ported yet, and the python3-ipaserver RPM isn't even built. The parts of ipaserver needed for these tests will be my next goal.
OK However I see errors under py3 in cert tests
[...] For me, those tests don't pass under Python 2 either, but I'll keep looking. Is this blocking the other patches?
Well I'm sure that under py2 those tests passed, and in jenkins they pass as well. I tested it without your patches and py3 tests failed with same errors as I reported, so ACK. (but would be nice to fix it :) ) Pushed to master: * f753ad322dfdd81907a309827bddfcb1e47917a7 test_xmlrpc: Use absolute imports * 6406c7a5935e9fb9cd41af49f67d6200021b3574 xmlrpc_test: Rename exception instance before working with it * 890f83b0bbd5ec03397e817ed1282fa66efab7da radiusproxy plugin: Use str(error) rather than error.message * 095d0cb7afc3d404829d87bc894d8691be2228ef xmlrpc_test: Expect bytes rather than strings for binary attributes * baaa041b8a272e43c99f00f69fc645a2e92216db ipalib.rpc: Send base64-encoded data as string under Python 3 * 14aba1c7c16e3b4e6375305990fffbd86cefbfdd range plugin tests: Use bytes with MockLDAP under Python 3 * bdee89001455825bfe2c7e820c6b2d651f1f45eb radiusproxy plugin tests: Expect bytes, not text, for ipatokenradiussecret * 6ddf0d657f70eb03d17af2e63eb52d6ef33305be certprofile plugin: Use binary mode for file with binary data * 20a6a42567f0fa21945f02aa58420c31bc0c9127 test_add_remove_cert_cmd: Use bytes for base64.b64encode() ipa-4-3: * 5750c3ece9359ca5a1c9ddbbf727eb63862709ce test_xmlrpc: Use absolute imports * ba3d77253a54e862249476e3d289ebf01f1a9f9a xmlrpc_test: Rename exception instance before working with it * a514ebdc81548f37e5fedb7bb43ca7ddab473af8 radiusproxy plugin: Use str(error) rather than error.message * 4c68bd671a89f3ddda0c09f9abffe0e1b87098cb xmlrpc_test: Expect bytes rather than strings for binary attributes * 72fb2674117ee8c3c1cafa17512e524ea437f966 ipalib.rpc: Send base64-encoded data as string under Python 3 * 8f637bc9b1343979a0ead7346a5b0d771f133420 range plugin tests: Use bytes with MockLDAP under Python 3 * aa052a0976ce3ab643fd54a10bc5428711dd9b61 radiusproxy plugin tests: Expect bytes, not text, for ipatokenradiussecret * ffb8fcc20848b570bff7a7776ad08d23ac882ff5 certprofile plugin: Use binary mode for file with binary data * c009ea8a7622a567de2101d8577955942e67a44d test_add_remove_cert_cmd: Use bytes for base64.b64encode() -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 5 15:06:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 May 2016 11:06:42 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] Fix added to ipa-compat-manage command line help In-Reply-To: <950a6605-0b34-7a83-437f-81e882d96e28@redhat.com> Message-ID: <493017644.48848390.1462460802441.JavaMail.zimbra@redhat.com> On 03.05.2016 15:20, Petr Spacek wrote: On 2.5.2016 12:43, Abhijeet Kasurde wrote:
Hi All, Please review this patch. ACK
Pushed to master: * 42bcbcf460811fe2ee7468ef06b86510981ddefc Fix added to ipa-compat-manage command line help -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Fri May 6 04:26:55 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 6 May 2016 09:56:55 +0530 Subject: [Freeipa-devel] [PATCH] Replaced find_hostname with api.env.host Message-ID: <572C1D0F.5010704@redhat.com> Hi All, Please review this patch. Thanks for mbasti for helping me. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0012-Replaced-find_hostname-with-api.env.host.patch Type: text/x-patch Size: 1957 bytes Desc: not available URL: From jcholast at redhat.com Fri May 6 05:13:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 6 May 2016 07:13:19 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <5721E3BA.4030409@redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> <20160407115302.GL4768@p.redhat.com> <570DFB66.9040207@redhat.com> <570E3800.1060700@redhat.com> <5715CE17.8090503@redhat.com> <5721E3BA.4030409@redhat.com> Message-ID: <967698b2-8be9-7c37-390c-8929b5a81d49@redhat.com> On 28.4.2016 12:19, Tomas Babej wrote: > > > On 04/19/2016 08:20 AM, Jan Cholasta wrote: >> On 13.4.2016 14:13, Tomas Babej wrote: >>> On 04/13/2016 09:55 AM, Tomas Babej wrote: >>>> On 04/07/2016 01:53 PM, Sumit Bose wrote: >>>>> On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 1.4.2016 16:53, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this extends the user ID overrides with capability to store the user >>>>>>> certificate. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4955 >>>>>> >>>>>> The preferred way of managing certificates nowadays is using >>>>>> $OBJ-add-cert >>>>>> and $OBJ-remove-cert commands, you should add them here as well. >>>>>> >>>>>> I would even go as far as not allowing to modify certificates using >>>>>> idoverrideuser-mod - in user-mod and host-mod, it's there just for >>>>>> backward >>>>>> compatibility, which is not the case here. But I don't have a >>>>>> strong opinion >>>>>> on that. >>>>>> >>>>>> For consistency with user-find and host-find, the full certificate >>>>>> blob >>>>>> should not be shown in idoverrideuser-find. You can do that by setting >>>>>> search_display_attributes attribute on the idoverrideuser class >>>>>> appropriately. >>>>> >>>>> I tested the current patch with my related patches for SSSD and all is >>>>> working as expected. >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>>>> >>>>>> Honza >>>>>> >>>>>> -- >>>>>> Jan Cholasta >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-devel mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >>>>> >>>> >>>> Thanks for the reviews, >>>> >>>> attaching a updated patch that addresses Honza's comments. >>>> >>>> Tomas >>>> >>> >>> Sending an improved version addressing a couple of additional issues. >> >> 1) This bit in idoverrideuser_add.pre_callback() is redundant, as the >> certificate will always be DER here already: >> >> # Normalize the certificate to DER format >> certs = options.get('usercertificate', []) >> certs_der = [x509.normalize_certificate(c) for c in certs] >> entry_attrs['usercertificate'] = certs_der >> >> >> 2) You need to call convert_usercertificate_pre() in >> idoverrideuser_mod.pre_callback() and convert_usercertificate_post() in >> idoverrideuser_{mod,find,show}.post_callback() as well. >> >> Honza >> > > Updated patch attached, mentioned issues should be fixed, I also removed > one redundant import which escaped my careful eye. Thanks, ACK. Added ticket URL and pushed to master: 6adf86378108cdf8b0825277431419a5e803aeb5 -- Jan Cholasta From akasurde at redhat.com Fri May 6 05:33:14 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 6 May 2016 11:03:14 +0530 Subject: [Freeipa-devel] [PATCH 0013] Updated ipa-server-install man page for domain-level attribute Message-ID: <572C2C9A.5030000@redhat.com> Hi All, Please review this patch. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0013-Updated-ipa-server-install-man-page-for-domain-level-ipa-4-3.patch Type: text/x-patch Size: 1174 bytes Desc: not available URL: From ftweedal at redhat.com Fri May 6 06:01:58 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 6 May 2016 16:01:58 +1000 Subject: [Freeipa-devel] [DESIGN] Lightweight CA renewal Message-ID: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> Hullo all, FreeIPA Lightweight CAs implementation is progressing well. The remaining big unknown in the design is how to do renewal. I have put my ideas into the design page[1] and would appreciate any and all feedback! [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal Some brief commentary on the options: I intend to implement approach (1) as a baseline. Apart from implementing machinery in Dogtag to actually perform the renewal - which is required for all the approaches - it's not much work and gets us over the "lightweight CAs can be renewed easily" line, even if it is a manual process. For automatic renewal, I am leaning towards approach (2). Dogtag owns the lightweight CAs so I think it makes sense to give Dogtag the ability to renew them automatically (if configured to do so), without relying on external tools i.e. Certmonger. But as you will see from the outlines, each approach has its upside and downside. Cheers, Fraser From ofayans at redhat.com Fri May 6 07:36:43 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 May 2016 09:36:43 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests Message-ID: <572C498B.4060202@redhat.com> Tests are finally stable: ============================= test session starts ============================== platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: multihost, sourceorder collected 8 items test_integration/test_dnssec.py ........ ========================= 8 passed in 5561.48 seconds ========================== -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0037-A-workaround-for-ticket-N-5348.patch Type: text/x-patch Size: 7527 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0038-Added-necessary-A-record-for-replica-to-root-zone.patch Type: text/x-patch Size: 1208 bytes Desc: not available URL: From mbasti at redhat.com Fri May 6 07:48:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 09:48:37 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C498B.4060202@redhat.com> References: <572C498B.4060202@redhat.com> Message-ID: <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> On 06.05.2016 09:36, Oleg Fayans wrote: > Tests are finally stable: > > ============================= test session starts > ============================== > platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > plugins: multihost, sourceorder > collected 8 items > > test_integration/test_dnssec.py ........ > > ========================= 8 passed in 5561.48 seconds > ========================== > > > > > PATCH 38 LGTM PATCH 37 IIRC I refused to accept workaround for this issue when you send this (almost the same) patch for first time, are you sure that we want to hide real issues in tests, to just have green color there? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri May 6 08:20:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 10:20:20 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue Message-ID: https://fedorahosted.org/freeipa/ticket/2008 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch Type: text/x-patch Size: 5129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch Type: text/x-patch Size: 4063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch Type: text/x-patch Size: 14336 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0476-DNS-Locations-API-tests.patch Type: text/x-patch Size: 9269 bytes Desc: not available URL: From ofayans at redhat.com Fri May 6 09:14:58 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 May 2016 11:14:58 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> Message-ID: <572C6092.3010804@redhat.com> On 05/06/2016 09:48 AM, Martin Basti wrote: > > > On 06.05.2016 09:36, Oleg Fayans wrote: >> Tests are finally stable: >> >> ============================= test session starts >> ============================== >> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >> plugins: multihost, sourceorder >> collected 8 items >> >> test_integration/test_dnssec.py ........ >> >> ========================= 8 passed in 5561.48 seconds >> ========================== >> >> >> >> >> > PATCH 38 LGTM > > PATCH 37 IIRC I refused to accept workaround for this issue when you > send this (almost the same) patch for first time, are you sure that we > want to hide real issues in tests, to just have green color there? > The underlying issue is 7 months old. Latest update in the issue from Peter Spacek is: "I do not have time to investigate this issue now", which means, that it will stay there for unpredictable amount of time more. If we want to have a "green" jenkins that actually tests existing features, we have to accept workarounds for such long-term issues > Martin -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Fri May 6 09:42:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 11:42:09 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C6092.3010804@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> Message-ID: <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> On 06.05.2016 11:14, Oleg Fayans wrote: > > On 05/06/2016 09:48 AM, Martin Basti wrote: >> >> On 06.05.2016 09:36, Oleg Fayans wrote: >>> Tests are finally stable: >>> >>> ============================= test session starts >>> ============================== >>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>> plugins: multihost, sourceorder >>> collected 8 items >>> >>> test_integration/test_dnssec.py ........ >>> >>> ========================= 8 passed in 5561.48 seconds >>> ========================== >>> >>> >>> >>> >>> >> PATCH 38 LGTM >> >> PATCH 37 IIRC I refused to accept workaround for this issue when you >> send this (almost the same) patch for first time, are you sure that we >> want to hide real issues in tests, to just have green color there? >> > The underlying issue is 7 months old. Latest update in the issue from > Peter Spacek is: "I do not have time to investigate this issue now", > which means, that it will stay there for unpredictable amount of time > more. If we want to have a "green" jenkins that actually tests existing > features, we have to accept workarounds for such long-term issues > >> Martin I leave decision if push this or not to different people, however I will do review on this. NACK 1) Why do you change sleep time? How is it related to workaround? - time.sleep(20) # sleep a bit until LDAP changes are applied to DNS + time.sleep(10) # sleep a bit until LDAP changes are applied to DNS 2) why do you removes sleep from several places? How is this related to workaround? @@ -281,13 +302,19 @@ class TestInstallDNSSECFirst(IntegrationTest): "--a-rec=" + self.master.ip ] self.master.run_command(args) - time.sleep(10) # sleep a bit until data are provided by bind-dyndb-ldap args = [ "ipa", "dnsrecord-add", root_zone, self.master.domain.name, "--ns-rec=" + self.master.hostname ] self.master.run_command(args) 3) You restart the same replica twice + time.sleep(10) # sleep a bit until LDAP changes are applied to DNS + # A workaround for ticket N 5348 + self.replicas[0].run_command(["systemctl", "restart", + "named-pkcs11.service"]) + self.replicas[0].run_command(["systemctl", "restart", + "named-pkcs11.service"]) + # End of workaround 4) Can you create a function doing workaround instead of copying the same code several times? something like def restart_named(*args): for host in args: # host$ systemctl restart named-pkcs11 where args are instances self.host, or self.master, or self.replica 5) Why did you removed this comment? - # wait until zone is signed 6) I'm not sure, but is sleep there needed? Because restart of named will download all LDAP data again. If timeout is required maybe reason why time is there should be rephrased, to something like, make sure the dnssec keys were exported for named, or so. + time.sleep(10) # sleep a bit until LDAP changes are applied to DNS + # A workaround for ticket N 5348 + self.master.run_command(["systemctl", "restart", + "named-pkcs11.service"]) + self.replicas[0].run_command(["systemctl", "restart", + "named-pkcs11.service"]) + # End of workaround Martin^2 From mbabinsk at redhat.com Fri May 6 10:08:43 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 May 2016 12:08:43 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C6092.3010804@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> Message-ID: <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> On 05/06/2016 11:14 AM, Oleg Fayans wrote: > > > On 05/06/2016 09:48 AM, Martin Basti wrote: >> >> >> On 06.05.2016 09:36, Oleg Fayans wrote: >>> Tests are finally stable: >>> >>> ============================= test session starts >>> ============================== >>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>> plugins: multihost, sourceorder >>> collected 8 items >>> >>> test_integration/test_dnssec.py ........ >>> >>> ========================= 8 passed in 5561.48 seconds >>> ========================== >>> >>> >>> >>> >>> >> PATCH 38 LGTM >> >> PATCH 37 IIRC I refused to accept workaround for this issue when you >> send this (almost the same) patch for first time, are you sure that we >> want to hide real issues in tests, to just have green color there? >> > > The underlying issue is 7 months old. Latest update in the issue from > Peter Spacek is: "I do not have time to investigate this issue now", > which means, that it will stay there for unpredictable amount of time > more. If we want to have a "green" jenkins that actually tests existing > features, we have to accept workarounds for such long-term issues > >> Martin > I have never been a big fan of "having a green jenkins whatever it takes" but I understand that there are all kinds of pressure on your team to deliver 100% stable test results. If the test fails, let it fail or, even better, use 'xfail' markers so that we know that this test fails and we should investigate. I fit fails for such a long time, we should really invest some time to look for the root cause of failure(s). If the appointed person does not have time for this, he/she should be able to negotiate some time allocated for the investigation. If you feel that the test failures are not getting enough attention from us then you perhaps need to be more proactive in the reporting. We really should be fixing issues, not adding workarounds so that tests pass. -- Martin^3 Babinsky From lslebodn at redhat.com Fri May 6 10:22:29 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 6 May 2016 12:22:29 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C6092.3010804@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> Message-ID: <20160506102228.GB13550@10.4.128.1> On (06/05/16 11:14), Oleg Fayans wrote: >On 05/06/2016 09:48 AM, Martin Basti wrote: >> On 06.05.2016 09:36, Oleg Fayans wrote: >>> Tests are finally stable: >>> >>> ============================= test session starts >>> ============================== >>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>> plugins: multihost, sourceorder >>> collected 8 items >>> >>> test_integration/test_dnssec.py ........ >>> >>> ========================= 8 passed in 5561.48 seconds >>> ========================== >>> >>> >>> >>> >>> >> PATCH 38 LGTM >> >> PATCH 37 IIRC I refused to accept workaround for this issue when you >> send this (almost the same) patch for first time, are you sure that we >> want to hide real issues in tests, to just have green color there? >> > >The underlying issue is 7 months old. Latest update in the issue from >Peter Spacek is: "I do not have time to investigate this issue now", So the solution should be to escalate this issue and ensure that Petr's manager reserve enough time for him to fix the bug. The bug is in FreeIPA and not in test and therefore tests should not be changed. If you want to add workaround then please add workaround(s) to the freeipa related part of code. LS From slaznick at redhat.com Fri May 6 10:28:28 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 6 May 2016 12:28:28 +0200 Subject: [Freeipa-devel] [WIP][PATCH] Time-Based HBAC Policies In-Reply-To: <56FBAE4E.6020600@redhat.com> References: <56D9935D.9050507@redhat.com> <56E04E38.8080804@redhat.com> <56FBAE4E.6020600@redhat.com> Message-ID: <572C71CC.4000302@redhat.com> Hello, The time rules for FreeIPA effort is now to be found on Github. I forked FreeIPA and SSSD repos and added the current state of work there. https://github.com/stlaz/freeipa/tree/timerules https://github.com/stlaz/sssd/tree/freeipa-timerules Please note that if I'll be making changes to the code it will be done through rebasing so you may not necessarily be always able to easily pull the repository. I also updated the design so that I may present the current state of the effort to SSSD developers. The SSSD code is almost finished - some more tests may be necessary and I still need to do python bindings. Also, as the pam_hbac module seems to aim for portability, I will need to discuss the system of getting time zone information on various systems but the current solution should work just fine on Red Hat-like and Debian-like distributions. In the meantime, I published quite a patch for python-icalendar that should make it a bit stricter parser but also improve some of its behavior: https://github.com/collective/icalendar/pull/192. Standa From mbasti at redhat.com Fri May 6 12:32:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 14:32:13 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> Message-ID: <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> On 28.04.2016 14:45, Jan Cholasta wrote: > Hi, > > I have pushed my thin client WIP branch to GitHub: > . > > All commits up to "ipalib: use relative imports for cross-plugin > imports" should be good for review. The rest is subject to change > (WARNING: I will force push into this branch). > > Honza > I did not test it yet, I just checked the code * automount: do not inherit automountlocation_tofiles from LDAPQuery * LGTM * dns: move all dnsrecord code called on client to a single class * LGTM * dns: do not rely on server data structures in code called on client * 1) you forgot to increment VERSION Otherwise LGTM * otptoken: fix import of DN * ACK * otptoken_yubikey: fix otptoken_add_yubikey arguments * 1) you forgot to increment VERSION 2) Did you find out why this was issue? - del answer['value'] # Why does this cause an error if omitted? - del answer['summary'] # Why does this cause an error if omitted? Otherwise LGTM * vault: move client-side code to the module level * LGTM * vault: copy arguments of client commands from server counterparts * 1) you forgot to increment Version * ipalib: use relative imports for cross-plugin imports * 1) Missing explanation for future generations why this change is needed in commit message The other commits I will check later. Martin^2 From sbose at redhat.com Fri May 6 12:44:44 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 6 May 2016 14:44:44 +0200 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <1462397635.1537.70.camel@redhat.com> References: <1462397635.1537.70.camel@redhat.com> Message-ID: <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote: > This series of patches implements authentication indicator insertion, > evaluation and management in FreeIPA. Besides these patches, two other > patches are needed to round out support. > > First, we need a UI patch:?https://fedorahosted.org/freeipa/ticket/5872 > > Second, we need a SSSD patch to handle the new case where multiple > responders are set (when either 1FA or 2FA can be used). I've already some initial work done here and will continue with your patches. > > Please note that the last patch in this series (0093) is untested and > simply represents my desire to get these patches off of my hard disk > before I take a long weekend. This patch also requires mrogers' patch > 0001 (already merged to master). > > Also worthy of note is the need for an OID for the authentication > control. Hopefully Simo can assign this after we agree that this > control method is sufficient. One question I had was whether or not it > would be possible to send the control only on UNIX sockets (0089; > report_auth_method()). > > Please review the approaches taken here. I plan to hit this hard on > Monday. I'm on a conference next week and currently busy preparing my presentation. I will give you feedback in the following week. bye, Sumit > > Nathaniel From mbasti at redhat.com Fri May 6 12:45:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 14:45:49 +0200 Subject: [Freeipa-devel] [PATCH] 0001 (update 2) provide more information for "ipa cert-revoke -h" In-Reply-To: References: <0ffbca59-c6ad-3f82-a4c6-127f0b8365e6@gmail.com> Message-ID: On 04.05.2016 14:30, Gabe Alford wrote: > On Wed, May 4, 2016 at 1:35 AM, Patrice Duc-Jacquet > > wrote: > > Hi everyone > > this is a second update that take into account review feedback. > > In case the proposal fix is K what are the next step to commit > this change. I'm not sure to really understand the process. Thanks > and regards > > > If the fix is good, you receive an ack and a core member of the > FreeIPA team will take your ack'ed patch and push it to the official > git repository. > > ACK from me > > Gabe > > Pat > > > -- > 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 > > > > Hello, I agree with ACk, but I cannot apply the patch using git am -3, can you please send rebased version? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 6 12:57:41 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 6 May 2016 14:57:41 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <57149B5B.1050909@redhat.com> References: <5707C9F2.8060903@redhat.com> <57149B5B.1050909@redhat.com> Message-ID: <94a7e07d-6871-15cf-f427-79dc05234fd8@redhat.com> On 04/18/2016 10:31 AM, Martin Kosek wrote: > On 04/08/2016 05:10 PM, Martin Babinsky wrote: >> Hi list, >> >> I have put together a draft [1] outlining the effort to reimplement the >> handling of Kerberos principals in both backend and frontend layers of FreeIPA >> so that we may have multiple aliases per user, host or service and thus >> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and >> https://fedorahosted.org/freeipa/ticket/5413 . >> >> Since much of the plumbing was already implemented,[2] the document mainly >> describes what the patches do. Some parts required by other use cases may be >> missing so please point these out. >> >> I would also be happy if you could correct all factual inacurracies, I did >> research on this issue a long time ago and my knowledge turned a bit rusty. >> >> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > > Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also > see that you are using the Kerberos attributes in the raw name > ("--krbprincipalname"). This is not consistent with the CLI form when they are > used in other commands: > > ... > Str('krbprincipalname?', validate_principal, > cli_name='principal', > label=_('Kerberos principal'), > default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm), > autofill=True, > flags=['no_update'], > normalizer=lambda value: normalize_principal(value), > ), > DateTime('krbprincipalexpiration?', > cli_name='principal_expiration', > label=_('Kerberos principal expiration'), > ), > ... > > IMO, it should be rather "--principal" and "--principal-alias". > > Martin > Bump. From ofayans at redhat.com Fri May 6 12:58:35 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 May 2016 14:58:35 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> Message-ID: <572C94FB.8050408@redhat.com> On 05/06/2016 11:42 AM, Martin Basti wrote: > > > On 06.05.2016 11:14, Oleg Fayans wrote: >> >> On 05/06/2016 09:48 AM, Martin Basti wrote: >>> >>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>> Tests are finally stable: >>>> >>>> ============================= test session starts >>>> ============================== >>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>> plugins: multihost, sourceorder >>>> collected 8 items >>>> >>>> test_integration/test_dnssec.py ........ >>>> >>>> ========================= 8 passed in 5561.48 seconds >>>> ========================== >>>> >>>> >>>> >>>> >>>> >>> PATCH 38 LGTM >>> >>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>> send this (almost the same) patch for first time, are you sure that we >>> want to hide real issues in tests, to just have green color there? >>> >> The underlying issue is 7 months old. Latest update in the issue from >> Peter Spacek is: "I do not have time to investigate this issue now", >> which means, that it will stay there for unpredictable amount of time >> more. If we want to have a "green" jenkins that actually tests existing >> features, we have to accept workarounds for such long-term issues >> >>> Martin > I leave decision if push this or not to different people, however I will > do review on this. > > > NACK > > 1) > Why do you change sleep time? How is it related to workaround? > > - time.sleep(20) # sleep a bit until LDAP changes are applied to > DNS > + time.sleep(10) # sleep a bit until LDAP changes are applied to > DNS 10 seconds proved to be enough even in our super-slow brno rhevm lab > > > 2) > why do you removes sleep from several places? How is this related to > workaround? > @@ -281,13 +302,19 @@ class TestInstallDNSSECFirst(IntegrationTest): > "--a-rec=" + self.master.ip > ] > self.master.run_command(args) > - time.sleep(10) # sleep a bit until data are provided by > bind-dyndb-ldap > > args = [ > "ipa", "dnsrecord-add", root_zone, self.master.domain.name, > "--ns-rec=" + self.master.hostname > ] > self.master.run_command(args) Because it's more reasonable to make changes on all hosts and then wait. > > 3) > You restart the same replica twice > + time.sleep(10) # sleep a bit until LDAP changes are applied to > DNS > + # A workaround for ticket N 5348 > + self.replicas[0].run_command(["systemctl", "restart", > + "named-pkcs11.service"]) > + self.replicas[0].run_command(["systemctl", "restart", > + "named-pkcs11.service"]) > + # End of workaround My bad. > > 4) > Can you create a function doing workaround instead of copying the same > code several times? > > something like > def restart_named(*args): > for host in args: > # host$ systemctl restart named-pkcs11 > > where args are instances self.host, or self.master, or self.replica Now, that's a marvelous idea! Implemented. And put the sleep interval in it too just to keep it in one place > > 5) > Why did you removed this comment? > - # wait until zone is signed Because this is kin of obvious from the name of the function: wait_until_record_is_signed > > 6) > I'm not sure, but is sleep there needed? Because restart of named will > download all LDAP data again. It turns out, without this interval the restart does not always help > If timeout is required maybe reason why > time is there should be rephrased, to something like, make sure the > dnssec keys were exported for named, or so. Rephrased > + time.sleep(10) # sleep a bit until LDAP changes are applied to > DNS > + # A workaround for ticket N 5348 > + self.master.run_command(["systemctl", "restart", > + "named-pkcs11.service"]) > + self.replicas[0].run_command(["systemctl", "restart", > + "named-pkcs11.service"]) > + # End of workaround > > Martin^2 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0037.1-A-workaround-for-ticket-N-5348.patch Type: text/x-patch Size: 8037 bytes Desc: not available URL: From ofayans at redhat.com Fri May 6 13:03:46 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 May 2016 15:03:46 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> Message-ID: <572C9632.8080908@redhat.com> On 05/06/2016 12:08 PM, Martin Babinsky wrote: > On 05/06/2016 11:14 AM, Oleg Fayans wrote: >> >> >> On 05/06/2016 09:48 AM, Martin Basti wrote: >>> >>> >>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>> Tests are finally stable: >>>> >>>> ============================= test session starts >>>> ============================== >>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>> plugins: multihost, sourceorder >>>> collected 8 items >>>> >>>> test_integration/test_dnssec.py ........ >>>> >>>> ========================= 8 passed in 5561.48 seconds >>>> ========================== >>>> >>>> >>>> >>>> >>>> >>> PATCH 38 LGTM >>> >>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>> send this (almost the same) patch for first time, are you sure that we >>> want to hide real issues in tests, to just have green color there? >>> >> >> The underlying issue is 7 months old. Latest update in the issue from >> Peter Spacek is: "I do not have time to investigate this issue now", >> which means, that it will stay there for unpredictable amount of time >> more. If we want to have a "green" jenkins that actually tests existing >> features, we have to accept workarounds for such long-term issues >> >>> Martin >> > I have never been a big fan of "having a green jenkins whatever it > takes" but I understand that there are all kinds of pressure on your > team to deliver 100% stable test results. > > If the test fails, let it fail or, even better, use 'xfail' markers so > that we know that this test fails and we should investigate. Then all 8 existing cases would have to be marked as xfailed. > > I fit fails for such a long time, we should really invest some time to > look for the root cause of failure(s). If the appointed person does not > have time for this, he/she should be able to negotiate some time > allocated for the investigation. If you feel that the test failures are > not getting enough attention from us then you perhaps need to be more > proactive in the reporting. I am quite OK if Peter Spacek receives some more time for investigation of the root cause of the problem. What I am not OK with is having a perfectly functional testsuite for otherwise working feature, that is being deferred for months just because we do not approve of issue workarounds. > > We really should be fixing issues, not adding workarounds so that tests > pass. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pviktori at redhat.com Fri May 6 13:09:44 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 6 May 2016 15:09:44 +0200 Subject: [Freeipa-devel] [PATCHES] 0786-0788 More Python 3 fixes Message-ID: <572C9798.5030009@redhat.com> Hi, With these patches, xmlrpc_tests pass for me (except those that fail on py2, and, if python3-ipaserver is installed, some in permission that use ldap2 plugin). -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0786-Fix-remaining-relative-import-and-enable-Pylint-chec.patch Type: text/x-patch Size: 1563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0787-ipalib.cli-Improve-reporting-of-binary-values-in-the.patch Type: text/x-patch Size: 1347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0788-test_cert_plugin-Encode-certificate-for-comparison-w.patch Type: text/x-patch Size: 1614 bytes Desc: not available URL: From pviktori at redhat.com Fri May 6 13:13:15 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 6 May 2016 15:13:15 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> Message-ID: <572C986B.5050601@redhat.com> On 05/03/2016 03:01 PM, Petr Spacek wrote: > On 29.4.2016 19:49, Petr Viktorin wrote: >> On 04/12/2016 12:52 PM, Petr Spacek wrote: >>> On 19.2.2016 13:50, Petr Viktorin wrote: >>>> Is it time yet? >>>> >>>> This patch switches /usr/bin/ipa to Python 3 for >>>> - the in-tree ./ipa command >>>> - RPMs, when built with_python3 >>> >>> NACK, the change in 'ipa' command broke ipa dnszone-find: >>> >>> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >>> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found >>> >>> The same command works when I switch python3->python2 in the 'ipa' command. >> >> That error is now fixed, could you please re-review? > > ACK, I did not find any breakage (when combined with other Py3 patches). Hello, Those patches are now merged. Anything I can do to help push this forward? -- Petr Viktorin From mbabinsk at redhat.com Fri May 6 13:18:06 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 May 2016 15:18:06 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <94a7e07d-6871-15cf-f427-79dc05234fd8@redhat.com> References: <5707C9F2.8060903@redhat.com> <57149B5B.1050909@redhat.com> <94a7e07d-6871-15cf-f427-79dc05234fd8@redhat.com> Message-ID: <137efa7c-3b08-e58c-4902-9e6c265e2a2d@redhat.com> On 05/06/2016 02:57 PM, Martin Kosek wrote: > On 04/18/2016 10:31 AM, Martin Kosek wrote: >> On 04/08/2016 05:10 PM, Martin Babinsky wrote: >>> Hi list, >>> >>> I have put together a draft [1] outlining the effort to reimplement the >>> handling of Kerberos principals in both backend and frontend layers of FreeIPA >>> so that we may have multiple aliases per user, host or service and thus >>> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and >>> https://fedorahosted.org/freeipa/ticket/5413 . >>> >>> Since much of the plumbing was already implemented,[2] the document mainly >>> describes what the patches do. Some parts required by other use cases may be >>> missing so please point these out. >>> >>> I would also be happy if you could correct all factual inacurracies, I did >>> research on this issue a long time ago and my knowledge turned a bit rusty. >>> >>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >> >> Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also >> see that you are using the Kerberos attributes in the raw name >> ("--krbprincipalname"). This is not consistent with the CLI form when they are >> used in other commands: >> >> ... >> Str('krbprincipalname?', validate_principal, >> cli_name='principal', >> label=_('Kerberos principal'), >> default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm), >> autofill=True, >> flags=['no_update'], >> normalizer=lambda value: normalize_principal(value), >> ), >> DateTime('krbprincipalexpiration?', >> cli_name='principal_expiration', >> label=_('Kerberos principal expiration'), >> ), >> ... >> >> IMO, it should be rather "--principal" and "--principal-alias". >> >> Martin >> > > Bump. > I have fixed the CLI API a while ago so it should now be more conformant with the rest of the framework. I just forgot to notify the list about the change. Other parts of the design were also revised but we are not there yet since we have to investigate a discrepancy in handling of kinit using alias without canonicalization between AD and MIT Kerberos. We have discussed this with Simo (cc'ed) who promised to ask MIT guys about this. We should restart the discussion about the design. -- Martin^3 Babinsky From pspacek at redhat.com Fri May 6 13:25:03 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 May 2016 15:25:03 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C9632.8080908@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> <572C9632.8080908@redhat.com> Message-ID: <1df30d11-20eb-8ab8-6349-f07736926058@redhat.com> On 6.5.2016 15:03, Oleg Fayans wrote: > > > On 05/06/2016 12:08 PM, Martin Babinsky wrote: >> On 05/06/2016 11:14 AM, Oleg Fayans wrote: >>> >>> >>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>> >>>> >>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>> Tests are finally stable: >>>>> >>>>> ============================= test session starts >>>>> ============================== >>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>>> plugins: multihost, sourceorder >>>>> collected 8 items >>>>> >>>>> test_integration/test_dnssec.py ........ >>>>> >>>>> ========================= 8 passed in 5561.48 seconds >>>>> ========================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>> PATCH 38 LGTM >>>> >>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>> send this (almost the same) patch for first time, are you sure that we >>>> want to hide real issues in tests, to just have green color there? >>>> >>> >>> The underlying issue is 7 months old. Latest update in the issue from >>> Peter Spacek is: "I do not have time to investigate this issue now", >>> which means, that it will stay there for unpredictable amount of time >>> more. If we want to have a "green" jenkins that actually tests existing >>> features, we have to accept workarounds for such long-term issues >>> >>>> Martin >>> >> I have never been a big fan of "having a green jenkins whatever it >> takes" but I understand that there are all kinds of pressure on your >> team to deliver 100% stable test results. >> >> If the test fails, let it fail or, even better, use 'xfail' markers so >> that we know that this test fails and we should investigate. > Then all 8 existing cases would have to be marked as xfailed. That is perfectly fine - the test simply found a bug and we have to fix it. There is no point in having "green" tests just to have them. Let me clarify my comment in the ticket that this is not a test blocker: Red Hat Bugzilla is using this definition of TestBlocker: A test blocker is a bug that prevents at least one test (test case) from being executed. As far as I can tell this issue does not block anything. The tests execute and correctly detect a bug. It would be a TestBlocker if it was e.g. a bug in installer which prevented the install and thus prevented some other test cases from being executed. AFAIK this is not the case. Or am I wrong? >> I fit fails for such a long time, we should really invest some time to >> look for the root cause of failure(s). If the appointed person does not >> have time for this, he/she should be able to negotiate some time >> allocated for the investigation. If you feel that the test failures are >> not getting enough attention from us then you perhaps need to be more >> proactive in the reporting. > > I am quite OK if Peter Spacek receives some more time for investigation > of the root cause of the problem. What I am not OK with is having a > perfectly functional testsuite for otherwise working feature, that is > being deferred for months just because we do not approve of issue > workarounds. Sorry, I do not understand this. What do you mean? >> We really should be fixing issues, not adding workarounds so that tests >> pass. +1, it is just a matter of priority -- Petr^2 Spacek From jefferyharrell at gmail.com Wed May 4 18:23:19 2016 From: jefferyharrell at gmail.com (Jeffery Harrell) Date: Wed, 4 May 2016 11:23:19 -0700 Subject: [Freeipa-devel] LDAP attributes with incompatible names? Message-ID: Hi. I?m trying to find a way to expose via the Python plugin API some non-default LDAP attributes that have hyphens in their names ? e.g, "apple-user-homeurl?. Obviously I can?t create a Param with that name. Is there a customary way to handle this kind of situation, or do I have to subclass Param? Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri May 6 13:43:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 May 2016 15:43:12 +0200 Subject: [Freeipa-devel] Should we stop supporting realm != upper(domain) installations? Message-ID: <91ce27cb-451e-9824-3acd-35f8202f289e@redhat.com> Hello, I wonder if we should stop supporting new installations where Kerberos realm != uppercase(primary DNS domain). It breaks a lot of stuff, is harder to manager and docs are full of warnings discouraging it anyway. Do we really need to support it for new installs? -- Petr^2 Spacek From mbabinsk at redhat.com Fri May 6 13:46:16 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 May 2016 15:46:16 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C9632.8080908@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> <572C9632.8080908@redhat.com> Message-ID: On 05/06/2016 03:03 PM, Oleg Fayans wrote: > > > On 05/06/2016 12:08 PM, Martin Babinsky wrote: >> On 05/06/2016 11:14 AM, Oleg Fayans wrote: >>> >>> >>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>> >>>> >>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>> Tests are finally stable: >>>>> >>>>> ============================= test session starts >>>>> ============================== >>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>>> plugins: multihost, sourceorder >>>>> collected 8 items >>>>> >>>>> test_integration/test_dnssec.py ........ >>>>> >>>>> ========================= 8 passed in 5561.48 seconds >>>>> ========================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>> PATCH 38 LGTM >>>> >>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>> send this (almost the same) patch for first time, are you sure that we >>>> want to hide real issues in tests, to just have green color there? >>>> >>> >>> The underlying issue is 7 months old. Latest update in the issue from >>> Peter Spacek is: "I do not have time to investigate this issue now", >>> which means, that it will stay there for unpredictable amount of time >>> more. If we want to have a "green" jenkins that actually tests existing >>> features, we have to accept workarounds for such long-term issues >>> >>>> Martin >>> >> I have never been a big fan of "having a green jenkins whatever it >> takes" but I understand that there are all kinds of pressure on your >> team to deliver 100% stable test results. >> >> If the test fails, let it fail or, even better, use 'xfail' markers so >> that we know that this test fails and we should investigate. > Then all 8 existing cases would have to be marked as xfailed. > Sorry I lost context, does the whole test suite fail because of this? >> >> I fit fails for such a long time, we should really invest some time to >> look for the root cause of failure(s). If the appointed person does not >> have time for this, he/she should be able to negotiate some time >> allocated for the investigation. If you feel that the test failures are >> not getting enough attention from us then you perhaps need to be more >> proactive in the reporting. > > I am quite OK if Peter Spacek receives some more time for investigation > of the root cause of the problem. What I am not OK with is having a > perfectly functional testsuite for otherwise working feature, that is > being deferred for months just because we do not approve of issue > workarounds. > Well if the test suite is perfectly functional then I don't see why it is deferred. If all the failures are caused by buggy zone signing then that is problem for us developers to fix, not yours. I would also argue that since we tests for the feature are not passing in upstream QE environment then we can not consider the feature as "working". (I do not want to play down the enormous amount work Petr and Martin put into implementing DNSSec zone signing, I am just stating how I see things) >> >> We really should be fixing issues, not adding workarounds so that tests >> pass. >> > -- Martin^3 Babinsky From mbabinsk at redhat.com Fri May 6 13:50:31 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 May 2016 15:50:31 +0200 Subject: [Freeipa-devel] Should we stop supporting realm != upper(domain) installations? In-Reply-To: <91ce27cb-451e-9824-3acd-35f8202f289e@redhat.com> References: <91ce27cb-451e-9824-3acd-35f8202f289e@redhat.com> Message-ID: <626754b2-fce8-8ec9-5182-0a593771e307@redhat.com> On 05/06/2016 03:43 PM, Petr Spacek wrote: > Hello, > > I wonder if we should stop supporting new installations where > Kerberos realm != uppercase(primary DNS domain). > > It breaks a lot of stuff, is harder to manager and docs are full of warnings > discouraging it anyway. > > Do we really need to support it for new installs? > Since many people using such setup are bound to shoot themselves in the foot at some point I would argue for dropping support for this. I even fail to see the use case for having realm different that domain name. -- Martin^3 Babinsky From pspacek at redhat.com Fri May 6 13:50:58 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 May 2016 15:50:58 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <572C986B.5050601@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> <572C986B.5050601@redhat.com> Message-ID: <2324a219-46cf-c39b-8196-ec3f276bedf8@redhat.com> On 6.5.2016 15:13, Petr Viktorin wrote: > On 05/03/2016 03:01 PM, Petr Spacek wrote: >> On 29.4.2016 19:49, Petr Viktorin wrote: >>> On 04/12/2016 12:52 PM, Petr Spacek wrote: >>>> On 19.2.2016 13:50, Petr Viktorin wrote: >>>>> Is it time yet? >>>>> >>>>> This patch switches /usr/bin/ipa to Python 3 for >>>>> - the in-tree ./ipa command >>>>> - RPMs, when built with_python3 >>>> >>>> NACK, the change in 'ipa' command broke ipa dnszone-find: >>>> >>>> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >>>> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found >>>> >>>> The same command works when I switch python3->python2 in the 'ipa' command. >>> >>> That error is now fixed, could you please re-review? >> >> ACK, I did not find any breakage (when combined with other Py3 patches). > > Hello, > Those patches are now merged. Anything I can do to help push this forward? Nag the Master Pusher (mbasti) :-) -- Petr^2 Spacek From mbasti at redhat.com Fri May 6 13:52:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 15:52:44 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <2324a219-46cf-c39b-8196-ec3f276bedf8@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> <572C986B.5050601@redhat.com> <2324a219-46cf-c39b-8196-ec3f276bedf8@redhat.com> Message-ID: On 06.05.2016 15:50, Petr Spacek wrote: > On 6.5.2016 15:13, Petr Viktorin wrote: >> On 05/03/2016 03:01 PM, Petr Spacek wrote: >>> On 29.4.2016 19:49, Petr Viktorin wrote: >>>> On 04/12/2016 12:52 PM, Petr Spacek wrote: >>>>> On 19.2.2016 13:50, Petr Viktorin wrote: >>>>>> Is it time yet? >>>>>> >>>>>> This patch switches /usr/bin/ipa to Python 3 for >>>>>> - the in-tree ./ipa command >>>>>> - RPMs, when built with_python3 >>>>> NACK, the change in 'ipa' command broke ipa dnszone-find: >>>>> >>>>> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >>>>> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found >>>>> >>>>> The same command works when I switch python3->python2 in the 'ipa' command. >>>> That error is now fixed, could you please re-review? >>> ACK, I did not find any breakage (when combined with other Py3 patches). >> Hello, >> Those patches are now merged. Anything I can do to help push this forward? > Nag the Master Pusher (mbasti) :-) > I cannot apply patch, sorry :( Please rebase it (both 4.3 and master) From cheimes at redhat.com Fri May 6 13:55:02 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 6 May 2016 15:55:02 +0200 Subject: [Freeipa-devel] Should we stop supporting realm != upper(domain) installations? In-Reply-To: <626754b2-fce8-8ec9-5182-0a593771e307@redhat.com> References: <91ce27cb-451e-9824-3acd-35f8202f289e@redhat.com> <626754b2-fce8-8ec9-5182-0a593771e307@redhat.com> Message-ID: On 2016-05-06 15:50, Martin Babinsky wrote: > On 05/06/2016 03:43 PM, Petr Spacek wrote: >> Hello, >> >> I wonder if we should stop supporting new installations where >> Kerberos realm != uppercase(primary DNS domain). >> >> It breaks a lot of stuff, is harder to manager and docs are full of >> warnings >> discouraging it anyway. >> >> Do we really need to support it for new installs? >> > > Since many people using such setup are bound to shoot themselves in the > foot at some point I would argue for dropping support for this. > > I even fail to see the use case for having realm different that domain > name. +1 We could consider a --force option to skip the check and allow people to shoot themselves in the knee. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Fri May 6 14:00:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 16:00:07 +0200 Subject: [Freeipa-devel] Should we stop supporting realm != upper(domain) installations? In-Reply-To: References: <91ce27cb-451e-9824-3acd-35f8202f289e@redhat.com> <626754b2-fce8-8ec9-5182-0a593771e307@redhat.com> Message-ID: On 06.05.2016 15:55, Christian Heimes wrote: > On 2016-05-06 15:50, Martin Babinsky wrote: >> On 05/06/2016 03:43 PM, Petr Spacek wrote: >>> Hello, >>> >>> I wonder if we should stop supporting new installations where >>> Kerberos realm != uppercase(primary DNS domain). >>> >>> It breaks a lot of stuff, is harder to manager and docs are full of >>> warnings >>> discouraging it anyway. >>> >>> Do we really need to support it for new installs? >>> >> Since many people using such setup are bound to shoot themselves in the >> foot at some point I would argue for dropping support for this. >> >> I even fail to see the use case for having realm different that domain >> name. > +1 > > We could consider a --force option to skip the check and allow people to > shoot themselves in the knee. > > Christian > > > > And dont forgot about current installation that may have different domain and realm, otherwise sounds good -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri May 6 14:11:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 16:11:49 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572C94FB.8050408@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> <572C94FB.8050408@redhat.com> Message-ID: <4d3efef2-c57a-0f6c-14a6-0d7d36aa870c@redhat.com> On 06.05.2016 14:58, Oleg Fayans wrote: > > On 05/06/2016 11:42 AM, Martin Basti wrote: >> >> On 06.05.2016 11:14, Oleg Fayans wrote: >>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>> Tests are finally stable: >>>>> >>>>> ============================= test session starts >>>>> ============================== >>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>>> plugins: multihost, sourceorder >>>>> collected 8 items >>>>> >>>>> test_integration/test_dnssec.py ........ >>>>> >>>>> ========================= 8 passed in 5561.48 seconds >>>>> ========================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>> PATCH 38 LGTM >>>> >>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>> send this (almost the same) patch for first time, are you sure that we >>>> want to hide real issues in tests, to just have green color there? >>>> >>> The underlying issue is 7 months old. Latest update in the issue from >>> Peter Spacek is: "I do not have time to investigate this issue now", >>> which means, that it will stay there for unpredictable amount of time >>> more. If we want to have a "green" jenkins that actually tests existing >>> features, we have to accept workarounds for such long-term issues >>> >>>> Martin >> I leave decision if push this or not to different people, however I will >> do review on this. >> >> >> NACK >> >> 1) >> Why do you change sleep time? How is it related to workaround? >> >> - time.sleep(20) # sleep a bit until LDAP changes are applied to >> DNS >> + time.sleep(10) # sleep a bit until LDAP changes are applied to >> DNS > 10 seconds proved to be enough even in our super-slow brno rhevm lab Unrelated to workaround, send it as new patch > >> >> 2) >> why do you removes sleep from several places? How is this related to >> workaround? >> @@ -281,13 +302,19 @@ class TestInstallDNSSECFirst(IntegrationTest): >> "--a-rec=" + self.master.ip >> ] >> self.master.run_command(args) >> - time.sleep(10) # sleep a bit until data are provided by >> bind-dyndb-ldap >> >> args = [ >> "ipa", "dnsrecord-add", root_zone, self.master.domain.name, >> "--ns-rec=" + self.master.hostname >> ] >> self.master.run_command(args) > Because it's more reasonable to make changes on all hosts and then wait. Now, this is NACK. Yes, that is true wait when all changes are done, but you completely misunderstood why that sleep is there. Sleep is there because an A record was added, and it took time until this change is propagated to DNS, without A record following command (adding NS record) will fail. Bind-dyndb-ldap feels happy so it can work today, but it may not work tomorrow. > >> 3) >> You restart the same replica twice >> + time.sleep(10) # sleep a bit until LDAP changes are applied to >> DNS >> + # A workaround for ticket N 5348 >> + self.replicas[0].run_command(["systemctl", "restart", >> + "named-pkcs11.service"]) >> + self.replicas[0].run_command(["systemctl", "restart", >> + "named-pkcs11.service"]) >> + # End of workaround > My bad. > >> 4) >> Can you create a function doing workaround instead of copying the same >> code several times? >> >> something like >> def restart_named(*args): >> for host in args: >> # host$ systemctl restart named-pkcs11 >> >> where args are instances self.host, or self.master, or self.replica > Now, that's a marvelous idea! Implemented. And put the sleep interval in > it too just to keep it in one place I wanted *args to have restart_named(self.replicas[0], self.replicas[1]) instead creating an additional list restart_named([self.replicas[0], self.replicas[1]]) but whatever it works. > >> 5) >> Why did you removed this comment? >> - # wait until zone is signed > Because this is kin of obvious from the name of the function: > wait_until_record_is_signed Unrelated to this workaround, send it as separate patch "Removing mbasti's useless DNSSEC comments" > >> 6) >> I'm not sure, but is sleep there needed? Because restart of named will >> download all LDAP data again. > It turns out, without this interval the restart does not always help > >> If timeout is required maybe reason why >> time is there should be rephrased, to something like, make sure the >> dnssec keys were exported for named, or so. > Rephrased > >> + time.sleep(10) # sleep a bit until LDAP changes are applied to >> DNS >> + # A workaround for ticket N 5348 >> + self.master.run_command(["systemctl", "restart", >> + "named-pkcs11.service"]) >> + self.replicas[0].run_command(["systemctl", "restart", >> + "named-pkcs11.service"]) >> + # End of workaround >> >> Martin^2 From pviktori at redhat.com Fri May 6 14:16:41 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 6 May 2016 16:16:41 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> <572C986B.5050601@redhat.com> <2324a219-46cf-c39b-8196-ec3f276bedf8@redhat.com> Message-ID: <572CA749.2050700@redhat.com> On 05/06/2016 03:52 PM, Martin Basti wrote: > > > On 06.05.2016 15:50, Petr Spacek wrote: >> On 6.5.2016 15:13, Petr Viktorin wrote: >>> On 05/03/2016 03:01 PM, Petr Spacek wrote: >>>> On 29.4.2016 19:49, Petr Viktorin wrote: >>>>> On 04/12/2016 12:52 PM, Petr Spacek wrote: >>>>>> On 19.2.2016 13:50, Petr Viktorin wrote: >>>>>>> Is it time yet? >>>>>>> >>>>>>> This patch switches /usr/bin/ipa to Python 3 for >>>>>>> - the in-tree ./ipa command >>>>>>> - RPMs, when built with_python3 >>>>>> NACK, the change in 'ipa' command broke ipa dnszone-find: >>>>>> >>>>>> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >>>>>> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone >>>>>> not found >>>>>> >>>>>> The same command works when I switch python3->python2 in the 'ipa' >>>>>> command. >>>>> That error is now fixed, could you please re-review? >>>> ACK, I did not find any breakage (when combined with other Py3 >>>> patches). >>> Hello, >>> Those patches are now merged. Anything I can do to help push this >>> forward? >> Nag the Master Pusher (mbasti) :-) >> > I cannot apply patch, sorry :( Please rebase it (both 4.3 and master) The attached patch should apply on both branches. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0770.2-Switch-usr-bin-ipa-to-Python-3.patch Type: text/x-patch Size: 2141 bytes Desc: not available URL: From mbasti at redhat.com Fri May 6 14:18:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 16:18:15 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <572CA749.2050700@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> <57239EA7.6050902@redhat.com> <5d510b4e-58af-d7c5-4128-e69bd1bf45d0@redhat.com> <572C986B.5050601@redhat.com> <2324a219-46cf-c39b-8196-ec3f276bedf8@redhat.com> <572CA749.2050700@redhat.com> Message-ID: <12204a7d-8240-41a8-eee5-320b9b6e8e45@redhat.com> On 06.05.2016 16:16, Petr Viktorin wrote: > On 05/06/2016 03:52 PM, Martin Basti wrote: >> >> On 06.05.2016 15:50, Petr Spacek wrote: >>> On 6.5.2016 15:13, Petr Viktorin wrote: >>>> On 05/03/2016 03:01 PM, Petr Spacek wrote: >>>>> On 29.4.2016 19:49, Petr Viktorin wrote: >>>>>> On 04/12/2016 12:52 PM, Petr Spacek wrote: >>>>>>> On 19.2.2016 13:50, Petr Viktorin wrote: >>>>>>>> Is it time yet? >>>>>>>> >>>>>>>> This patch switches /usr/bin/ipa to Python 3 for >>>>>>>> - the in-tree ./ipa command >>>>>>>> - RPMs, when built with_python3 >>>>>>> NACK, the change in 'ipa' command broke ipa dnszone-find: >>>>>>> >>>>>>> # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. >>>>>>> ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone >>>>>>> not found >>>>>>> >>>>>>> The same command works when I switch python3->python2 in the 'ipa' >>>>>>> command. >>>>>> That error is now fixed, could you please re-review? >>>>> ACK, I did not find any breakage (when combined with other Py3 >>>>> patches). >>>> Hello, >>>> Those patches are now merged. Anything I can do to help push this >>>> forward? >>> Nag the Master Pusher (mbasti) :-) >>> >> I cannot apply patch, sorry :( Please rebase it (both 4.3 and master) > The attached patch should apply on both branches. > thanks Pushed to: master: 1ebd8334bc7da95f1edd64fc930e9cd6e3650534 ipa-4-3: e0ec5e133a70eddbb4dbc6f84e0ff7c1ad378a36 From mbabinsk at redhat.com Fri May 6 14:35:14 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 May 2016 16:35:14 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: References: <5707C9F2.8060903@redhat.com> Message-ID: On 05/05/2016 02:58 PM, Milan Kub?k wrote: > On 04/08/2016 05:10 PM, Martin Babinsky wrote: >> Hi list, >> >> I have put together a draft [1] outlining the effort to reimplement >> the handling of Kerberos principals in both backend and frontend >> layers of FreeIPA so that we may have multiple aliases per user, host >> or service and thus implement stuff like >> https://fedorahosted.org/freeipa/ticket/3961 and >> https://fedorahosted.org/freeipa/ticket/5413 . >> >> Since much of the plumbing was already implemented,[2] the document >> mainly describes what the patches do. Some parts required by other use >> cases may be missing so please point these out. >> >> I would also be happy if you could correct all factual inacurracies, I >> did research on this issue a long time ago and my knowledge turned a >> bit rusty. >> >> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >> [2] >> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >> > > Hi! > > I went through the design document and the related email thread here on > the list and I have few questions: > > 1. Is there any progress on what's to happen if MODRDN would colide with > an existing alias on a different entry? > Both krbPrincipalName and krbCanonicalName will be guarded by uniqueness plugin so this should raise an error in the DS backend. It will need some more investigation though and will probably warrant a separate test case in the future test plan. > 2. How does this RFE change the behavior of stage user plugin? Is the > principal (as in the canonical name) assigned at this stage of user > lifetime? > I didn't think about staged users when designing/doing patches. Thank you for pointing this out. The principal name is assigned when creating the staged user and it is also checked during activation and again added if it is not present. We will need to handle both of these cases. I will update the design to reflect this. > 3. Will there be any constraints on what string can be used as an alias? > (The document mentions email address as one use case) > The e-mail case can be tricky, since having two '@' in the principal name can break parsing/unparsing of principal name in KDB DAL. We will likely have to implement some sort of escaping to handle this correctly. This should be discussed in more detail with Simo/Alexander/Sumit. > 4. Will this RFE have any impact on AD trust (possibility of cross realm > routing, RFC 6806 section 9) > IIRC there should be no impact on trusts. > Otherwise the document looks good from my POV as QE. > > > Regards, > > -- > Milan Kubik > Thank you for the review. -- Martin^3 Babinsky From ofayans at redhat.com Fri May 6 14:38:29 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 May 2016 16:38:29 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <1df30d11-20eb-8ab8-6349-f07736926058@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> <572C9632.8080908@redhat.com> <1df30d11-20eb-8ab8-6349-f07736926058@redhat.com> Message-ID: <572CAC65.4030404@redhat.com> On 05/06/2016 03:25 PM, Petr Spacek wrote: > On 6.5.2016 15:03, Oleg Fayans wrote: >> >> >> On 05/06/2016 12:08 PM, Martin Babinsky wrote: >>> On 05/06/2016 11:14 AM, Oleg Fayans wrote: >>>> >>>> >>>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>>> Tests are finally stable: >>>>>> >>>>>> ============================= test session starts >>>>>> ============================== >>>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>>>> plugins: multihost, sourceorder >>>>>> collected 8 items >>>>>> >>>>>> test_integration/test_dnssec.py ........ >>>>>> >>>>>> ========================= 8 passed in 5561.48 seconds >>>>>> ========================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> PATCH 38 LGTM >>>>> >>>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>>> send this (almost the same) patch for first time, are you sure that we >>>>> want to hide real issues in tests, to just have green color there? >>>>> >>>> >>>> The underlying issue is 7 months old. Latest update in the issue from >>>> Peter Spacek is: "I do not have time to investigate this issue now", >>>> which means, that it will stay there for unpredictable amount of time >>>> more. If we want to have a "green" jenkins that actually tests existing >>>> features, we have to accept workarounds for such long-term issues >>>> >>>>> Martin >>>> >>> I have never been a big fan of "having a green jenkins whatever it >>> takes" but I understand that there are all kinds of pressure on your >>> team to deliver 100% stable test results. >>> >>> If the test fails, let it fail or, even better, use 'xfail' markers so >>> that we know that this test fails and we should investigate. >> Then all 8 existing cases would have to be marked as xfailed. > > That is perfectly fine - the test simply found a bug and we have to fix it. > There is no point in having "green" tests just to have them. > > Let me clarify my comment in the ticket that this is not a test blocker: > Red Hat Bugzilla is using this definition of TestBlocker: > A test blocker is a bug that prevents at least one test (test case) from > being executed. > > As far as I can tell this issue does not block anything. The tests execute and > correctly detect a bug. > > It would be a TestBlocker if it was e.g. a bug in installer which prevented > the install and thus prevented some other test cases from being executed. > > AFAIK this is not the case. Or am I wrong? > >>> I fit fails for such a long time, we should really invest some time to >>> look for the root cause of failure(s). If the appointed person does not >>> have time for this, he/she should be able to negotiate some time >>> allocated for the investigation. If you feel that the test failures are >>> not getting enough attention from us then you perhaps need to be more >>> proactive in the reporting. >> >> I am quite OK if Peter Spacek receives some more time for investigation >> of the root cause of the problem. What I am not OK with is having a >> perfectly functional testsuite for otherwise working feature, that is >> being deferred for months just because we do not approve of issue >> workarounds. > > Sorry, I do not understand this. What do you mean? What I mean is: Do we support adding dnssec-enabled zones? - Yes Does a dnssec-enabled zone display signature? - Yes, but after restarting of named-pkcs11. Should this feature in it's current state be covered with automated tests - YES, definitely! But I understand that most of the team have the opposite opinion on the subject We could probably add a separate test that checks exactly this bug: add a dnssec-enabled zone and query it WITHOUT restarting named-pkcs11. And mark it as xfail. This way we hit 2 goals simultaneously: test the feature itself and have a constant reminder for you guys, that we still have this problem that needs your attention. > > >>> We really should be fixing issues, not adding workarounds so that tests >>> pass. > > +1, it is just a matter of priority > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From thozza at redhat.com Fri May 6 14:41:56 2016 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 6 May 2016 16:41:56 +0200 Subject: [Freeipa-devel] [PATCH 0393-0398] Unload automatic empty zones only if conflicting forward zone has policy 'only'Add ability to log warningsUnload automatic empty zones which are super/sub/equal domain as forward zoneDo not touch global forwarders from named.conf if there is no config in LDAPAdd missing includes to util.hMove zone_isempty() and delete_bind_zone() to zone_register.c In-Reply-To: <5704F62A.8050606@redhat.com> References: <5704F62A.8050606@redhat.com> Message-ID: <0ccf65c5-403e-a61e-618b-ad9bd4e34049@redhat.com> On 04/06/2016 01:42 PM, Petr Spacek wrote: > Hello, > > attached patch set implements > https://fedorahosted.org/bind-dyndb-ldap/ticket/160 > described in > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones > > It will be accompanied with upgrade code in FreeIPA which will automatically > convert forward zones as necessary. > ACK. I reviewed the patches on GitHub (https://github.com/pspacek/bind-dyndb-ldap/commits/empty_zones_unload_only) I have these comments: - commit 396 (https://github.com/pspacek/bind-dyndb-ldap/commit/a1bb7c0f802107d1fc67de8a58d0f33095accd06) - it uses "forwarders" in wrong context. In many places and also in the commit message you should use "forward zone" instead of "forwarder". "forwarder is the server to which the queries are forwarded, not the zone. - It wold be nice to explicitly note in the commit message, that conflicting empty zones are unloaded regardless of the forward policy ("only" or "first"). - It would be good to document, that once you add forward zone, which causes removal of empty zone and then you remove the forward zone, the empty zone is not added back. The empty zone will appear again only after restart of BIND, when it loads all empty zones and only existing ones are removed. The situation is the same when you configure global forwarders and them remove them = all empty zones are unloaded and these are not added back until the restart of BIND. This is a limitation and IMHO the users should be informed about this behavior, as it may not be completely expected. - Configuring global forwarders as forward first creates too many log messages (for each empty zone). This may not be a problem, but it is IMHO not necessary. Also when I configure global forwarders as forward "only" and then change it to forward "first", the log message is printed even though the empty zones are not there any more, which is a bit misleading. - Warning log message about the configuration of global forward zone are logged every time on start-up regardless of the forward policy set in LDAP. Other than that the changes look good to me. The functionality works as documented with the shortcomings mentioned above. PS: There seems to be some kind of race condition when you configure forward zone and you have global forwarding turned off. In case you configure a forward zone with forward "only" and it conflicts with an empty zone, you can get SERVFAIL from the server for hostname from such zone. It is reproducible only if you are quick enough. The next query is forwarded correctly and the response from forwarder is returned. Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com From mbasti at redhat.com Fri May 6 14:50:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 16:50:58 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <572CAC65.4030404@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <65db3ffa-fc6e-1d25-9d43-dae1fbe5aa8e@redhat.com> <572C9632.8080908@redhat.com> <1df30d11-20eb-8ab8-6349-f07736926058@redhat.com> <572CAC65.4030404@redhat.com> Message-ID: <6687626b-6bab-1336-67da-3eacbfd9c3cc@redhat.com> On 06.05.2016 16:38, Oleg Fayans wrote: > > On 05/06/2016 03:25 PM, Petr Spacek wrote: >> On 6.5.2016 15:03, Oleg Fayans wrote: >>> >>> On 05/06/2016 12:08 PM, Martin Babinsky wrote: >>>> On 05/06/2016 11:14 AM, Oleg Fayans wrote: >>>>> >>>>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>>>> >>>>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>>>> Tests are finally stable: >>>>>>> >>>>>>> ============================= test session starts >>>>>>> ============================== >>>>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >>>>>>> plugins: multihost, sourceorder >>>>>>> collected 8 items >>>>>>> >>>>>>> test_integration/test_dnssec.py ........ >>>>>>> >>>>>>> ========================= 8 passed in 5561.48 seconds >>>>>>> ========================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> PATCH 38 LGTM >>>>>> >>>>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>>>> send this (almost the same) patch for first time, are you sure that we >>>>>> want to hide real issues in tests, to just have green color there? >>>>>> >>>>> The underlying issue is 7 months old. Latest update in the issue from >>>>> Peter Spacek is: "I do not have time to investigate this issue now", >>>>> which means, that it will stay there for unpredictable amount of time >>>>> more. If we want to have a "green" jenkins that actually tests existing >>>>> features, we have to accept workarounds for such long-term issues >>>>> >>>>>> Martin >>>> I have never been a big fan of "having a green jenkins whatever it >>>> takes" but I understand that there are all kinds of pressure on your >>>> team to deliver 100% stable test results. >>>> >>>> If the test fails, let it fail or, even better, use 'xfail' markers so >>>> that we know that this test fails and we should investigate. >>> Then all 8 existing cases would have to be marked as xfailed. >> That is perfectly fine - the test simply found a bug and we have to fix it. >> There is no point in having "green" tests just to have them. >> >> Let me clarify my comment in the ticket that this is not a test blocker: >> Red Hat Bugzilla is using this definition of TestBlocker: >> A test blocker is a bug that prevents at least one test (test case) from >> being executed. >> >> As far as I can tell this issue does not block anything. The tests execute and >> correctly detect a bug. >> >> It would be a TestBlocker if it was e.g. a bug in installer which prevented >> the install and thus prevented some other test cases from being executed. >> >> AFAIK this is not the case. Or am I wrong? >> >>>> I fit fails for such a long time, we should really invest some time to >>>> look for the root cause of failure(s). If the appointed person does not >>>> have time for this, he/she should be able to negotiate some time >>>> allocated for the investigation. If you feel that the test failures are >>>> not getting enough attention from us then you perhaps need to be more >>>> proactive in the reporting. >>> I am quite OK if Peter Spacek receives some more time for investigation >>> of the root cause of the problem. What I am not OK with is having a >>> perfectly functional testsuite for otherwise working feature, that is >>> being deferred for months just because we do not approve of issue >>> workarounds. >> Sorry, I do not understand this. What do you mean? > What I mean is: > Do we support adding dnssec-enabled zones? > - Yes > Does a dnssec-enabled zone display signature? > - Yes, but after restarting of named-pkcs11. > Should this feature in it's current state be covered with automated tests > - YES, definitely! > But I understand that most of the team have the opposite opinion on the > subject > > We could probably add a separate test that checks exactly this bug: add > a dnssec-enabled zone and query it WITHOUT restarting named-pkcs11. And > mark it as xfail. This way we hit 2 goals simultaneously: test the > feature itself and have a constant reminder for you guys, that we still > have this problem that needs your attention. > Yes why not, we can duplicate code for the every issue. We will have nice statics on github :) >> >>>> We really should be fixing issues, not adding workarounds so that tests >>>> pass. >> +1, it is just a matter of priority >> From mbasti at redhat.com Fri May 6 15:22:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 17:22:06 +0200 Subject: [Freeipa-devel] [PATCH 0469] make: fail when API.txt or ACI.txt differ from code In-Reply-To: <20160429153259.GF12088@10.4.128.1> References: <57237081.4090800@redhat.com> <20160429153259.GF12088@10.4.128.1> Message-ID: <88823633-304d-beb7-6d53-bd09e42698d9@redhat.com> On 29.04.2016 17:32, Lukas Slebodnik wrote: > On (29/04/16 16:32), Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5865 >> >> Patch attached. > >From 511f9bb1645a707ee83571123df9548731cc9387 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 29 Apr 2016 16:28:28 +0200 >> Subject: [PATCH] make: fail when ACI.txt or API.txt differs from values in >> source code >> >> This regression was caused by commit 6acaf73b0c6f7301d5a5d4292a4f9926cc370867 before this commit make rpms failed when API.txt did not match api >> >> https://fedorahosted.org/freeipa/ticket/5865 >> --- >> Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index 82e6936a7162ff6e0359521d5c1299ff8ee55220..9cc4d40d191cc0ab27a5c150535e49be89b23b72 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -188,7 +188,7 @@ version-update: release-update >> fi >> >> if [ "$(SKIP_API_VERSION_CHECK)" != "yes" ]; then \ >> - ./makeapi --validate; \ >> + ./makeapi --validate && \ >> ./makeaci --validate; \ >> fi > ACK > > LS master: * 8787e032281e0715a4f405a2ce4f2529cd73e9d7 make: fail when ACI.txt or API.txt differs from values in source code ipa-4-3: * dce18a825b21daf55a800651a0fa9d8727603a9c make: fail when ACI.txt or API.txt differs from values in source code From mbasti at redhat.com Fri May 6 20:20:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 6 May 2016 22:20:56 +0200 Subject: [Freeipa-devel] [PATCH 0103] DNS installer: accept --auto-forwarders option in unattended mode In-Reply-To: References: Message-ID: <01eef55d-e6ee-a339-c990-e8590cb7eea1@redhat.com> On 03.05.2016 14:56, Petr Spacek wrote: > Hello, > > DNS installer: accept --auto-forwarders option in unattended mode > > https://fedorahosted.org/freeipa/ticket/5869 > > > ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Sat May 7 06:44:51 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Sat, 7 May 2016 12:14:51 +0530 Subject: [Freeipa-devel] [PATCH 0014] Removed custom implementation of CalledProcessError Message-ID: <572D8EE3.2050800@redhat.com> Hi All, Please review this patch. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0014-Removed-custom-implementation-of-CalledProcessError.patch Type: text/x-patch Size: 2174 bytes Desc: not available URL: From jerel.gilmer at gmail.com Sun May 8 16:14:57 2016 From: jerel.gilmer at gmail.com (Jerel Gilmer) Date: Sun, 8 May 2016 12:14:57 -0400 Subject: [Freeipa-devel] Generate report of user access levels on each system Message-ID: Hello all - I've been using IdM and was tasked by my management with generating two system reports: - List of what users have access to what services on each system - List of sudo rules for each system I did a lot of research but couldn't find a simple way to do this so I created scripts using ldapsearch calls that created the reports I needed. I'm sending these out to the community for comment and for anyone that has similar requirements. I've pasted the scripts below. If there are any issues with formatting, you can download the scripts from my Github (github com/jerelgilmer/freeipa-scripts) Jerel Gilmer ----------> server-access-report.py #!/usr/bin/python ''' 2016 - March - 2 Author: Jerel Gilmer ''' import os import sys import ldap def print_usage(): print "Usage: server-access-report.py " print "This script generates the list of allowed users for each service defined in applicable HBAC rules.\n" print " - System hostname; This can be the short name\n" print "For report of all systems, use \'.\'\n" print "Make sure to set the below variables in the script:" print "\tDOMAIN: Domain component" print "\tLDAP_SERVER: LDAP server to be queried" print "\tLDAP_USER: LDAP user to query server; preferable a read-only account" print "\tLDAP_PW: LDAP user's password\n" sys.exit(1) try: server = str(sys.argv[1]) except: print_usage() ## LDAP Connection Info and bind to the LDAP server ## Uncomment and set these variables to the appropriate values ## Below are examples #DOMAIN = "dc=sub,dc=example,dc=com" #LDAP_SERVER = "ldap://ipaserver1.sub.example.com" #LDAP_USER = "uid=user1,cn=users,cn=compat," + DOMAIN #LDAP_PW = "Password123" try: DOMAIN LDAP_SERVER LDAP_USER LDAP_PW except: print_usage() l = ldap.initialize(LDAP_SERVER) l.simple_bind_s(LDAP_USER,LDAP_PW) ## LDAP Search Variables ## Base DN for LDAP Searches baseComputerDN = "cn=computers,cn=accounts," + DOMAIN baseGroupDN = "cn=groups,cn=accounts," + DOMAIN baseUserDN = "cn=users,cn=accounts," + DOMAIN baseHBACDN = "cn=hbac," + DOMAIN baseHBACServicesDN = "cn=hbacservices,cn=hbac," + DOMAIN baseHBACServiceGroupsDN = "cn=hbacservicegroups,cn=hbac," + DOMAIN ## Default LDAP SCOPE scope = ldap.SCOPE_SUBTREE ## Filter for LDAP Searches compFilter = "(&(objectclass=ipahost)(fqdn=*" + server + "*))" hbacFilter = "(objectclass=ipahbacrule)" userFilter = "(objectclass=person)" groupFilter = "(objectclass=ipausergroup)" hbacServiceFilter = "(objectclass=ipahbacservice)" hbacServiceGroupsFilter = "(objectclass=ipahbacservicegroup)" ## Attributes from LDAP Searches compAttributes = ['memberOf', 'fqdn'] hbacAttributes = ['memberUser', 'memberService', 'serviceCategory'] userAttributes = ['uid'] groupAttributes = ['member'] hbacServiceAttributes = ['cn' , 'ipaUniqueID'] hbacServiceGroupsAttributes = ['cn' , 'member'] ## Perform LDAP searches and store results into array ALL_HOSTS = l.search_s(baseComputerDN, scope, compFilter, compAttributes) ALL_USERS = l.search_s(baseUserDN, scope, userFilter, userAttributes) ALL_GROUPS = l.search_s(baseGroupDN, scope, groupFilter, groupAttributes) ALL_HBACRULES = l.search_s(baseHBACDN, scope, hbacFilter, hbacAttributes) ALL_HBACSERVICES = l.search_s(baseHBACServicesDN, scope, hbacServiceFilter, hbacServiceAttributes) ALL_HBACSERVICEGROUPS = l.search_s(baseHBACServiceGroupsDN, scope, hbacServiceGroupsFilter, hbacServiceGroupsAttributes) # HBAC rules that apply to all servers hbacAllServersFilter = "(&(objectclass=ipahbacrule)(hostCategory=all))" HBACRULE_ALL_SERVERS = l.search_s(baseHBACDN, scope, hbacAllServersFilter, hbacAttributes) ALL_HOSTS.sort() def findUID(user): uid = filter(lambda x: user in x, ALL_USERS) return uid[0][1]['uid'][0] def findGroupMembers(groupname): if "cn=groups,cn" not in groupname: pass group = filter(lambda x: groupname in x, ALL_GROUPS) try: groupmembers = group[0][1]['member'] except: groupmembers = "" for user in groupmembers: if "cn=groups,cn" in user: for i in findGroupMembers(user): yield i else: yield (findUID(user)) def findServiceName(service_name): s = filter(lambda x: service_name in x, ALL_HBACSERVICES) return s[0][1]['cn'][0] def findServiceGroupMembers(service_group): allServices = [] serviceGroup = filter(lambda x: service_group in x, ALL_HBACSERVICEGROUPS) serviceGroupMembers = serviceGroup[0][1]['member'] for i in serviceGroupMembers: allServices.append(findServiceName(i)) formattedAllServices = ', '.join(allServices) return formattedAllServices def accessToAllSystems(): allSystemsHBACRules = {} for hbacname in HBACRULE_ALL_SERVERS: hbacrule = filter(lambda x: hbacname[0] in x, ALL_HBACRULES) for hbacuser in hbacrule: services = [] allowedUsers = [] users = [] groups = [] try: users = filter(lambda x: "cn=users,cn" in x, hbacuser[1]['memberUser']) except: users = [] try: groups = filter(lambda x: "cn=groups,cn" in x, hbacuser[1]['memberUser']) except: groups = [] try: hbacservice = hbacuser[1]['memberService'] for i in hbacservice: if "hbacservicegroups,cn" in i: services.append(findServiceGroupMembers(i)) else: services.append(findServiceName(i)) except: try: services = hbacuser[1]['serviceCategory'][0] except: services = ['None'] for i in users: allowedUsers.append(findUID(i)) for i in groups: allowedUsers += (findGroupMembers(i)) allSystemsHBACRules[hbacrule[0][0]] = {'services': services, 'allowedUsers': allowedUsers} return allSystemsHBACRules def mergeD(results,services): for k in results: if services == results[k]['services']: return "MATCH!!", k def nestedL(l): if isinstance(l, str): yield l for k in l: if isinstance(k, list): for i in k: yield i if isinstance(k, str): yield k def main(): for entry in ALL_HOSTS: systemWide = {} HBACAllowedList = {} results = {} x = 1 fqdn = entry[1]['fqdn'][0] print "HOSTNAME = ", fqdn try: membership = filter(lambda x: "hbac,dc" in x, entry[1]['memberOf']) except: membership = [] for hbacname in membership: hbacrule = filter(lambda x: hbacname in x, ALL_HBACRULES) for hbacuser in hbacrule: allowedUsers = [] allowedUsersLst = [] users = [] groups = [] services = [] try: hbacservice = hbacuser[1]['memberService'] for i in hbacservice: if "hbacservicegroups,cn" in i: services.append(findServiceGroupMembers(i)) else: services.append(findServiceName(i)) except: try: services = hbacuser[1]['serviceCategory'][0] except: services = [] try: users = filter(lambda x: "cn=users,cn" in x, hbacuser[1]['memberUser']) except: users = [] try: groups = filter(lambda x: "cn=groups,cn" in x, hbacuser[1]['memberUser']) except: groups = [] for i in users: allowedUsers.append(findUID(i)) for i in groups: allowedUsers += findGroupMembers(i) HBACAllowedList[hbacrule[0][0]] = {'services': services, 'allowedUsers': allowedUsers} systemWide = accessToAllSystems() HBACAllowedList.update(accessToAllSystems()) for key, value in HBACAllowedList.iteritems(): if isinstance(value['services'], list): services = ', '.join(value['services']) else: services = value['services'] allowedUsers = value['allowedUsers'] try: mark, key = mergeD(results,services) except: mark, key = (None, None) if mark == "MATCH!!": results[key]['allowedUsers'].append(allowedUsers) else: results[x] = {'services': services, 'allowedUsers': allowedUsers} x = x + 1 for i in results: results_services = results[i]['services'] results_allowedUsers = list(nestedL(results[i]['allowedUsers'])) results_allowedUsersSet = set(results_allowedUsers) results_allowedUsersLst = list(results_allowedUsersSet) results_allowedUsersLst.sort() formatted_allowedUsers = ' '.join(results_allowedUsersLst) if not results_services: results_services = 'empty' if not formatted_allowedUsers: formatted_allowedUsers = 'empty' print "SERVICES = ", results_services print "ALLOWED USERS = ", formatted_allowedUsers, "\n" main() -------------------------------------------------- -------------------> sudo-report.py #!/usr/bin/python ''' 2016 - March - 2 Author: Jerel Gilmer ''' import os import sys import ldap def print_usage(): print "Usage: server-access-report.py " print "This script generates the list of sudo rules for each server.\n" print " - System hostname; This can be the short name\n" print "For report of all systems, use \'.\'\n" print "Make sure to set the below variables in the script:" print "\tDOMAIN: Domain component" print "\tLDAP_SERVER: LDAP server to be queried" print "\tLDAP_USER: LDAP user to query server; preferable a read-only account" print "\tLDAP_PW: LDAP user's password\n" sys.exit(1) try: server = str(sys.argv[1]) except: print_usage() ## LDAP Connection Info and bind to the LDAP server ## Uncomment and set these variables to the appropriate values ## Below are examples #DOMAIN = "dc=sub,dc=example,dc=com" #LDAP_SERVER = "ldap://ipaserver1" #LDAP_USER = "uid=user1,cn=users,cn=compat," + DOMAIN #LDAP_PW = "Password123" try: DOMAIN LDAP_SERVER LDAP_USER LDAP_PW except: print_usage() l = ldap.initialize(LDAP_SERVER) l.simple_bind_s(LDAP_USER,LDAP_PW) ## LDAP Search Variables ## Base DN for LDAP Searches baseComputerDN = "cn=computers,cn=accounts," + DOMAIN baseGroupDN = "cn=groups,cn=accounts," + DOMAIN baseUserDN = "cn=users,cn=accounts," + DOMAIN baseSudoDN = "cn=sudorules,cn=sudo," + DOMAIN baseSudoCmdDN = "cn=sudocmds,cn=sudo," + DOMAIN baseSudoCmdGroupDN = "cn=sudocmdgroups,cn=sudo," + DOMAIN ## Default LDAP SCOPE scope = ldap.SCOPE_SUBTREE ## Filter for LDAP Searches compFilter = "(&(objectclass=ipahost)(fqdn=*" + server + "*))" userFilter = "(objectclass=person)" groupFilter = "(objectclass=ipausergroup)" sudoFilter = "objectclass=ipasudorule" sudoCmdFilter = "objectclass=ipasudocmd" sudoCmdGroupFilter = "objectclass=ipasudocmdgrp" ## Attributes from LDAP Searches compAttributes = ['memberOf', 'fqdn'] userAttributes = ['uid'] groupAttributes = ['member'] sudoAttributes = ['memberUser', 'ipaSudoOpt', 'memberAllowCmd', 'hostCategory', 'cmdCategory'] sudoCmdAttributes = ['sudoCmd'] sudoCmdGroupAttributes = ['member'] ## Perform LDAP searches and store results into array ALL_HOSTS = l.search_s(baseComputerDN, scope, compFilter, compAttributes) ALL_USERS = l.search_s(baseUserDN, scope, userFilter, userAttributes) ALL_GROUPS = l.search_s(baseGroupDN, scope, groupFilter, groupAttributes) ALL_SUDORULES = l.search_s(baseSudoDN, scope, sudoFilter, sudoAttributes) ALL_SUDOCMDS = l.search_s(baseSudoCmdDN, scope, sudoCmdFilter, sudoCmdAttributes) ALL_SUDOCMDGROUPS = l.search_s(baseSudoCmdGroupDN, scope, sudoCmdGroupFilter, sudoCmdGroupAttributes) # Sudo rules that apply to all servers sudoAllServersFilter = "(&(objectclass=ipasudorule)(hostCategory=all))" SUDORULE_ALL_SERVERS = l.search_s(baseSudoDN, scope, sudoAllServersFilter, sudoAttributes) ALL_HOSTS.sort() def findUID(user): uid = filter(lambda x: user in x, ALL_USERS) return uid[0][1]['uid'][0] def findGroupMembers(groupname): if "cn=groups,cn" not in groupname: pass group = filter(lambda x: groupname in x, ALL_GROUPS) try: groupmembers = group[0][1]['member'] except: groupmembers = "" for user in groupmembers: if "cn=groups,cn" in user: for i in findGroupMembers(user): yield i else: yield (findUID(user)) def findSudoCmds(sudo_cmd): s = filter(lambda x: sudo_cmd in x, ALL_SUDOCMDS) return s[0][1]['sudoCmd'][0] def findSudoCmdGroupMembers(sudo_cmd_group): allSudoCmds = [] sudoGroup = filter(lambda x: sudo_cmd_group in x, ALL_SUDOCMDGROUPS) sudoGroupMembers = sudoGroup[0][1]['member'] for i in sudoGroupMembers: allSudoCmds.append(findSudoCmds(i)) formattedAllSudoCmds = ', '.join(allSudoCmds) return formattedAllSudoCmds def sudoOnAllSystems(): allSystemsSudoRules = {} for sudoname in SUDORULE_ALL_SERVERS: sudorule = filter(lambda x: sudoname[0] in x, ALL_SUDORULES) for sudouser in sudorule: sudocmds = [] allowedUsers = [] allowedSudoCmd = [] users = [] groups = [] try: sudoOptions = ['ipaSudoOpt'] except: sudoOptions = [] try: sudocmds = sudouser[1]['memberAllowCmd'] for i in sudocmds: if "cn=sudocmdgroups,cn" in i: allowedSudoCmd.append(findSudoCmdGroupMembers(i)) else: allowedSudoCmd.append(findSudoCmds(i)) except: try: if sudouser[1]['cmdCategory']: allowedSudoCmd = sudouser[1]['cmdCategory'][0] except: allowedSudoCmd = ['None'] try: sudocmdgroup = filter(lambda x: "cn=sudocmdgroups" in x, sudouser[1]['memberAllowCmd']) except: sudocmdgroup = '' try: users = filter(lambda x: "cn=users,cn" in x, sudouser[1]['memberUser']) except: users = [] try: groups = filter(lambda x: "cn=groups,cn" in x, sudouser[1]['memberUser']) except: groups = [] for i in users: allowedUsers.append(findUID(i)) for i in groups: allowedUsers += (findGroupMembers(i)) allSystemsSudoRules[sudorule[0][0]] = {'sudoCommands': allowedSudoCmd, 'allowedUsers': allowedUsers} return allSystemsSudoRules def mergeD(results,allowedSudoCmd): for k in results: if allowedSudoCmd == results[k]['sudoCommands']: return "MATCH!!", k def nestedL(l): if isinstance(l, str): yield l for k in l: if isinstance(k, list): for i in k: yield i if isinstance(k, str): yield k def main(): for entry in ALL_HOSTS: SudoAllowedList = {} results = {} x = 1 fqdn = entry[1]['fqdn'][0] print "HOSTNAME = ", fqdn try: membership = filter(lambda x: "sudo,dc" in x, entry[1]['memberOf']) except: membership = [] for sudoname in membership: sudorule = filter(lambda x: sudoname in x, ALL_SUDORULES) for sudouser in sudorule: allowedUsers = [] allowedUsersLst = [] allowedSudoLst = [] allowedSudoCmd = [] users = [] groups = [] try: sudoOptions = ['ipaSudoOpt'] except: sudoOptions = [] try: sudocmds = sudouser[1]['memberAllowCmd'] for i in sudocmds: if "cn=sudocmdgroups,cn" in i: allowedSudoCmd.append(findSudoCmdGroupMembers(i)) else: allowedSudoCmd.append(findSudoCmds(i)) except: try: if sudouser[1]['cmdCategory']: allowedSudoCmd = sudouser[1]['cmdCategory'][0] except: allowedSudoCmd = ['None'] try: users = filter(lambda x: "cn=users,cn" in x, sudouser[1]['memberUser']) except: users = [] try: groups = filter(lambda x: "cn=groups,cn" in x, sudouser[1]['memberUser']) except: groups = [] for i in users: allowedUsers.append(findUID(i)) for i in groups: allowedUsers += findGroupMembers(i) SudoAllowedList[sudorule[0][0]] = {'sudoCommands': allowedSudoCmd, 'allowedUsers': allowedUsers} systemWide = sudoOnAllSystems() SudoAllowedList.update(systemWide) for key, value in SudoAllowedList.iteritems(): if isinstance(value['sudoCommands'], list): allowedSudoCmd = ', '.join(value['sudoCommands']) else: allowedSudoCmd = value['sudoCommands'] allowedUsers = value['allowedUsers'] try: mark, key = mergeD(results,allowedSudoCmd) except: mark, key = (None, None) if mark == "MATCH!!": results[key]['allowedUsers'].append(allowedUsers) else: results[x] = {'sudoCommands': allowedSudoCmd, 'allowedUsers': allowedUsers} x = x + 1 for i in results: results_allowedSudoCmd = results[i]['sudoCommands'] results_allowedUsers = list(nestedL(results[i]['allowedUsers'])) results_allowedUsersSet = set(results_allowedUsers) results_allowedUsersLst = list(results_allowedUsersSet) results_allowedUsersLst.sort() formatted_allowedUsers = ' '.join(results_allowedUsersLst) if not results_allowedSudoCmd: results_services = 'empty' if not formatted_allowedUsers: formatted_allowedUsers = 'empty' print "SUDO COMMANDS = ", results_allowedSudoCmd print "ALLOWED USERS = ", formatted_allowedUsers, "\n" main() ------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Mon May 9 05:26:51 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 9 May 2016 10:56:51 +0530 Subject: [Freeipa-devel] [PATCH 0015] Added exception handling for mal-formatted XML Parsing Message-ID: <57301F9B.6070005@redhat.com> Hi all, Please review the patch. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1333755 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0015-Added-exception-handling-for-mal-formatted-XML-Parsin.patch Type: text/x-patch Size: 1721 bytes Desc: not available URL: From abokovoy at redhat.com Mon May 9 06:26:15 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 May 2016 09:26:15 +0300 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: References: <5707C9F2.8060903@redhat.com> Message-ID: <20160509062557.kal42vxwur7obauc@redhat.com> On Fri, 06 May 2016, Martin Babinsky wrote: >On 05/05/2016 02:58 PM, Milan Kub?k wrote: >>On 04/08/2016 05:10 PM, Martin Babinsky wrote: >>>Hi list, >>> >>>I have put together a draft [1] outlining the effort to reimplement >>>the handling of Kerberos principals in both backend and frontend >>>layers of FreeIPA so that we may have multiple aliases per user, host >>>or service and thus implement stuff like >>>https://fedorahosted.org/freeipa/ticket/3961 and >>>https://fedorahosted.org/freeipa/ticket/5413 . >>> >>>Since much of the plumbing was already implemented,[2] the document >>>mainly describes what the patches do. Some parts required by other use >>>cases may be missing so please point these out. >>> >>>I would also be happy if you could correct all factual inacurracies, I >>>did research on this issue a long time ago and my knowledge turned a >>>bit rusty. >>> >>>[1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>>[2] >>>https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>> >> >>Hi! >> >>I went through the design document and the related email thread here on >>the list and I have few questions: >> >>1. Is there any progress on what's to happen if MODRDN would colide with >>an existing alias on a different entry? >> >Both krbPrincipalName and krbCanonicalName will be guarded by >uniqueness plugin so this should raise an error in the DS backend. > >It will need some more investigation though and will probably warrant >a separate test case in the future test plan. > >>2. How does this RFE change the behavior of stage user plugin? Is the >>principal (as in the canonical name) assigned at this stage of user >>lifetime? >> >I didn't think about staged users when designing/doing patches. Thank >you for pointing this out. The principal name is assigned when >creating the staged user and it is also checked during activation and >again added if it is not present. We will need to handle both of these >cases. I will update the design to reflect this. > >>3. Will there be any constraints on what string can be used as an alias? >>(The document mentions email address as one use case) >> >The e-mail case can be tricky, since having two '@' in the principal >name can break parsing/unparsing of principal name in KDB DAL. We will >likely have to implement some sort of escaping to handle this >correctly. This should be discussed in more detail with >Simo/Alexander/Sumit. We should not allow anything after @ not belonging to the list of realm domains. We also will need to extend realm domains to include non-domain-based UPN suffixes. This actually flies close to what I need to finish in my AD trust UPN patches, so I need to make sure we have the same approach there. > >>4. Will this RFE have any impact on AD trust (possibility of cross realm >>routing, RFC 6806 section 9) >> > >IIRC there should be no impact on trusts. We should never allow to specify alias from the realm we don't own. This means the code needs to look into the namespaces associated with any of the trusted domains and reject them. -- / Alexander Bokovoy From jcholast at redhat.com Mon May 9 06:54:32 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 May 2016 08:54:32 +0200 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <57161E1F.6020001@redhat.com> References: <57161E1F.6020001@redhat.com> Message-ID: <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> Hi, 1) """ The "upstream" root certificate and intermediate CA certificates would be stored in LDAP for distribution to clients, with the root CA having an ipaKeyTrust value of trusted and intermediate CAs having a value of unknown (see CA certificate renewal). """ Note that currently it's the IPA CA that is trusted by default, not any of the external (root or intermediate) CAs. I think it should stay this way, as we don't need to trust any of the external CAs for IPA to work correctly. 2) It should be mentioned here that the primary CA is also handled by this plugin. I would like to propose two additional fields: * subject (required) - subject name of the CA, to be able to look up sub-CA that issued a certificate from its issuer name. * issuer_ca (optional) - name of the sub-CA which issued certificate for this CA, to have information about the sub-CA hierarchy. If there is no sub-CA entry for the issuer, it would be unset. 3) """ Subject Distinguished Name When creating a sub-CA, the subject DN is constructed by copying the DN of the parent CA, then setting the CN to the name. More control could be implemented if there is a clear case for it. """ Note that adding the ability to override the CN in the subject name of the IPA CA certificate was requested a long time ago: . """ Validity The default validity could be the default validity used by ipa-server-install. TODO what is the default duration? """ ATM the default duration is 10 years. """ Specify the CA certificate validity. Something human-friendly should be used, e.g. a duration spec that supports 5y, 365d, etc. TODO is there a precendent for this sort of duration interpretation in FreeIPA? If so, be consistent. """ Currently there is (IIRC) only krbmaxticketlife (seconds) and krbmaxrenewableage (seconds) in the krbtpolicy plugin and krbmaxpwdlife (days) and krbminpwdlife (hours) in the pwpolicy plugin. If you are going to invent something generic, it would be nice if it worked for them as well. 4) """ For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which implements the KeyRetriever interface. It invokes a Python script that performs the retrieval, reusing existing FreeIPA Custodia client code. """ Will this be distributed with Dogtag or with IPA? The Python script bit sounds like an implementation detail rather than an actual design. Ideally the whole thing would be done in Java, right? """ The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key and shall be executed as pkiuser. """ Could you please use a subdirectory? Like /usr/libexec/pki (if the script is going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is going to be distributed with IPA). """ pkiuser does not have read access to either of these locations, so a new service principal shall be created for each Dogtag CA instance for the purpose of authenticating to Custodia and retrieving lightweight CA private keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively. """ Don't forget to update this paragraph with the new principal name. 5) """ A CA object for the top-level CA will initially be created, with DN cn=.,ou=cas,cn=ca,$SUFFIX. """ I would rather not use punctuation for the short name, as it can be easily overlooked (think logs). (Also it should be '/' if anything, not '.', which usually means "current".) Above you stated that the subject name will be derived from the short name of the sub-CA. The top-level CA has subject name of the form "CN=Certificate Authority,$SUBJECT_BASE", so its short name should be "Certificate Authority". 6) """ ipa ca-del Delete the given certificate authority. This will remove knowledge of the CA from the FreeIPA directory but will not delete the sub-CA from Dogtag. Dogtag will still know about the CA and the certificates it issued, be able to act at a CRL / OCSP authority for it, etc. """ What is the use case for this? Will the certificates issued by the sub-CA still be valid after delete or not? Will the sub-CA certificate be explicitly distrusted on delete or not? IMO it should be possible to delete only a leaf sub-CA, i.e. anything but the top-level CA in the current design. """ ipa cert-find [shortname] shortname Optional positional parameter to specify a sub-CA to use (omit to specify the top-level CA). The special shortname * is used to search in all CAs. """ This should be "ipa cert-find [--ca=]". At some point, cert-find should be fixed to be consistent with every other -find command and have an optional 'criteria' positional argument, and there can't be two optional positional arguments, as it creates an ambiguity. I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather than a magic value for an all-CA search. Magic value might work for cert-find alone, but you are creating a precedent for the whole framework here. """ ipa cert-show [shortname] shortname Optional positional parameter to specify a sub-CA (omit to specify the top-level CA). --chain Request the certificate chain (when saving via --out , PEM format is used; this is the format uesd for the end-entity certificate). """ This should be "ipa cert-show [--ca=]", for consistency with cert-find, see above. IMO it would make sense to add --chain to cert-request as well, it should be useful for certmonger. 7) How is a certificate going to be requested from a specific sub-CA using the getcert command? Honza -- Jan Cholasta From ldoudova at redhat.com Mon May 9 07:02:18 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 9 May 2016 09:02:18 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Thin client Message-ID: <573035FA.1000503@redhat.com> Hi, looks fine, but it would be nice to update the document so that it would reflect changes mentioned on previous email thread. Lenka From ldoudova at redhat.com Mon May 9 07:07:41 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 9 May 2016 09:07:41 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Support of UPN for trusted domains Message-ID: <5730373D.6080804@redhat.com> Hi, design look good, no remarks. Lenka From ofayans at redhat.com Mon May 9 07:09:48 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 9 May 2016 09:09:48 +0200 Subject: [Freeipa-devel] [TBD] Automated tests, regressions and workarounds Message-ID: <573037BC.9070606@redhat.com> Hi guys, As a result of a situation formed around dnssec tests and one of the long-term bugs in dnssec feature [1], I'd like to share some general considerations with the whole team. First I'll state a couple of obvious things just to eliminate all possible fundamental disagreements. 1. The biggest purpose of test automation is to quickly find regressions in existing, released features 2. In order for the automated tests to effectively catch these regressions, the testsuite must 100% pas, so that any introduced issue will be noticed upon the very first test failure 3. Now, the standard workflow of using of automated tests is as follows: What happens, when a regression is found? Right, it's being quickly fixed, a new release is published, the test is green again, everybody is happy. What happens, if a team does not have enough resources to quickly (like within a week or so) fix this bug? Well. that's also quite a common situation. The company then elaborates a workaround, issues a notice with description of this bug and a workaround so that customers know about it and it would not affect their workflows. The tests are then tweaked accordingly with this known workaround automated so that each run is green again and ready to catch the next regression. Now, what happens if the tests are NOT tweaked? The team then has constantly "red" testruns which are not able to catch a next possible regression. And it inevitably occurs. Being uncaught by a team's CI it creeps into production and reach customers, who (quite expectedly) become nervous, because they would expect to receive at least a notice from the vendor, that the feature they are using has some more bugs in it. Guys, I am really sorry for being Captain Obvious here, but it seems that most of our team puts the principle "No workarounds, we need to fix the bug no matter what" above any common sense. [1] https://fedorahosted.org/freeipa/ticket/5348 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jhrozek at redhat.com Mon May 9 07:28:50 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 9 May 2016 09:28:50 +0200 Subject: [Freeipa-devel] Generate report of user access levels on each system In-Reply-To: References: Message-ID: <20160509072850.GH25501@hendrix> On Sun, May 08, 2016 at 12:14:57PM -0400, Jerel Gilmer wrote: > Hello all - > > I've been using IdM and was tasked by my management with generating two > system reports: > > - List of what users have access to what services on each system > - List of sudo rules for each system The list of applicable HBAC rules and SUDO rules is resolved by SSSD. This issue has come up before and we are tracking it in SSSD's tracker: https://fedorahosted.org/sssd/ticket/2840 but unfortunately the current milestone under development got already quite big, so it was bumped to the next version. > > I did a lot of research but couldn't find a simple way to do this so I > created scripts using ldapsearch calls that created the reports I needed. What you can do for the access control attestation is to run ipa hbactest. We don't have a similar tool for sudo. But looking into sssd's cache with ldbsearch on the target host itself might give some idea. > > I'm sending these out to the community for comment and for anyone that has > similar requirements. > > I've pasted the scripts below. If there are any issues with formatting, you > can download the scripts from my Github (github > com/jerelgilmer/freeipa-scripts) > > Jerel Gilmer > > ----------> server-access-report.py > #!/usr/bin/python > ''' > 2016 - March - 2 > Author: Jerel Gilmer > ''' > > import os > import sys > import ldap > > def print_usage(): > print "Usage: server-access-report.py " > print "This script generates the list of allowed users for each service > defined in applicable HBAC rules.\n" > print " - System hostname; This can be the short name\n" > print "For report of all systems, use \'.\'\n" > print "Make sure to set the below variables in the script:" > print "\tDOMAIN: Domain component" > print "\tLDAP_SERVER: LDAP server to be queried" > print "\tLDAP_USER: LDAP user to query server; preferable a read-only > account" > print "\tLDAP_PW: LDAP user's password\n" > sys.exit(1) > > try: > server = str(sys.argv[1]) > except: > print_usage() > > ## LDAP Connection Info and bind to the LDAP server > ## Uncomment and set these variables to the appropriate values > ## Below are examples > #DOMAIN = "dc=sub,dc=example,dc=com" > #LDAP_SERVER = "ldap://ipaserver1.sub.example.com" > #LDAP_USER = "uid=user1,cn=users,cn=compat," + DOMAIN > #LDAP_PW = "Password123" > > try: > DOMAIN > LDAP_SERVER > LDAP_USER > LDAP_PW > except: > print_usage() > > l = ldap.initialize(LDAP_SERVER) > > l.simple_bind_s(LDAP_USER,LDAP_PW) > > ## LDAP Search Variables > ## Base DN for LDAP Searches > baseComputerDN = "cn=computers,cn=accounts," + DOMAIN > baseGroupDN = "cn=groups,cn=accounts," + DOMAIN > baseUserDN = "cn=users,cn=accounts," + DOMAIN > baseHBACDN = "cn=hbac," + DOMAIN > baseHBACServicesDN = "cn=hbacservices,cn=hbac," + DOMAIN > baseHBACServiceGroupsDN = "cn=hbacservicegroups,cn=hbac," + DOMAIN > > ## Default LDAP SCOPE > scope = ldap.SCOPE_SUBTREE > > ## Filter for LDAP Searches > compFilter = "(&(objectclass=ipahost)(fqdn=*" + server + "*))" > hbacFilter = "(objectclass=ipahbacrule)" > userFilter = "(objectclass=person)" > groupFilter = "(objectclass=ipausergroup)" > hbacServiceFilter = "(objectclass=ipahbacservice)" > hbacServiceGroupsFilter = "(objectclass=ipahbacservicegroup)" > > ## Attributes from LDAP Searches > compAttributes = ['memberOf', 'fqdn'] > hbacAttributes = ['memberUser', 'memberService', 'serviceCategory'] > userAttributes = ['uid'] > groupAttributes = ['member'] > hbacServiceAttributes = ['cn' , 'ipaUniqueID'] > hbacServiceGroupsAttributes = ['cn' , 'member'] > > ## Perform LDAP searches and store results into array > ALL_HOSTS = l.search_s(baseComputerDN, scope, compFilter, compAttributes) > > ALL_USERS = l.search_s(baseUserDN, scope, userFilter, userAttributes) > > ALL_GROUPS = l.search_s(baseGroupDN, scope, groupFilter, groupAttributes) > > ALL_HBACRULES = l.search_s(baseHBACDN, scope, hbacFilter, hbacAttributes) > > ALL_HBACSERVICES = l.search_s(baseHBACServicesDN, scope, hbacServiceFilter, > hbacServiceAttributes) > > ALL_HBACSERVICEGROUPS = l.search_s(baseHBACServiceGroupsDN, scope, > hbacServiceGroupsFilter, hbacServiceGroupsAttributes) > > # HBAC rules that apply to all servers > hbacAllServersFilter = "(&(objectclass=ipahbacrule)(hostCategory=all))" > HBACRULE_ALL_SERVERS = l.search_s(baseHBACDN, scope, hbacAllServersFilter, > hbacAttributes) > > ALL_HOSTS.sort() > > def findUID(user): > uid = filter(lambda x: user in x, ALL_USERS) > return uid[0][1]['uid'][0] > > def findGroupMembers(groupname): > if "cn=groups,cn" not in groupname: > pass > group = filter(lambda x: groupname in x, ALL_GROUPS) > try: > groupmembers = group[0][1]['member'] > except: > groupmembers = "" > for user in groupmembers: > if "cn=groups,cn" in user: > for i in findGroupMembers(user): > yield i > else: > yield (findUID(user)) > > def findServiceName(service_name): > s = filter(lambda x: service_name in x, ALL_HBACSERVICES) > return s[0][1]['cn'][0] > > def findServiceGroupMembers(service_group): > allServices = [] > serviceGroup = filter(lambda x: service_group in x, ALL_HBACSERVICEGROUPS) > serviceGroupMembers = serviceGroup[0][1]['member'] > for i in serviceGroupMembers: > allServices.append(findServiceName(i)) > formattedAllServices = ', '.join(allServices) > return formattedAllServices > > def accessToAllSystems(): > allSystemsHBACRules = {} > > for hbacname in HBACRULE_ALL_SERVERS: > hbacrule = filter(lambda x: hbacname[0] in x, ALL_HBACRULES) > > for hbacuser in hbacrule: > services = [] > allowedUsers = [] > users = [] > groups = [] > > try: > users = filter(lambda x: "cn=users,cn" in x, hbacuser[1]['memberUser']) > except: > users = [] > > try: > groups = filter(lambda x: "cn=groups,cn" in x, > hbacuser[1]['memberUser']) > except: > groups = [] > > try: > hbacservice = hbacuser[1]['memberService'] > for i in hbacservice: > if "hbacservicegroups,cn" in i: > services.append(findServiceGroupMembers(i)) > else: > services.append(findServiceName(i)) > except: > try: > services = hbacuser[1]['serviceCategory'][0] > except: > services = ['None'] > > for i in users: > allowedUsers.append(findUID(i)) > > for i in groups: > allowedUsers += (findGroupMembers(i)) > > allSystemsHBACRules[hbacrule[0][0]] = {'services': services, > 'allowedUsers': allowedUsers} > > return allSystemsHBACRules > > def mergeD(results,services): > for k in results: > if services == results[k]['services']: > return "MATCH!!", k > > def nestedL(l): > if isinstance(l, str): > yield l > for k in l: > if isinstance(k, list): > for i in k: > yield i > if isinstance(k, str): > yield k > > def main(): > for entry in ALL_HOSTS: > systemWide = {} > HBACAllowedList = {} > results = {} > x = 1 > > fqdn = entry[1]['fqdn'][0] > > print "HOSTNAME = ", fqdn > try: > membership = filter(lambda x: "hbac,dc" in x, entry[1]['memberOf']) > except: > membership = [] > > for hbacname in membership: > hbacrule = filter(lambda x: hbacname in x, ALL_HBACRULES) > for hbacuser in hbacrule: > allowedUsers = [] > allowedUsersLst = [] > users = [] > groups = [] > services = [] > try: > hbacservice = hbacuser[1]['memberService'] > for i in hbacservice: > if "hbacservicegroups,cn" in i: > services.append(findServiceGroupMembers(i)) > else: > services.append(findServiceName(i)) > except: > try: > services = hbacuser[1]['serviceCategory'][0] > except: > services = [] > try: > users = filter(lambda x: "cn=users,cn" in x, hbacuser[1]['memberUser']) > except: > users = [] > > try: > groups = filter(lambda x: "cn=groups,cn" in x, > hbacuser[1]['memberUser']) > except: > groups = [] > > for i in users: > allowedUsers.append(findUID(i)) > > for i in groups: > allowedUsers += findGroupMembers(i) > > HBACAllowedList[hbacrule[0][0]] = {'services': services, > 'allowedUsers': allowedUsers} > > systemWide = accessToAllSystems() > HBACAllowedList.update(accessToAllSystems()) > > for key, value in HBACAllowedList.iteritems(): > > if isinstance(value['services'], list): > services = ', '.join(value['services']) > else: > services = value['services'] > > allowedUsers = value['allowedUsers'] > > try: > mark, key = mergeD(results,services) > except: > mark, key = (None, None) > > if mark == "MATCH!!": > results[key]['allowedUsers'].append(allowedUsers) > else: > results[x] = {'services': services, 'allowedUsers': allowedUsers} > x = x + 1 > > for i in results: > results_services = results[i]['services'] > > results_allowedUsers = list(nestedL(results[i]['allowedUsers'])) > results_allowedUsersSet = set(results_allowedUsers) > results_allowedUsersLst = list(results_allowedUsersSet) > results_allowedUsersLst.sort() > formatted_allowedUsers = ' '.join(results_allowedUsersLst) > > if not results_services: > results_services = 'empty' > if not formatted_allowedUsers: > formatted_allowedUsers = 'empty' > print "SERVICES = ", results_services > print "ALLOWED USERS = ", formatted_allowedUsers, "\n" > > main() > > -------------------------------------------------- > > -------------------> sudo-report.py > #!/usr/bin/python > ''' > 2016 - March - 2 > Author: Jerel Gilmer > ''' > > import os > import sys > import ldap > > def print_usage(): > print "Usage: server-access-report.py " > print "This script generates the list of sudo rules for each server.\n" > print " - System hostname; This can be the short name\n" > print "For report of all systems, use \'.\'\n" > print "Make sure to set the below variables in the script:" > print "\tDOMAIN: Domain component" > print "\tLDAP_SERVER: LDAP server to be queried" > print "\tLDAP_USER: LDAP user to query server; preferable a read-only > account" > print "\tLDAP_PW: LDAP user's password\n" > sys.exit(1) > > try: > server = str(sys.argv[1]) > except: > print_usage() > > ## LDAP Connection Info and bind to the LDAP server > ## Uncomment and set these variables to the appropriate values > ## Below are examples > #DOMAIN = "dc=sub,dc=example,dc=com" > #LDAP_SERVER = "ldap://ipaserver1" > #LDAP_USER = "uid=user1,cn=users,cn=compat," + DOMAIN > #LDAP_PW = "Password123" > > try: > DOMAIN > LDAP_SERVER > LDAP_USER > LDAP_PW > except: > print_usage() > > l = ldap.initialize(LDAP_SERVER) > > l.simple_bind_s(LDAP_USER,LDAP_PW) > > ## LDAP Search Variables > ## Base DN for LDAP Searches > baseComputerDN = "cn=computers,cn=accounts," + DOMAIN > baseGroupDN = "cn=groups,cn=accounts," + DOMAIN > baseUserDN = "cn=users,cn=accounts," + DOMAIN > baseSudoDN = "cn=sudorules,cn=sudo," + DOMAIN > baseSudoCmdDN = "cn=sudocmds,cn=sudo," + DOMAIN > baseSudoCmdGroupDN = "cn=sudocmdgroups,cn=sudo," + DOMAIN > > ## Default LDAP SCOPE > scope = ldap.SCOPE_SUBTREE > > ## Filter for LDAP Searches > compFilter = "(&(objectclass=ipahost)(fqdn=*" + server + "*))" > userFilter = "(objectclass=person)" > groupFilter = "(objectclass=ipausergroup)" > sudoFilter = "objectclass=ipasudorule" > sudoCmdFilter = "objectclass=ipasudocmd" > sudoCmdGroupFilter = "objectclass=ipasudocmdgrp" > > ## Attributes from LDAP Searches > compAttributes = ['memberOf', 'fqdn'] > userAttributes = ['uid'] > groupAttributes = ['member'] > sudoAttributes = ['memberUser', 'ipaSudoOpt', 'memberAllowCmd', > 'hostCategory', 'cmdCategory'] > sudoCmdAttributes = ['sudoCmd'] > sudoCmdGroupAttributes = ['member'] > > ## Perform LDAP searches and store results into array > ALL_HOSTS = l.search_s(baseComputerDN, scope, compFilter, compAttributes) > > ALL_USERS = l.search_s(baseUserDN, scope, userFilter, userAttributes) > > ALL_GROUPS = l.search_s(baseGroupDN, scope, groupFilter, groupAttributes) > > ALL_SUDORULES = l.search_s(baseSudoDN, scope, sudoFilter, sudoAttributes) > > ALL_SUDOCMDS = l.search_s(baseSudoCmdDN, scope, sudoCmdFilter, > sudoCmdAttributes) > > ALL_SUDOCMDGROUPS = l.search_s(baseSudoCmdGroupDN, scope, > sudoCmdGroupFilter, sudoCmdGroupAttributes) > > # Sudo rules that apply to all servers > sudoAllServersFilter = "(&(objectclass=ipasudorule)(hostCategory=all))" > SUDORULE_ALL_SERVERS = l.search_s(baseSudoDN, scope, sudoAllServersFilter, > sudoAttributes) > > ALL_HOSTS.sort() > > def findUID(user): > uid = filter(lambda x: user in x, ALL_USERS) > return uid[0][1]['uid'][0] > > def findGroupMembers(groupname): > if "cn=groups,cn" not in groupname: > pass > group = filter(lambda x: groupname in x, ALL_GROUPS) > try: > groupmembers = group[0][1]['member'] > except: > groupmembers = "" > for user in groupmembers: > if "cn=groups,cn" in user: > for i in findGroupMembers(user): > yield i > else: > yield (findUID(user)) > > def findSudoCmds(sudo_cmd): > s = filter(lambda x: sudo_cmd in x, ALL_SUDOCMDS) > return s[0][1]['sudoCmd'][0] > > def findSudoCmdGroupMembers(sudo_cmd_group): > allSudoCmds = [] > sudoGroup = filter(lambda x: sudo_cmd_group in x, ALL_SUDOCMDGROUPS) > sudoGroupMembers = sudoGroup[0][1]['member'] > for i in sudoGroupMembers: > allSudoCmds.append(findSudoCmds(i)) > formattedAllSudoCmds = ', '.join(allSudoCmds) > return formattedAllSudoCmds > > def sudoOnAllSystems(): > allSystemsSudoRules = {} > > for sudoname in SUDORULE_ALL_SERVERS: > sudorule = filter(lambda x: sudoname[0] in x, ALL_SUDORULES) > > for sudouser in sudorule: > sudocmds = [] > allowedUsers = [] > allowedSudoCmd = [] > users = [] > groups = [] > > try: > sudoOptions = ['ipaSudoOpt'] > except: > sudoOptions = [] > > try: > sudocmds = sudouser[1]['memberAllowCmd'] > for i in sudocmds: > if "cn=sudocmdgroups,cn" in i: > allowedSudoCmd.append(findSudoCmdGroupMembers(i)) > else: > allowedSudoCmd.append(findSudoCmds(i)) > except: > try: > if sudouser[1]['cmdCategory']: > allowedSudoCmd = sudouser[1]['cmdCategory'][0] > except: > allowedSudoCmd = ['None'] > > try: > sudocmdgroup = filter(lambda x: "cn=sudocmdgroups" in x, > sudouser[1]['memberAllowCmd']) > except: > sudocmdgroup = '' > > try: > users = filter(lambda x: "cn=users,cn" in x, sudouser[1]['memberUser']) > except: > users = [] > > try: > groups = filter(lambda x: "cn=groups,cn" in x, > sudouser[1]['memberUser']) > except: > groups = [] > > for i in users: > allowedUsers.append(findUID(i)) > > for i in groups: > allowedUsers += (findGroupMembers(i)) > > allSystemsSudoRules[sudorule[0][0]] = {'sudoCommands': allowedSudoCmd, > 'allowedUsers': allowedUsers} > > return allSystemsSudoRules > > def mergeD(results,allowedSudoCmd): > for k in results: > if allowedSudoCmd == results[k]['sudoCommands']: > return "MATCH!!", k > > def nestedL(l): > if isinstance(l, str): > yield l > for k in l: > if isinstance(k, list): > for i in k: > yield i > if isinstance(k, str): > yield k > > def main(): > for entry in ALL_HOSTS: > SudoAllowedList = {} > results = {} > x = 1 > > fqdn = entry[1]['fqdn'][0] > > print "HOSTNAME = ", fqdn > > try: > membership = filter(lambda x: "sudo,dc" in x, entry[1]['memberOf']) > except: > membership = [] > > for sudoname in membership: > sudorule = filter(lambda x: sudoname in x, ALL_SUDORULES) > for sudouser in sudorule: > allowedUsers = [] > allowedUsersLst = [] > allowedSudoLst = [] > allowedSudoCmd = [] > users = [] > groups = [] > > try: > sudoOptions = ['ipaSudoOpt'] > except: > sudoOptions = [] > > try: > sudocmds = sudouser[1]['memberAllowCmd'] > for i in sudocmds: > if "cn=sudocmdgroups,cn" in i: > allowedSudoCmd.append(findSudoCmdGroupMembers(i)) > else: > allowedSudoCmd.append(findSudoCmds(i)) > except: > try: > if sudouser[1]['cmdCategory']: > allowedSudoCmd = sudouser[1]['cmdCategory'][0] > except: > allowedSudoCmd = ['None'] > > try: > users = filter(lambda x: "cn=users,cn" in x, sudouser[1]['memberUser']) > except: > users = [] > > try: > groups = filter(lambda x: "cn=groups,cn" in x, > sudouser[1]['memberUser']) > except: > groups = [] > > for i in users: > allowedUsers.append(findUID(i)) > > for i in groups: > allowedUsers += findGroupMembers(i) > > SudoAllowedList[sudorule[0][0]] = {'sudoCommands': allowedSudoCmd, > 'allowedUsers': allowedUsers} > > systemWide = sudoOnAllSystems() > SudoAllowedList.update(systemWide) > > for key, value in SudoAllowedList.iteritems(): > > if isinstance(value['sudoCommands'], list): > allowedSudoCmd = ', '.join(value['sudoCommands']) > else: > allowedSudoCmd = value['sudoCommands'] > > allowedUsers = value['allowedUsers'] > > try: > mark, key = mergeD(results,allowedSudoCmd) > except: > mark, key = (None, None) > > if mark == "MATCH!!": > results[key]['allowedUsers'].append(allowedUsers) > else: > results[x] = {'sudoCommands': allowedSudoCmd, 'allowedUsers': > allowedUsers} > x = x + 1 > > for i in results: > results_allowedSudoCmd = results[i]['sudoCommands'] > > results_allowedUsers = list(nestedL(results[i]['allowedUsers'])) > results_allowedUsersSet = set(results_allowedUsers) > results_allowedUsersLst = list(results_allowedUsersSet) > results_allowedUsersLst.sort() > formatted_allowedUsers = ' '.join(results_allowedUsersLst) > > if not results_allowedSudoCmd: > results_services = 'empty' > if not formatted_allowedUsers: > formatted_allowedUsers = 'empty' > print "SUDO COMMANDS = ", results_allowedSudoCmd > print "ALLOWED USERS = ", formatted_allowedUsers, "\n" > > main() > > ------------------------------------------------ > -- > 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 From jcholast at redhat.com Mon May 9 07:35:06 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 May 2016 09:35:06 +0200 Subject: [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> Message-ID: Hi, On 6.5.2016 08:01, Fraser Tweedale wrote: > Hullo all, > > FreeIPA Lightweight CAs implementation is progressing well. The > remaining big unknown in the design is how to do renewal. I have > put my ideas into the design page[1] and would appreciate any and > all feedback! > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal > > Some brief commentary on the options: > > I intend to implement approach (1) as a baseline. Apart from > implementing machinery in Dogtag to actually perform the renewal - > which is required for all the approaches - it's not much work and > gets us over the "lightweight CAs can be renewed easily" line, even > if it is a manual process. > > For automatic renewal, I am leaning towards approach (2). Dogtag > owns the lightweight CAs so I think it makes sense to give Dogtag > the ability to renew them automatically (if configured to do so), > without relying on external tools i.e. Certmonger. But as you will > see from the outlines, each approach has its upside and downside. I would prefer (3), as I would very much like to avoid duplicating certmonger's functionality in Dogtag. Some comments on the disadvantages: * "Proliferation of Certmonger tracking requests; one for each FreeIPA-managed lightweight CA." I don't think this is an actual issue, as it's purely cosmetic. * "Either lightweight CA creation is restricted to the renewal master, or the renewal master must observe the creation of new lightweight CAs and start tracking their certificate." IMO this doesn't have to be done automatically in the initial implementation. You could extend ipa-certupdate to set up certmonger for lightweight CAs and have admins run it manually on masters after adding a new lightweight CA. They will have to run it anyway to get the new lightweight CA certificate installed in the system, so it should be fine to do it this way. * "Development of new Certmonger renewal helpers solely for lightweight CA renewal." It would be easier to extend the existing helpers. I don't think there is anything preventing them from being used for lighweight CAs, except not conveying the CA name, which should be easy to implement. I would also avoid starting with (1), I don't believe it adds any real value. IMHO the first thing that should be done is implement lightweight CA support in certmonger (add new 'request' / 'start-tracking' option for CA name, store it in tracking requests, pass it to CA helpers in a new environment variable). Honza -- Jan Cholasta From pspacek at redhat.com Mon May 9 07:58:55 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 09:58:55 +0200 Subject: [Freeipa-devel] [PATCH 0013] Updated ipa-server-install man page for domain-level attribute In-Reply-To: <572C2C9A.5030000@redhat.com> References: <572C2C9A.5030000@redhat.com> Message-ID: <7f70763e-c89f-fe30-7cb7-ba1c155094cc@redhat.com> On 6.5.2016 07:33, Abhijeet Kasurde wrote: > Please review this patch. Good catch! In general, I believe that man page should explain what domain level means (probably with an example of levels 0 and 1) so the user can actually use the man page to find out what value is needed for his purposes. Considering this, I have to NACK this patch. Please elaborate. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Mon May 9 08:02:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 10:02:42 +0200 Subject: [Freeipa-devel] [PATCH 0014] Removed custom implementation of CalledProcessError In-Reply-To: <572D8EE3.2050800@redhat.com> References: <572D8EE3.2050800@redhat.com> Message-ID: <3ff432b0-0e2a-0d31-8dd3-5e07e9be15e2@redhat.com> On 7.5.2016 08:44, Abhijeet Kasurde wrote: > Hi All, > > Please review this patch. ACK, I've verified that CalledProcessError signature in Python 2.7 and in the duplicate code is the same. -- Petr^2 Spacek From tbordaz at redhat.com Mon May 9 09:50:10 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 9 May 2016 11:50:10 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: References: <5729E929.6010307@redhat.com> Message-ID: <57305D52.5090202@redhat.com> On 05/05/2016 03:44 PM, Petr Vobornik wrote: > On 05/04/2016 02:20 PM, thierry bordaz wrote: >> Hello, >> >> I have been doing some tests/measures using >> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >> The tool creates a set of typical users/hosts/groups... to import with a >> ldapadd. >> >> I wrote down some finding in >> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >> I still have to do some cleanup around the performance but the basic of a >> possible improvement is to do provisioning in several steps (disabling >> plugins, provisioning, enabling plugin, running fixup tasks). >> >> Before going further in the design I wanted to share those ideas and know if >> it raise any concern. >> >> thanks >> thierry >> > Hi Thierry, > > Thanks for the analysis. Very nice. > > Knowing this will help us suggesting workarounds also for old releases. > > Couple questions: > > Have you tested retrCL disabled with memberOf enabled. It seems that it > would eliminate 550K adds and 0.8M searches. What would be the time > improvement? Basically provisioning/migrate does not scale well because of memberOf. Each time you add a member to a group you need to reevalute its membership (15M search) and finally update the member (that is a MOD for the member + ADD in retroCL). If a same entry is added to a group and later added to an other group, the first evaluation/updates are useless. Disabling memberof drops SRCH from 15M -> ~1M. You can get an additional gain ~1M -> ~0.1M if you disable retroCL. I tested retroCL disabled / memberOf enabled but on a different dataset. It gaves low improvement in term of duration. I think MODs are here more expensive that ADD. I will test your suggestion to confirm the numbers. > > Do you know what is the time when memberof is enabled but slapi-nis and > retroCL are disabled? No. I will test it. > > From the text it was not clear to me, if you find or investigate > possible improvements in memberof plugin which would improve the > performance without stopping and starting DS. memberof does not scale well because of #SRCH and #MOD. Ludwig suggested a group caching that is looking close to other in-memory implementations of memberof. Such cache would reduce the #SRCH possibly from 15M->1M, but the implementation is not immediate. Also note that filling the cache has a cost that can delay startup (like we saw in slapi-nis) and a memory footprint. Regarding the MODs we can make memberof attribute a virtual attribute and stop updating the entries. This is also not immediate to implement: rewrite memberof plugin. From 7.3 schedule, I think we can get an important improvement if DS start-stop is acceptable. Improving memberof is more a longer term option. thanks thierry From placko at redhat.com Mon May 9 10:19:10 2016 From: placko at redhat.com (Peter Lacko) Date: Mon, 9 May 2016 06:19:10 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0002 New User Role Tests In-Reply-To: <2082574617.50966046.1462788885740.JavaMail.zimbra@redhat.com> Message-ID: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> Hi! New User Role Tests, extending coverage of previous declarative tests are ready for review. Peter Lacko placko at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0002-New-User-Role-Tests.patch Type: text/x-patch Size: 68352 bytes Desc: not available URL: From mbasti at redhat.com Mon May 9 11:04:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 9 May 2016 13:04:15 +0200 Subject: [Freeipa-devel] [PATCH] 0002 New User Role Tests In-Reply-To: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> References: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> Message-ID: <19bc3a86-8e60-f023-6bab-b807a3d03364@redhat.com> On 09.05.2016 12:19, Peter Lacko wrote: > +# pylint: disable=unicode-builtin I'm not doing complete review, just the line above hit my eyes. unicode() is not in Py3 because all strings there are unicode, thus you cannot use it directly, you need something like if six.PY2: str = unicode and use str() everywhere and remove that #pylint line FYI all enabled pylint checks are there for a good reason, be careful with disabling it (mainly disabling it for a whole module) rather ask before if you are not sure. Martin^2 From mbasti at redhat.com Mon May 9 11:06:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 9 May 2016 13:06:08 +0200 Subject: [Freeipa-devel] [PATCH] 0002 New User Role Tests In-Reply-To: <19bc3a86-8e60-f023-6bab-b807a3d03364@redhat.com> References: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> <19bc3a86-8e60-f023-6bab-b807a3d03364@redhat.com> Message-ID: On 09.05.2016 13:04, Martin Basti wrote: > > > On 09.05.2016 12:19, Peter Lacko wrote: >> +# pylint: disable=unicode-builtin > I'm not doing complete review, just the line above hit my eyes. > > unicode() is not in Py3 because all strings there are unicode, thus > you cannot use it directly, you need something like > > if six.PY2: > str = unicode > > and use str() everywhere and remove that #pylint line > > FYI all enabled pylint checks are there for a good reason, be careful > with disabling it (mainly disabling it for a whole module) rather ask > before if you are not sure. > > Martin^2 > Nope, sorry, I temporarily forgot how to python instead of pylint disable use this if six.PY3: unicode =str and keep unicode there. Sorry Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon May 9 12:07:42 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 May 2016 14:07:42 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> Message-ID: On 6.5.2016 14:32, Martin Basti wrote: > > > On 28.04.2016 14:45, Jan Cholasta wrote: >> Hi, >> >> I have pushed my thin client WIP branch to GitHub: >> . >> >> All commits up to "ipalib: use relative imports for cross-plugin >> imports" should be good for review. The rest is subject to change >> (WARNING: I will force push into this branch). >> >> Honza >> > I did not test it yet, I just checked the code > > * automount: do not inherit automountlocation_tofiles from LDAPQuery * > LGTM > > * dns: move all dnsrecord code called on client to a single class * > LGTM > > * dns: do not rely on server data structures in code called on client * > 1) > you forgot to increment VERSION This was deliberate, as it will no longer be necessary to bump VERSION for backward compatible changes after this whole patchset is merged. But we're not there yet, so fixed. > > Otherwise LGTM > > * otptoken: fix import of DN * > ACK > > * otptoken_yubikey: fix otptoken_add_yubikey arguments * > 1) > you forgot to increment VERSION Fixed. > > 2) > Did you find out why this was issue? > - del answer['value'] # Why does this cause an error if omitted? > - del answer['summary'] # Why does this cause an error if omitted? The command definition was not complete, it was missing has_output. > > Otherwise LGTM > > * vault: move client-side code to the module level * > LGTM > > * vault: copy arguments of client commands from server counterparts * > 1) > you forgot to increment Version Fixed. > > * ipalib: use relative imports for cross-plugin imports * > 1) Missing explanation for future generations why this change is needed > in commit message Fixed. > > The other commits I will check later. > Martin^2 > Okay. Thanks. -- Jan Cholasta From pspacek at redhat.com Mon May 9 14:25:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 16:25:06 +0200 Subject: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release Message-ID: <1dc06d62-9894-6e43-ccb5-0fe79b4db1c0@redhat.com> Hello, following patch should cover most misleading warnings produced by new code handling empty zones. If it is okay I will release version 9.0 with it. Please review it ASAP. Thank you very much! -- Petr^2 Spacek From pspacek at redhat.com Mon May 9 14:30:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 16:30:35 +0200 Subject: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release In-Reply-To: <1dc06d62-9894-6e43-ccb5-0fe79b4db1c0@redhat.com> References: <1dc06d62-9894-6e43-ccb5-0fe79b4db1c0@redhat.com> Message-ID: <0200bd34-1390-b096-8e18-a0b643e12dfa@redhat.com> On 9.5.2016 16:25, Petr Spacek wrote: > Hello, > > following patch should cover most misleading warnings produced by new code > handling empty zones. > > If it is okay I will release version 9.0 with it. > > Please review it ASAP. Thank you very much! ... and here are patches :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: 0399-Do-not-log-warning-about-empty-zones-which-are-alrea.patch Type: text/x-patch Size: 4667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0400-Document-new-empty-zone-handling-mechanism.patch Type: text/x-patch Size: 1281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0401-Update-NEWS-for-upcoming-9.0-release.patch Type: text/x-patch Size: 929 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0402-Bump-NVR-to-9.0.patch Type: text/x-patch Size: 1145 bytes Desc: not available URL: From pspacek at redhat.com Mon May 9 14:32:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 16:32:35 +0200 Subject: [Freeipa-devel] [PATCH 0391-0392] Add missing return value checks to pthread operations & replace strcmp(var, "") with strlen(var) to workaround Clang bug 20144 In-Reply-To: References: <56D59AE9.1040004@redhat.com> Message-ID: On 5.5.2016 16:44, Tomas Hozza wrote: > On 03/01/2016 02:36 PM, Petr Spacek wrote: >> Hello, >> >> Add missing return value checks to pthread operations. >> Detected by clang 3.8 -O2 -Wunused-value. >> >> Replace strcmp(var, "") with strlen(var) to workaround Clang bug 20144. >> https://llvm.org/bugs/show_bug.cgi?id=20144 >> > > ACK. > > I was not able to reproduce the issues. However the changes look good to me. I tested the plugin on Fedora 24 with basic tasks (query, zone transfer, DNS update) without DNSSEC signing. Thanks! Pushed to master: 4a73d9aa3d049e5cbf18f37f932c101a9b16844c f23821137b60a4500567258723f979c0d4ca3133 -- Petr^2 Spacek From jerel.gilmer at gmail.com Mon May 9 14:33:51 2016 From: jerel.gilmer at gmail.com (Jerel Gilmer) Date: Mon, 9 May 2016 10:33:51 -0400 Subject: [Freeipa-devel] Generate report of user access levels on each system In-Reply-To: <20160509072850.GH25501@hendrix> References: <20160509072850.GH25501@hendrix> Message-ID: Thanks Jakub. My goal for the scripts I wrote would be to potentially address both: https://fedorahosted.org/freeipa/ticket/3775 https://fedorahosted.org/sssd/ticket/2840 The scripts could be run centrally from an IdM server and produce a report for all registered systems in under a few seconds. I have over 1100 systems in my environment. Using the 'ipa hbactest' to produce a similar report would take too long to run. Using the sssd cache on each systems would be a local approach that couldn't be scaled in my environment. The scripts allow for producing centralized system auditing and reporting. One issue I noticed users run into is the need to produce reports of system's allowed users and sudo rules. Although I can easily list the HBAC and Sudo rules for each system, trying to pull a user list can be a tedious task. That's where these scripts come in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon May 9 14:46:27 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 May 2016 16:46:27 +0200 Subject: [Freeipa-devel] [PATCH 0393-0398] Unload automatic empty zones only if conflicting forward zone has policy 'only'Add ability to log warningsUnload automatic empty zones which are super/sub/equal domain as forward zoneDo not touch global forwarders from named.conf if there is no config in LDAPAdd missing includes to util.hMove zone_isempty() and delete_bind_zone() to zone_register.c In-Reply-To: <0ccf65c5-403e-a61e-618b-ad9bd4e34049@redhat.com> References: <5704F62A.8050606@redhat.com> <0ccf65c5-403e-a61e-618b-ad9bd4e34049@redhat.com> Message-ID: On 6.5.2016 16:41, Tomas Hozza wrote: > On 04/06/2016 01:42 PM, Petr Spacek wrote: >> Hello, >> >> attached patch set implements >> https://fedorahosted.org/bind-dyndb-ldap/ticket/160 >> described in >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >> >> It will be accompanied with upgrade code in FreeIPA which will automatically >> convert forward zones as necessary. >> > > ACK. > > I reviewed the patches on GitHub (https://github.com/pspacek/bind-dyndb-ldap/commits/empty_zones_unload_only) > > I have these comments: > > - commit 396 (https://github.com/pspacek/bind-dyndb-ldap/commit/a1bb7c0f802107d1fc67de8a58d0f33095accd06) > > - it uses "forwarders" in wrong context. In many places and also in the commit message you should use "forward zone" instead of "forwarder". "forwarder is the server to which the queries are forwarded, not the zone. > > - It wold be nice to explicitly note in the commit message, that conflicting empty zones are unloaded regardless of the forward policy ("only" or "first"). I've fixed this before push. > - It would be good to document, that once you add forward zone, which causes removal of empty zone and then you remove the forward zone, the empty zone is not added back. The empty zone will appear again only after restart of BIND, when it loads all empty zones and only existing ones are removed. The situation is the same when you configure global forwarders and them remove them = all empty zones are unloaded and these are not added back until the restart of BIND. This is a limitation and IMHO the users should be informed about this behavior, as it may not be completely expected. Good idea! This will be documented in follow-up patch. > - Configuring global forwarders as forward first creates too many log messages (for each empty zone). This may not be a problem, but it is IMHO not necessary. Also when I configure global forwarders as forward "only" and then change it to forward "first", the log message is printed even though the empty zones are not there any more, which is a bit misleading. Okay, I can improve this a little bit so zones which were once unloaded will not be reported again. This is a matter for a follow-up patch. On the other hand, I'm going to print message for every zone because this is was BIND 9.11 is doing. > - Warning log message about the configuration of global forward zone are logged every time on start-up regardless of the forward policy set in LDAP. This is caused by forwarding policy configured in named.conf. I will think about possible fix but it is not that easy. For now I will leave it as it is. Maybe rebase to BIND 9.11 will fix it for us because they print warnings, too. > Other than that the changes look good to me. The functionality works as documented with the shortcomings mentioned above. Thanks, pushed to master: 3232aa4f35850c5164e7ec0b9cc523e3cf7bdb5d Unload automatic empty zones only if conflicting forward zone has policy 'only'. 4174e96496aad3dc8b7040b552aa589157d9ede6 Add ability to log warnings. 5c3312cee1c080c5df45741da26ed801a9262d74 Unload automatic empty zones which are super/sub/equal domain as forward zone. 998b3fbd055dd455c0c0f3ebf7a68efe12e5ce52 Do not touch global forwarders from named.conf if there is no config in LDAP. ffcfb9563ae97cdc345d5611ccc168101fdffeeb Add missing includes to util.h. 168ed7bb2145f1c515e0f6166e24797630949df2 Move zone_isempty() and delete_bind_zone() to zone_register.c. Thank you very much for your time! > PS: There seems to be some kind of race condition when you configure forward zone and you have global forwarding turned off. In case you configure a forward zone with forward "only" and it conflicts with an empty zone, you can get SERVFAIL from the server for hostname from such zone. It is reproducible only if you are quick enough. The next query is forwarded correctly and the response from forwarder is returned. I think that this is there since forever and I have no idea why it happens and what we can do to fix it :-( -- Petr^2 Spacek From pvoborni at redhat.com Mon May 9 16:27:19 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 9 May 2016 18:27:19 +0200 Subject: [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> Message-ID: On 05/09/2016 09:35 AM, Jan Cholasta wrote: > Hi, > > On 6.5.2016 08:01, Fraser Tweedale wrote: >> Hullo all, >> >> FreeIPA Lightweight CAs implementation is progressing well. The >> remaining big unknown in the design is how to do renewal. I have >> put my ideas into the design page[1] and would appreciate any and >> all feedback! >> >> [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal >> >> Some brief commentary on the options: >> >> I intend to implement approach (1) as a baseline. Apart from >> implementing machinery in Dogtag to actually perform the renewal - >> which is required for all the approaches - it's not much work and >> gets us over the "lightweight CAs can be renewed easily" line, even >> if it is a manual process. >> >> For automatic renewal, I am leaning towards approach (2). Dogtag >> owns the lightweight CAs so I think it makes sense to give Dogtag >> the ability to renew them automatically (if configured to do so), >> without relying on external tools i.e. Certmonger. But as you will >> see from the outlines, each approach has its upside and downside. > > I would prefer (3), as I would very much like to avoid duplicating > certmonger's functionality in Dogtag. > > Some comments on the disadvantages: > > * "Proliferation of Certmonger tracking requests; one for each > FreeIPA-managed lightweight CA." > > I don't think this is an actual issue, as it's purely cosmetic. > > * "Either lightweight CA creation is restricted to the renewal master, > or the renewal master must observe the creation of new lightweight CAs > and start tracking their certificate." > > IMO this doesn't have to be done automatically in the initial > implementation. You could extend ipa-certupdate to set up certmonger for > lightweight CAs and have admins run it manually on masters after adding > a new lightweight CA. They will have to run it anyway to get the new > lightweight CA certificate installed in the system, so it should be fine > to do it this way. I'm afraid that it can lead to errors where admins would distribute the cert by other means and as a result this command would not be run on renewal master even though it is easier. But it is still better than #1 without auto-renewal mechanism. > > * "Development of new Certmonger renewal helpers solely for > lightweight CA renewal." > > It would be easier to extend the existing helpers. I don't think > there is anything preventing them from being used for lighweight CAs, > except not conveying the CA name, which should be easy to implement. > > > I would also avoid starting with (1), I don't believe it adds any real > value. IMHO the first thing that should be done is implement lightweight > CA support in certmonger (add new 'request' / 'start-tracking' option > for CA name, store it in tracking requests, pass it to CA helpers in a > new environment variable). > > > Honza > -- Petr Vobornik From rcritten at redhat.com Mon May 9 18:28:12 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 9 May 2016 14:28:12 -0400 Subject: [Freeipa-devel] LDAP attributes with incompatible names? In-Reply-To: References: Message-ID: <5730D6BC.9080608@redhat.com> Jeffery Harrell wrote: > Hi. I?m trying to find a way to expose via the Python plugin API some > non-default LDAP attributes that have hyphens in their names ? e.g, > "apple-user-homeurl?. Obviously I can?t create a Param with that name. > Is there a customary way to handle this kind of situation, or do I have > to subclass Param? A Param needs to be a valid python variable name which is why dashes aren't allowed. I'm not sure subclassing the parameter type would do it but you can try. I suspect it needs to be addressed in the LDAP code. I think what I'd do is use underscore instead of dash, then do a replacement before storing and retrieving the attributes. This is probably in ipapython/ipaldap.py. rob From mbasti at redhat.com Tue May 10 07:43:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 09:43:45 +0200 Subject: [Freeipa-devel] [PATCH 0015] Added exception handling for mal-formatted XML Parsing In-Reply-To: <57301F9B.6070005@redhat.com> References: <57301F9B.6070005@redhat.com> Message-ID: <8524648f-ff10-6747-07d3-b1ca6bafb13d@redhat.com> On 09.05.2016 07:26, Abhijeet Kasurde wrote: > Hi all, > > Please review the patch. > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1333755 > > Thanks, > Abhijeet Kasurde > > > Hello, + self.raise_certificate_operation_error('parse', + detail=e.msg) Please use detail=str(e), e.msg is deprecated Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 07:47:50 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 09:47:50 +0200 Subject: [Freeipa-devel] [PATCH 0014] Removed custom implementation of CalledProcessError In-Reply-To: <3ff432b0-0e2a-0d31-8dd3-5e07e9be15e2@redhat.com> References: <572D8EE3.2050800@redhat.com> <3ff432b0-0e2a-0d31-8dd3-5e07e9be15e2@redhat.com> Message-ID: <8f0de95d-2a81-b580-7f2c-4c515eefe881@redhat.com> On 09.05.2016 10:02, Petr Spacek wrote: > On 7.5.2016 08:44, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review this patch. > ACK, I've verified that CalledProcessError signature in Python 2.7 and in the > duplicate code is the same. > Pushed to master: 51db9380cfc862993e1909602d2726e851f463b4 From mbasti at redhat.com Tue May 10 08:00:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 10:00:09 +0200 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: <57298605.60203@redhat.com> Message-ID: <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> On 04.05.2016 15:14, Gabe Alford wrote: > On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde > wrote: > > Hi Gabe, > > I am wondering, how are we handling "CalledProcessError" exception ? > > > I am not sure 100% what you are asking, but from what I understand, > the "CalledProcessError" exception is when a process returns a > non-zero exit status. > However when running 'ipa-nis-manage enable', an exception is never > hit even if portmap is not installed, hence portmap always being enabled. > > So it seems that if the process is not installed, "CalledProcessError" > doesn't catch an error. > > Gabe Hello, portmap.enable() may raise the "CalledProcessError" in case that systemct enable failed and we should catch this exception and handle it in the same way as it is done now. i.e catch that exception and set proper return state. Martin^2 > On 05/04/2016 09:17 AM, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5857 >> >> Thanks, >> >> Gabe >> >> > Thanks, > Abhijeet Kasurde > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 08:14:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 10:14:47 +0200 Subject: [Freeipa-devel] [PATCH 0102] DNS: Fix upgrade - master to forward zone transformatio In-Reply-To: <57234BE4.8080404@redhat.com> References: <571FAF6A.6080002@redhat.com> <57234BE4.8080404@redhat.com> Message-ID: <4a279d51-9338-d9f6-fbf2-d8b2ab4ae83e@redhat.com> On 29.04.2016 13:56, Martin Basti wrote: > > > On 26.04.2016 20:11, Petr Spacek wrote: >> Hello, >> >> DNS: Fix upgrade - master to forward zone transformation >> >> This happens when upgrading from IPA <= 4.0 to versions 4.3+. >> >> DNS caching might cause false positive in code which replaces master zone >> with forward zone. This will effectivelly delete the master zone >> without adding a replacement forward zone. >> >> Solution is to use skip_overlap_check option for dnsforwardzone_add command >> so zone existence check is skipped and the upgrade can proceed. >> >> https://fedorahosted.org/freeipa/ticket/5851 >> >> >> > ACK > > Pushed to: master: 475547fa40f6244ce838b8ce30e77cf32ee250be ipa-4-3: 4a270fc878fb0e036821066c34b41e93e258c4b4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue May 10 08:45:04 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 May 2016 10:45:04 +0200 Subject: [Freeipa-devel] [DESIGN] Lightweight CA renewal In-Reply-To: References: <20160506060158.GZ1237@dhcp-40-8.bne.redhat.com> Message-ID: <317cf8dd-22da-c320-2525-5aac4d5ebcf3@redhat.com> On 9.5.2016 18:27, Petr Vobornik wrote: > On 05/09/2016 09:35 AM, Jan Cholasta wrote: >> Hi, >> >> On 6.5.2016 08:01, Fraser Tweedale wrote: >>> Hullo all, >>> >>> FreeIPA Lightweight CAs implementation is progressing well. The >>> remaining big unknown in the design is how to do renewal. I have >>> put my ideas into the design page[1] and would appreciate any and >>> all feedback! >>> >>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal >>> >>> Some brief commentary on the options: >>> >>> I intend to implement approach (1) as a baseline. Apart from >>> implementing machinery in Dogtag to actually perform the renewal - >>> which is required for all the approaches - it's not much work and >>> gets us over the "lightweight CAs can be renewed easily" line, even >>> if it is a manual process. >>> >>> For automatic renewal, I am leaning towards approach (2). Dogtag >>> owns the lightweight CAs so I think it makes sense to give Dogtag >>> the ability to renew them automatically (if configured to do so), >>> without relying on external tools i.e. Certmonger. But as you will >>> see from the outlines, each approach has its upside and downside. >> >> I would prefer (3), as I would very much like to avoid duplicating >> certmonger's functionality in Dogtag. >> >> Some comments on the disadvantages: >> >> * "Proliferation of Certmonger tracking requests; one for each >> FreeIPA-managed lightweight CA." >> >> I don't think this is an actual issue, as it's purely cosmetic. >> >> * "Either lightweight CA creation is restricted to the renewal master, >> or the renewal master must observe the creation of new lightweight CAs >> and start tracking their certificate." >> >> IMO this doesn't have to be done automatically in the initial >> implementation. You could extend ipa-certupdate to set up certmonger for >> lightweight CAs and have admins run it manually on masters after adding >> a new lightweight CA. They will have to run it anyway to get the new >> lightweight CA certificate installed in the system, so it should be fine >> to do it this way. > > I'm afraid that it can lead to errors where admins would distribute the > cert by other means and as a result this command would not be run on > renewal master even though it is easier. But it is still better than #1 > without auto-renewal mechanism. Admins can screw up using any of the proposed approaches, so IMHO this argument is invalid :-) > >> >> * "Development of new Certmonger renewal helpers solely for >> lightweight CA renewal." >> >> It would be easier to extend the existing helpers. I don't think >> there is anything preventing them from being used for lighweight CAs, >> except not conveying the CA name, which should be easy to implement. >> >> >> I would also avoid starting with (1), I don't believe it adds any real >> value. IMHO the first thing that should be done is implement lightweight >> CA support in certmonger (add new 'request' / 'start-tracking' option >> for CA name, store it in tracking requests, pass it to CA helpers in a >> new environment variable). >> >> >> Honza >> -- Jan Cholasta From mbasti at redhat.com Tue May 10 10:23:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 12:23:13 +0200 Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <5722198D.2040305@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> Message-ID: On 28.04.2016 16:09, Martin Basti wrote: > > > On 08.04.2016 10:32, Peter Lacko wrote: >> >> > > Hello, > > I have a few comments: > > 1) > Please set up your git name and email correctly (consistently for all > patches) > this is not right From: root > > 2) > -# Copyright (C) 2012 Red Hat > +# Copyright (C) 2016 Red Hat > > leave there both years please > +# Copyright (C) 2012, 2016 Red Hat > > 3) > Please put the patch number to the email subject, it is easier to find correct patch for us > > Otherwise LGTM and works for me. > > Martin^2 > > Sorry I didn't noticed earlier, but your patch doesn't work under python3 from xmlrpc_test import XMLRPC_test, raises_exact E ImportError: No module named 'xmlrpc_test' You must use absolute import, not relative in py3 Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 10 10:34:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 12:34:59 +0200 Subject: [Freeipa-devel] [PATCH 0096] Batch command: avoid accessing potentially undefined context.principa In-Reply-To: <4e5bc6fe-d0d1-c331-7651-32224d6b5f4b@redhat.com> References: <571A0AD3.3090507@redhat.com> <4e5bc6fe-d0d1-c331-7651-32224d6b5f4b@redhat.com> Message-ID: On 4.5.2016 15:04, Jan Cholasta wrote: > Hi, > > On 22.4.2016 13:28, Petr Spacek wrote: >> Hello, >> >> Batch command: avoid accessing potentially undefined context.principal >> >> This might happen when the command is called directly in Python, >> e.g. in installers and so on. >> >> Pylint pylint-1.5.5-1.fc24.noarch caught this. >> >> https://fedorahosted.org/freeipa/ticket/5838 > > LGTM, but please use 'UNKNOWN' as the default value, for consistency with > ipalib.rpcserver code. Here you are. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0096-2-Batch-command-avoid-accessing-potentially-undefined-.patch Type: text/x-patch Size: 1306 bytes Desc: not available URL: From ftweedal at redhat.com Tue May 10 10:36:17 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 10 May 2016 20:36:17 +1000 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> References: <57161E1F.6020001@redhat.com> <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> Message-ID: <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> Honza, thanks for the review. Comments inline. Copy Nalin, re certmonger discussion at the very bottom. On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote: > Hi, > > 1) > > > """ > The "upstream" root certificate and intermediate CA certificates would be > stored in LDAP for distribution to clients, with the root CA having an > ipaKeyTrust value of trusted and intermediate CAs having a value of unknown > (see CA certificate renewal). > """ > > Note that currently it's the IPA CA that is trusted by default, not any of > the external (root or intermediate) CAs. I think it should stay this way, as > we don't need to trust any of the external CAs for IPA to work correctly. > Thanks for the clarification. I updated the design page. It is not going to be in the initial implementation but good to know! > > 2) > > It should be mentioned here that the primary CA is also handled by this > plugin. > > I would like to propose two additional fields: > > * subject (required) - subject name of the CA, to be able to look up > sub-CA that issued a certificate from its issuer name. > > * issuer_ca (optional) - name of the sub-CA which issued certificate for > this CA, to have information about the sub-CA hierarchy. If there is no > sub-CA entry for the issuer, it would be unset. > These data exist in the Dogtag database. Adding them to IPA might be useful for avoiding round trips so it is probably worth doing, but are you aware of use cases that would absolutely require them? > > 3) > > """ > Subject Distinguished Name > > When creating a sub-CA, the subject DN is constructed by copying the DN of > the parent CA, then setting the CN to the name. More control could be > implemented if there is a clear case for it. > """ > > Note that adding the ability to override the CN in the subject name of the > IPA CA certificate was requested a long time ago: > . > This text was vestige of earlier design. The DN is now completely up to user and I updated the design accordingly. (The validity of the Subject DN *may* be subject to Name Constraints extension in superior certs, but this is not checked). > > """ > Validity > > The default validity could be the default validity used by > ipa-server-install. TODO what is the default duration? > """ > > ATM the default duration is 10 years. > Thanks, updated. > """ > Specify the CA certificate validity. Something human-friendly should be > used, e.g. a duration spec that supports 5y, 365d, etc. TODO is there a > precendent for this sort of duration interpretation in FreeIPA? If so, be > consistent. > """ > > Currently there is (IIRC) only krbmaxticketlife (seconds) and > krbmaxrenewableage (seconds) in the krbtpolicy plugin and krbmaxpwdlife > (days) and krbminpwdlife (hours) in the pwpolicy plugin. If you are going to > invent something generic, it would be nice if it worked for them as well. > I've removed this part of the design for now, as it will not be in initial implementation. > > 4) > > """ > For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which > implements the KeyRetriever interface. It invokes a Python script that > performs the retrieval, reusing existing FreeIPA Custodia client code. > """ > > Will this be distributed with Dogtag or with IPA? > It's shipped in Dogtag. > The Python script bit sounds like an implementation detail rather than an > actual design. Ideally the whole thing would be done in Java, right? > I removed the script from the design page (it had changed, though not dramatically). It is written in Python so that we can reuse the CustodiaClient. > """ > The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key > and shall be executed as pkiuser. > """ > > Could you please use a subdirectory? Like /usr/libexec/pki (if the script is > going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is > going to be distributed with IPA). > What is the rationale - is it a packaging guideline or just common sense? > """ > pkiuser does not have read access to either of these locations, so a new > service principal shall be created for each Dogtag CA instance for the > purpose of authenticating to Custodia and retrieving lightweight CA private > keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its > keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and > mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and > /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively. > """ > > Don't forget to update this paragraph with the new principal name. > Thanks, I updated it. > > 5) > > """ > A CA object for the top-level CA will initially be created, with DN > cn=.,ou=cas,cn=ca,$SUFFIX. > """ > > I would rather not use punctuation for the short name, as it can be easily > overlooked (think logs). (Also it should be '/' if anything, not '.', which > usually means "current".) > > Above you stated that the subject name will be derived from the short name > of the sub-CA. The top-level CA has subject name of the form "CN=Certificate > Authority,$SUBJECT_BASE", so its short name should be "Certificate > Authority". > This section was also part of the old design. The entry for the host authority has ``ipaUniqueId=...`` as rightmost RDN, like other CAs. The cn is ``host-authority``. Subject DN is no longer derived from cn. > > 6) > > """ > ipa ca-del > > Delete the given certificate authority. This will remove knowledge of the CA > from the FreeIPA directory but will not delete the sub-CA from Dogtag. > Dogtag will still know about the CA and the certificates it issued, be able > to act at a CRL / OCSP authority for it, etc. > """ > > What is the use case for this? Will the certificates issued by the sub-CA > still be valid after delete or not? Will the sub-CA certificate be > explicitly distrusted on delete or not? > > IMO it should be possible to delete only a leaf sub-CA, i.e. anything but > the top-level CA in the current design. > > """ > ipa cert-find [shortname] > > shortname > Optional positional parameter to specify a sub-CA to use (omit to > specify the top-level CA). The special shortname * is used to search in all > CAs. > """ > > This should be "ipa cert-find [--ca=]". At some point, cert-find > should be fixed to be consistent with every other -find command and have an > optional 'criteria' positional argument, and there can't be two optional > positional arguments, as it creates an ambiguity. > > I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather > than a magic value for an all-CA search. Magic value might work for > cert-find alone, but you are creating a precedent for the whole framework > here. > Design updated. No position arg anymore. No special arg for "all CAs" - it is implied unless one of ``--issuer=DN`` or ``--ca=NAME`` is given. > > """ > ipa cert-show [shortname] > > shortname > Optional positional parameter to specify a sub-CA (omit to specify the > top-level CA). > --chain > Request the certificate chain (when saving via --out , PEM format > is used; this is the format uesd for the end-entity certificate). > """ > > This should be "ipa cert-show [--ca=]", for consistency with > cert-find, see above. > Actually, we do not (at the moment) need a CA argument, because serial numbers are unique in the whole Dogtag instance. I have removed the argument but if it makes a comeback in future, it will be in the form you recommend. > IMO it would make sense to add --chain to cert-request as well, it should be > useful for certmonger. > > > 7) > > How is a certificate going to be requested from a specific sub-CA using the > getcert command? > I added a preliminary design; add a new certmonger property and corresponding getcert-request(1) option for specifying the target CA. http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA Alternative approaches involve overloading an existing property (e.g. profile) to optionally carry both profile and CA. The overloading could be handled in Certmonger or in FreeIPA. Either way is feasible - both are nasty hacks! - but it is worth mentioning the alternatives. Cheers, Fraser From mbasti at redhat.com Tue May 10 10:48:10 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 12:48:10 +0200 Subject: [Freeipa-devel] [PATCHES] 0786-0788 More Python 3 fixes In-Reply-To: <572C9798.5030009@redhat.com> References: <572C9798.5030009@redhat.com> Message-ID: <7282e0c5-342a-39ea-7b82-167414f984a0@redhat.com> On 06.05.2016 15:09, Petr Viktorin wrote: > Hi, > With these patches, xmlrpc_tests pass for me (except those that fail on > py2, and, if python3-ipaserver is installed, some in permission that use > ldap2 plugin). > > > > > ACK master: * a9a13530988c616b331545ea02f539d39df64e27 Fix remaining relative import and enable Pylint check * 5dbb0f6fec59defd795dd501b67740a79616e86b ipalib.cli: Improve reporting of binary values in the CLI * 7d4d819b90f23cffbe437566818e29c394800b9e test_cert_plugin: Encode 'certificate' for comparison with 'usercertificate' ipa-4-3: * 2c5b29fe9247ee4b96c63406499ea40ed8e968cf Fix remaining relative import and enable Pylint check * 39132fd1f3a9798957e8c96529bc235ed14c5db3 ipalib.cli: Improve reporting of binary values in the CLI * 0ebbb48dc4cf0b9df78363f6a683c388634c595f test_cert_plugin: Encode 'certificate' for comparison with 'usercertificate' -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 10 11:09:31 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 13:09:31 +0200 Subject: [Freeipa-devel] [PATCH 0111] Remove unused file install/share/fedora-ds.init.patc Message-ID: <13d915b1-bc76-cbd2-f3f2-34521e607171@redhat.com> Hello, Remove unused file install/share/fedora-ds.init.patch -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0111-Remove-unused-file-install-share-fedora-ds.init.patc.patch Type: text/x-patch Size: 1039 bytes Desc: not available URL: From mbasti at redhat.com Tue May 10 11:14:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 13:14:40 +0200 Subject: [Freeipa-devel] [PATCH] Replaced find_hostname with api.env.host In-Reply-To: <572C1D0F.5010704@redhat.com> References: <572C1D0F.5010704@redhat.com> Message-ID: <9f5ae4f4-5e7c-9405-c925-0bb79da1b911@redhat.com> On 06.05.2016 06:26, Abhijeet Kasurde wrote: > Hi All, > > Please review this patch. > > Thanks for mbasti for helping me. > > Thanks, > Abhijeet Kasurde > > ACK Pushed to master: 865935739a37bb7c098f8379871648e776e582f2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 11:47:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 13:47:33 +0200 Subject: [Freeipa-devel] [PATCH 0068] Use ipareplica-ca-install.log instead of ipaserver-ca-install.log In-Reply-To: References: Message-ID: <72988386-d83e-da34-a2ed-65b5eabfbdaa@redhat.com> On 03.05.2016 15:41, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5727. Per comment #7, > this removes ipaserver-ca-install.log and uses ipareplica-ca-install.log. > > Thanks, > > Gabe > > Well, with this patch, ipa-ca-install on ca-less master server will log into ipareplica-ca-install.log what is not right. This difference between master an replica is somehow unfortunate because those servers are equal and it should be logged into ipa-ca-install.log. This is part of other logging tickets that has been postponed I think that all tickets should be resolved together. I suggest to postpone this ticket and fix it together with other logger tickets. Do you agree? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Tue May 10 11:59:57 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 10 May 2016 17:29:57 +0530 Subject: [Freeipa-devel] [PATCH 0015] Added exception handling for mal-formatted XML Parsing In-Reply-To: <8524648f-ff10-6747-07d3-b1ca6bafb13d@redhat.com> References: <57301F9B.6070005@redhat.com> <8524648f-ff10-6747-07d3-b1ca6bafb13d@redhat.com> Message-ID: <5731CD3D.9090306@redhat.com> Hi All, Please find the patch for review. Thanks, Abhijeet Kasurde On 05/10/2016 01:13 PM, Martin Basti wrote: > > > > On 09.05.2016 07:26, Abhijeet Kasurde wrote: >> Hi all, >> >> Please review the patch. >> >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1333755 >> >> Thanks, >> Abhijeet Kasurde >> >> >> > Hello, > > + self.raise_certificate_operation_error('parse', > + detail=e.msg) > > Please use detail=str(e), e.msg is deprecated > > Martin^2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0015-1-Added-exception-handling-for-mal-formatted-XML-Parsin.patch Type: text/x-patch Size: 1825 bytes Desc: not available URL: From redhatrises at gmail.com Tue May 10 12:11:22 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 10 May 2016 06:11:22 -0600 Subject: [Freeipa-devel] [PATCH 0068] Use ipareplica-ca-install.log instead of ipaserver-ca-install.log In-Reply-To: <72988386-d83e-da34-a2ed-65b5eabfbdaa@redhat.com> References: <72988386-d83e-da34-a2ed-65b5eabfbdaa@redhat.com> Message-ID: Yeah. That makes sense. Let's fix it with the other logger tickets. Gabe On Tue, May 10, 2016 at 5:47 AM, Martin Basti wrote: > > > On 03.05.2016 15:41, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5727. Per comment #7, > this removes ipaserver-ca-install.log and uses ipareplica-ca-install.log. > > Thanks, > > Gabe > > > Well, with this patch, ipa-ca-install on ca-less master server will log > into ipareplica-ca-install.log what is not right. This difference between > master an replica is somehow unfortunate because those servers are equal > and it should be logged into ipa-ca-install.log. This is part of other > logging tickets that has been postponed I think that all tickets should be > resolved together. > > I suggest to postpone this ticket and fix it together with other logger > tickets. > > Do you agree? > > Martin^2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue May 10 12:13:07 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 10 May 2016 06:13:07 -0600 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> Message-ID: On Tue, May 10, 2016 at 2:00 AM, Martin Basti wrote: > > > On 04.05.2016 15:14, Gabe Alford wrote: > > On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde < > akasurde at redhat.com> wrote: > >> Hi Gabe, >> >> I am wondering, how are we handling "CalledProcessError" exception ? >> > > I am not sure 100% what you are asking, but from what I understand, the > "CalledProcessError" exception is when a process returns a non-zero exit > status. > However when running 'ipa-nis-manage enable', an exception is never hit > even if portmap is not installed, hence portmap always being enabled. > > So it seems that if the process is not installed, "CalledProcessError" > doesn't catch an error. > > Gabe > > Hello, > > portmap.enable() may raise the "CalledProcessError" in case that systemct > enable failed and we should catch this exception and handle it in the same > way as it is done now. i.e catch that exception and set proper return state. > > Martin^2 > Shouldn't "CalledProcessError" raise an exception in this case? In my testing, it doesn't seem to raise an exception when the service does not even exist on the system. Gabe > > > >> On 05/04/2016 09:17 AM, Gabe Alford wrote: >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5857 >> >> Thanks, >> >> Gabe >> >> >> Thanks, >> Abhijeet Kasurde >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 12:26:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 14:26:58 +0200 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> Message-ID: On 10.05.2016 14:13, Gabe Alford wrote: > On Tue, May 10, 2016 at 2:00 AM, Martin Basti > wrote: > > > > On 04.05.2016 15:14, Gabe Alford wrote: >> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde >> > wrote: >> >> Hi Gabe, >> >> I am wondering, how are we handling "CalledProcessError" >> exception ? >> >> >> I am not sure 100% what you are asking, but from what I >> understand, the "CalledProcessError" exception is when a process >> returns a non-zero exit status. >> However when running 'ipa-nis-manage enable', an exception is >> never hit even if portmap is not installed, hence portmap always >> being enabled. >> >> So it seems that if the process is not installed, >> "CalledProcessError" doesn't catch an error. >> >> Gabe > Hello, > > portmap.enable() may raise the "CalledProcessError" in case that > systemct enable failed and we should catch this exception and > handle it in the same way as it is done now. i.e catch that > exception and set proper return state. > > Martin^2 > > > Shouldn't "CalledProcessError" raise an exception in this case? In my > testing, it doesn't seem to raise an exception when the service does > not even exist on the system. > > Gabe > You are right, there is try-except-pass, so no exception can be raised def __enable(self, instance_name=""): try: ipautil.run([paths.SYSTEMCTL,"enable", self.service_instance(instance_name)]) except ipautil.CalledProcessError: pass Martin > > >> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/5857 >>> >>> Thanks, >>> >>> Gabe >>> >>> >> Thanks, >> Abhijeet Kasurde >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 10 12:33:15 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 14:33:15 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: Message-ID: On 6.5.2016 10:20, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/2008 > > Patches attached. > > > freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch > > > From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Wed, 4 May 2016 17:33:52 +0200 > Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges > > DNS privileges are important for handling DNS locations which can be > created without DNS servers in IPA topology. We will also need this > privileges presented for future feature 'External DNS support' Seems reasonable, ACK. > freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch > > > From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Thu, 5 May 2016 11:12:00 +0200 > Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses > > http://www.freeipa.org/page/V4/DNS_Location_Mechanism > > https://fedorahosted.org/freeipa/ticket/2008 > --- > install/share/60ipadns.ldif | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif > index e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce 100644 > --- a/install/share/60ipadns.ldif > +++ b/install/share/60ipadns.ldif > @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME 'idnsSecKeyRevoke' DESC 'DNSKE > attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) > attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) > attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) > +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) > +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) > objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ DHCIDRecord $ HIPRecord $ SPFRecord ) ) > objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ idnsSecInlineSigning $ nSEC3PARAMRecord ) ) > objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ idnsPersistentSearch ) ) > objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) > objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) MAY ( idnsForwarders $ idnsForwardPolicy ) ) > objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) > +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( description ) X-ORIGIN 'IPA v4.4' ) Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be any other object class on the location object (at least not in the beginning). > +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) Conditional ACK if you fix ipaLocationObject. > freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch > > > From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Thu, 5 May 2016 11:13:07 +0200 > Subject: [PATCH 3/4] DNS Locations: Add location-* commands > > Added location-{add,mod,del,find,show} commands. Command are just > prototypes and does not provide any information about server (will be > done later) > > http://www.freeipa.org/page/V4/DNS_Location_Mechanism > > https://fedorahosted.org/freeipa/ticket/2008 > --- > ACI.txt | 8 ++ > API.txt | 59 ++++++++++++++ > VERSION | 4 +- > install/share/bootstrap-template.ldif | 6 ++ > install/updates/37-locations.update | 4 + > install/updates/Makefile.am | 1 + > ipalib/constants.py | 1 + > ipalib/plugins/location.py | 142 +++++++++++++++++++++++++++++++++- > 8 files changed, 222 insertions(+), 3 deletions(-) [...] > diff --git a/VERSION b/VERSION > index aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 100644 > --- a/VERSION > +++ b/VERSION > @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 > # # > ######################################################## > IPA_API_VERSION_MAJOR=2 > -IPA_API_VERSION_MINOR=165 > -# Last change: mbasti - limit ipamaxusernamelength value to 255 > +IPA_API_VERSION_MINOR=166 > +# Last change: mbasti - location-* commands Needs rebase. > diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif > index 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 100644 > --- a/install/share/bootstrap-template.ldif > +++ b/install/share/bootstrap-template.ldif > @@ -119,6 +119,12 @@ objectClass: nsContainer > objectClass: top > cn: etc > > +dn: cn=locations,cn=etc,$SUFFIX > +changetype: add > +objectClass: nsContainer > +objectClass: top > +cn: locations > + > dn: cn=sysaccounts,cn=etc,$SUFFIX > changetype: add > objectClass: nsContainer > diff --git a/install/updates/37-locations.update b/install/updates/37-locations.update > index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 100644 > --- a/install/updates/37-locations.update > +++ b/install/updates/37-locations.update > @@ -0,0 +1,4 @@ > +dn: cn=locations,cn=etc,$SUFFIX > +default: objectClass: nsContainer > +default: objectClass: top > +default: cn: locations Ok. [...] > diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py > index 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb 100644 > --- a/ipalib/plugins/location.py > +++ b/ipalib/plugins/location.py [...] > +__doc__ = _(""" > +IPA locations > +""") + _(""" > +Manipulate with DNS locations IMHO "with" should be omited. [...] > + at register() > +class location(LDAPObject): > + """ > + IPA locations > + """ [...] > + permission_filter_objectclasses = ['ipaLocationObject'] > + managed_permissions = { > + 'System: Read IPA Locations': { > + 'ipapermright': {'read', 'search', 'compare'}, > + 'ipapermdefaultattr': { > + 'objectclass', 'idnsname', 'description', > + }, > + 'default_privileges': {'DNS Administrators'}, > + }, > + 'System: Add IPA Locations': { > + 'ipapermright': {'add'}, > + 'default_privileges': {'DNS Administrators'}, > + }, > + 'System: Remove IPA Locations': { > + 'ipapermright': {'delete'}, > + 'default_privileges': {'DNS Administrators'}, > + }, > + 'System: Modify IPA Locations': { > + 'ipapermright': {'write'}, > + 'ipapermdefaultattr': { > + 'description', > + }, > + 'default_privileges': {'DNS Administrators'}, > + }, > + } Sounds reasonable. ACI does not allow renaming location but IMHO this is okay. Less renames we support the better. > + > + takes_params = ( > + DNSNameParam( > + 'idnsname', > + cli_name='name', > + primary_key=True, > + label=_('Location name'), > + doc=_('IPA location name'), > + # dns name must be relative, we will put it into middle of > + # location domain name for location records > + only_relative=True, > + ), Okay. We need to make sure that relative names with multiple labels work - but this should automagically work as long as we are handling DNS names using proper data types (not as strings). > + Str( > + 'description?', > + label=_('Description'), > + doc=_('IPA Location description'), > + ), After discussion with Honza we will keep description as single-value in the IPA framework and ignore that description attribute is multi-value in LDAP. This is done for consitency with mistakes from the past. [...] > + at register() > +class location_mod(LDAPUpdate): > + __doc__ = _('Modify information about an IPA location .') This should say 'Modify description' because nothing else can be modified. More specific text would hopefully stop some people from looking for rename options. > freeipa-mbasti-0476-DNS-Locations-API-tests.patch ACK. Nice patch set. If you fix the nitpicks above feel free to push it right away. -- Petr Spacek @ Red Hat From redhatrises at gmail.com Tue May 10 12:42:22 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 10 May 2016 06:42:22 -0600 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> Message-ID: On Tue, May 10, 2016 at 6:26 AM, Martin Basti wrote: > > > On 10.05.2016 14:13, Gabe Alford wrote: > > On Tue, May 10, 2016 at 2:00 AM, Martin Basti wrote: > >> >> >> On 04.05.2016 15:14, Gabe Alford wrote: >> >> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde < >> akasurde at redhat.com> wrote: >> >>> Hi Gabe, >>> >>> I am wondering, how are we handling "CalledProcessError" exception ? >>> >> >> I am not sure 100% what you are asking, but from what I understand, the >> "CalledProcessError" exception is when a process returns a non-zero exit >> status. >> However when running 'ipa-nis-manage enable', an exception is never hit >> even if portmap is not installed, hence portmap always being enabled. >> >> So it seems that if the process is not installed, "CalledProcessError" >> doesn't catch an error. >> >> Gabe >> >> Hello, >> >> portmap.enable() may raise the "CalledProcessError" in case that systemct >> enable failed and we should catch this exception and handle it in the same >> way as it is done now. i.e catch that exception and set proper return state. >> >> Martin^2 >> > > Shouldn't "CalledProcessError" raise an exception in this case? In my > testing, it doesn't seem to raise an exception when the service does not > even exist on the system. > > Gabe > > You are right, there is try-except-pass, so no exception can be raised > > def __enable(self, instance_name=""): > try: > ipautil.run([paths.SYSTEMCTL, "enable", > self.service_instance(instance_name)]) > except ipautil.CalledProcessError: > pass > > > Martin > It is also the case for disable(), mask(), unmask(), etc. Should we update the exception in __enable() or is there a reason that it just passes at exception? Gabe > > >> >> >> >>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>> >>> Hello, >>> >>> Fix for >>> https://fedorahosted.org/freeipa/ticket/5857 >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> Thanks, >>> Abhijeet Kasurde >>> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 12:44:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 14:44:23 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: Message-ID: On 10.05.2016 14:33, Petr Spacek wrote: > On 6.5.2016 10:20, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/2008 >> >> Patches attached. >> >> >> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >> >> >> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Wed, 4 May 2016 17:33:52 +0200 >> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >> >> DNS privileges are important for handling DNS locations which can be >> created without DNS servers in IPA topology. We will also need this >> privileges presented for future feature 'External DNS support' > Seems reasonable, ACK. > > >> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >> >> >> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Thu, 5 May 2016 11:12:00 +0200 >> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >> >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >> >> https://fedorahosted.org/freeipa/ticket/2008 >> --- >> install/share/60ipadns.ldif | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >> index e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce 100644 >> --- a/install/share/60ipadns.ldif >> +++ b/install/share/60ipadns.ldif >> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME 'idnsSecKeyRevoke' DESC 'DNSKE >> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ DHCIDRecord $ HIPRecord $ SPFRecord ) ) >> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ idnsPersistentSearch ) ) >> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) MAY ( idnsForwarders $ idnsForwardPolicy ) ) >> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( description ) X-ORIGIN 'IPA v4.4' ) > Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be > any other object class on the location object (at least not in the beginning). > >> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) > Conditional ACK if you fix ipaLocationObject. > > >> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >> >> >> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Thu, 5 May 2016 11:13:07 +0200 >> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >> >> Added location-{add,mod,del,find,show} commands. Command are just >> prototypes and does not provide any information about server (will be >> done later) >> >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >> >> https://fedorahosted.org/freeipa/ticket/2008 >> --- >> ACI.txt | 8 ++ >> API.txt | 59 ++++++++++++++ >> VERSION | 4 +- >> install/share/bootstrap-template.ldif | 6 ++ >> install/updates/37-locations.update | 4 + >> install/updates/Makefile.am | 1 + >> ipalib/constants.py | 1 + >> ipalib/plugins/location.py | 142 +++++++++++++++++++++++++++++++++- >> 8 files changed, 222 insertions(+), 3 deletions(-) > [...] > >> diff --git a/VERSION b/VERSION >> index aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 100644 >> --- a/VERSION >> +++ b/VERSION >> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >> # # >> ######################################################## >> IPA_API_VERSION_MAJOR=2 >> -IPA_API_VERSION_MINOR=165 >> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >> +IPA_API_VERSION_MINOR=166 >> +# Last change: mbasti - location-* commands > Needs rebase. > > >> diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif >> index 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 100644 >> --- a/install/share/bootstrap-template.ldif >> +++ b/install/share/bootstrap-template.ldif >> @@ -119,6 +119,12 @@ objectClass: nsContainer >> objectClass: top >> cn: etc >> >> +dn: cn=locations,cn=etc,$SUFFIX >> +changetype: add >> +objectClass: nsContainer >> +objectClass: top >> +cn: locations >> + >> dn: cn=sysaccounts,cn=etc,$SUFFIX >> changetype: add >> objectClass: nsContainer >> diff --git a/install/updates/37-locations.update b/install/updates/37-locations.update >> index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 100644 >> --- a/install/updates/37-locations.update >> +++ b/install/updates/37-locations.update >> @@ -0,0 +1,4 @@ >> +dn: cn=locations,cn=etc,$SUFFIX >> +default: objectClass: nsContainer >> +default: objectClass: top >> +default: cn: locations > Ok. > > [...] > >> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >> index 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb 100644 >> --- a/ipalib/plugins/location.py >> +++ b/ipalib/plugins/location.py > [...] >> +__doc__ = _(""" >> +IPA locations >> +""") + _(""" >> +Manipulate with DNS locations > IMHO "with" should be omited. [...] > > >> + at register() >> +class location(LDAPObject): >> + """ >> + IPA locations >> + """ > [...] > >> + permission_filter_objectclasses = ['ipaLocationObject'] >> + managed_permissions = { >> + 'System: Read IPA Locations': { >> + 'ipapermright': {'read', 'search', 'compare'}, >> + 'ipapermdefaultattr': { >> + 'objectclass', 'idnsname', 'description', >> + }, >> + 'default_privileges': {'DNS Administrators'}, >> + }, >> + 'System: Add IPA Locations': { >> + 'ipapermright': {'add'}, >> + 'default_privileges': {'DNS Administrators'}, >> + }, >> + 'System: Remove IPA Locations': { >> + 'ipapermright': {'delete'}, >> + 'default_privileges': {'DNS Administrators'}, >> + }, >> + 'System: Modify IPA Locations': { >> + 'ipapermright': {'write'}, >> + 'ipapermdefaultattr': { >> + 'description', >> + }, >> + 'default_privileges': {'DNS Administrators'}, >> + }, >> + } > Sounds reasonable. ACI does not allow renaming location but IMHO this is okay. > Less renames we support the better. > > >> + >> + takes_params = ( >> + DNSNameParam( >> + 'idnsname', >> + cli_name='name', >> + primary_key=True, >> + label=_('Location name'), >> + doc=_('IPA location name'), >> + # dns name must be relative, we will put it into middle of >> + # location domain name for location records >> + only_relative=True, >> + ), > Okay. We need to make sure that relative names with multiple labels work - but > this should automagically work as long as we are handling DNS names using > proper data types (not as strings). > > >> + Str( >> + 'description?', >> + label=_('Description'), >> + doc=_('IPA Location description'), >> + ), > After discussion with Honza we will keep description as single-value in the > IPA framework and ignore that description attribute is multi-value in LDAP. > This is done for consitency with mistakes from the past. > > [...] > >> + at register() >> +class location_mod(LDAPUpdate): >> + __doc__ = _('Modify information about an IPA location .') > This should say 'Modify description' because nothing else can be modified. > More specific text would hopefully stop some people from looking for rename > options. I disagree, this is general description about the modify command, see privilege-add it is the same as I made. I can see in future that we will forgot to update description of command if we add something new there. Martin^2 > > >> freeipa-mbasti-0476-DNS-Locations-API-tests.patch > ACK. > > > Nice patch set. If you fix the nitpicks above feel free to push it right away. > From mbasti at redhat.com Tue May 10 12:47:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 14:47:22 +0200 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> Message-ID: <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> On 10.05.2016 14:42, Gabe Alford wrote: > On Tue, May 10, 2016 at 6:26 AM, Martin Basti > wrote: > > > > On 10.05.2016 14:13, Gabe Alford wrote: >> On Tue, May 10, 2016 at 2:00 AM, Martin Basti > > wrote: >> >> >> >> On 04.05.2016 15:14, Gabe Alford wrote: >>> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde >>> > wrote: >>> >>> Hi Gabe, >>> >>> I am wondering, how are we handling "CalledProcessError" >>> exception ? >>> >>> >>> I am not sure 100% what you are asking, but from what I >>> understand, the "CalledProcessError" exception is when a >>> process returns a non-zero exit status. >>> However when running 'ipa-nis-manage enable', an exception >>> is never hit even if portmap is not installed, hence portmap >>> always being enabled. >>> >>> So it seems that if the process is not installed, >>> "CalledProcessError" doesn't catch an error. >>> >>> Gabe >> Hello, >> >> portmap.enable() may raise the "CalledProcessError" in case >> that systemct enable failed and we should catch this >> exception and handle it in the same way as it is done now. >> i.e catch that exception and set proper return state. >> >> Martin^2 >> >> >> Shouldn't "CalledProcessError" raise an exception in this case? >> In my testing, it doesn't seem to raise an exception when the >> service does not even exist on the system. >> >> Gabe >> > You are right, there is try-except-pass, so no exception can be raised > > def __enable(self, instance_name=""): > try: > ipautil.run([paths.SYSTEMCTL,"enable", > self.service_instance(instance_name)]) > except ipautil.CalledProcessError: > pass > > > Martin > > > It is also the case for disable(), mask(), unmask(), etc. Should we > update the exception in __enable() or is there a reason that it just > passes at exception? > > Gabe I dont think that we should chnge behavior there, what I'm missing there is proper logging :) If you want you can create ticket for it. Leave try-except-pass there, changing this may affect a lot of places, and there is no time to fix it in 4.4 release. Martin^2 > >> >>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>>> Hello, >>>> >>>> Fix for https://fedorahosted.org/freeipa/ticket/5857 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>>> >>> Thanks, >>> Abhijeet Kasurde >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue May 10 12:50:34 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 10 May 2016 06:50:34 -0600 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> Message-ID: On Tue, May 10, 2016 at 6:47 AM, Martin Basti wrote: > > > On 10.05.2016 14:42, Gabe Alford wrote: > > On Tue, May 10, 2016 at 6:26 AM, Martin Basti wrote: > >> >> >> On 10.05.2016 14:13, Gabe Alford wrote: >> >> On Tue, May 10, 2016 at 2:00 AM, Martin Basti < >> mbasti at redhat.com> wrote: >> >>> >>> >>> On 04.05.2016 15:14, Gabe Alford wrote: >>> >>> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde < >>> akasurde at redhat.com> wrote: >>> >>>> Hi Gabe, >>>> >>>> I am wondering, how are we handling "CalledProcessError" exception ? >>>> >>> >>> I am not sure 100% what you are asking, but from what I understand, the >>> "CalledProcessError" exception is when a process returns a non-zero exit >>> status. >>> However when running 'ipa-nis-manage enable', an exception is never hit >>> even if portmap is not installed, hence portmap always being enabled. >>> >>> So it seems that if the process is not installed, "CalledProcessError" >>> doesn't catch an error. >>> >>> Gabe >>> >>> Hello, >>> >>> portmap.enable() may raise the "CalledProcessError" in case that >>> systemct enable failed and we should catch this exception and handle it in >>> the same way as it is done now. i.e catch that exception and set proper >>> return state. >>> >>> Martin^2 >>> >> >> Shouldn't "CalledProcessError" raise an exception in this case? In my >> testing, it doesn't seem to raise an exception when the service does not >> even exist on the system. >> >> Gabe >> >> You are right, there is try-except-pass, so no exception can be raised >> >> def __enable(self, instance_name=""): >> try: >> ipautil.run([paths.SYSTEMCTL, "enable", >> self.service_instance(instance_name)]) >> except ipautil.CalledProcessError: >> pass >> >> >> Martin >> > > It is also the case for disable(), mask(), unmask(), etc. Should we update > the exception in __enable() or is there a reason that it just passes at > exception? > > Gabe > > > I dont think that we should chnge behavior there, what I'm missing there > is proper logging :) If you want you can create ticket for it. Leave > try-except-pass there, changing this may affect a lot of places, and there > is no time to fix it in 4.4 release. > > Martin^2 > Sounds good. Do you also want to keep the try-except-pass in ipa-nis-manage as well or does my patch suffice? Gabe > > >> >> >>> >>> >>> >>>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>>> >>>> Hello, >>>> >>>> Fix for >>>> https://fedorahosted.org/freeipa/ticket/5857 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>> >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 13:18:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 15:18:42 +0200 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> Message-ID: <55868d8c-4913-50c1-5ae2-5bb969e70c02@redhat.com> On 10.05.2016 14:50, Gabe Alford wrote: > On Tue, May 10, 2016 at 6:47 AM, Martin Basti > wrote: > > > > On 10.05.2016 14:42, Gabe Alford wrote: >> On Tue, May 10, 2016 at 6:26 AM, Martin Basti > > wrote: >> >> >> >> On 10.05.2016 14:13, Gabe Alford wrote: >>> On Tue, May 10, 2016 at 2:00 AM, Martin Basti >>> > wrote: >>> >>> >>> >>> On 04.05.2016 15:14, Gabe Alford wrote: >>>> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde >>>> > wrote: >>>> >>>> Hi Gabe, >>>> >>>> I am wondering, how are we handling >>>> "CalledProcessError" exception ? >>>> >>>> >>>> I am not sure 100% what you are asking, but from what I >>>> understand, the "CalledProcessError" exception is when >>>> a process returns a non-zero exit status. >>>> However when running 'ipa-nis-manage enable', an >>>> exception is never hit even if portmap is not >>>> installed, hence portmap always being enabled. >>>> >>>> So it seems that if the process is not installed, >>>> "CalledProcessError" doesn't catch an error. >>>> >>>> Gabe >>> Hello, >>> >>> portmap.enable() may raise the "CalledProcessError" in >>> case that systemct enable failed and we should catch >>> this exception and handle it in the same way as it is >>> done now. i.e catch that exception and set proper return >>> state. >>> >>> Martin^2 >>> >>> >>> Shouldn't "CalledProcessError" raise an exception in this >>> case? In my testing, it doesn't seem to raise an exception >>> when the service does not even exist on the system. >>> >>> Gabe >>> >> You are right, there is try-except-pass, so no exception can >> be raised >> >> def __enable(self, instance_name=""): >> try: >> ipautil.run([paths.SYSTEMCTL,"enable", >> self.service_instance(instance_name)]) >> except ipautil.CalledProcessError: >> pass >> >> >> Martin >> >> >> It is also the case for disable(), mask(), unmask(), etc. Should >> we update the exception in __enable() or is there a reason that >> it just passes at exception? >> >> Gabe > > I dont think that we should chnge behavior there, what I'm missing > there is proper logging :) If you want you can create ticket for > it. Leave try-except-pass there, changing this may affect a lot of > places, and there is no time to fix it in 4.4 release. > > Martin^2 > > > Sounds good. Do you also want to keep the try-except-pass in > ipa-nis-manage as well or does my patch suffice? > > Gabe I'm fine with your patch if Abhijeet agree, we can push it. Martin^2 >>> >>>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>>>> Hello, >>>>> >>>>> Fix for https://fedorahosted.org/freeipa/ticket/5857 >>>>> >>>>> Thanks, >>>>> >>>>> Gabe >>>>> >>>>> >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 10 13:21:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 15:21:03 +0200 Subject: [Freeipa-devel] [PATCH 0068] Use ipareplica-ca-install.log instead of ipaserver-ca-install.log In-Reply-To: References: <72988386-d83e-da34-a2ed-65b5eabfbdaa@redhat.com> Message-ID: <0b9b836f-fda9-6d0a-2d0c-fb553b1fe45f@redhat.com> Ok, I will update tickets On 10.05.2016 14:11, Gabe Alford wrote: > Yeah. That makes sense. Let's fix it with the other logger tickets. > > Gabe > > On Tue, May 10, 2016 at 5:47 AM, Martin Basti > wrote: > > > > On 03.05.2016 15:41, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5727. Per comment >> #7, this removes ipaserver-ca-install.log and uses >> ipareplica-ca-install.log. >> >> Thanks, >> >> Gabe >> >> > Well, with this patch, ipa-ca-install on ca-less master server > will log into ipareplica-ca-install.log what is not right. This > difference between master an replica is somehow unfortunate > because those servers are equal and it should be logged into > ipa-ca-install.log. This is part of other logging tickets that has > been postponed I think that all tickets should be resolved together. > > I suggest to postpone this ticket and fix it together with other > logger tickets. > > Do you agree? > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 10 13:23:46 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 15:23:46 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: Message-ID: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> On 10.5.2016 14:44, Martin Basti wrote: > > > On 10.05.2016 14:33, Petr Spacek wrote: >> On 6.5.2016 10:20, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/2008 >>> >>> Patches attached. >>> >>> >>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>> >>> >>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Wed, 4 May 2016 17:33:52 +0200 >>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >>> >>> DNS privileges are important for handling DNS locations which can be >>> created without DNS servers in IPA topology. We will also need this >>> privileges presented for future feature 'External DNS support' >> Seems reasonable, ACK. >> >> >>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>> >>> >>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Thu, 5 May 2016 11:12:00 +0200 >>> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >>> >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>> >>> https://fedorahosted.org/freeipa/ticket/2008 >>> --- >>> install/share/60ipadns.ldif | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>> index >>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>> 100644 >>> --- a/install/share/60ipadns.ldif >>> +++ b/install/share/60ipadns.ldif >>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>> 'idnsSecKeyRevoke' DESC 'DNSKE >>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC >>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC >>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match >>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC >>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC >>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns >>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ >>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ >>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord >>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord >>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ >>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ >>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ >>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC >>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ idnsPersistentSearch ) ) >>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top >>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC >>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) >>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC >>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ >>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC >>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( >>> description ) X-ORIGIN 'IPA v4.4' ) >> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be >> any other object class on the location object (at least not in the beginning). >> >>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC >>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >> Conditional ACK if you fix ipaLocationObject. >> >> >>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>> >>> >>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Thu, 5 May 2016 11:13:07 +0200 >>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>> >>> Added location-{add,mod,del,find,show} commands. Command are just >>> prototypes and does not provide any information about server (will be >>> done later) >>> >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>> >>> https://fedorahosted.org/freeipa/ticket/2008 >>> --- >>> ACI.txt | 8 ++ >>> API.txt | 59 ++++++++++++++ >>> VERSION | 4 +- >>> install/share/bootstrap-template.ldif | 6 ++ >>> install/updates/37-locations.update | 4 + >>> install/updates/Makefile.am | 1 + >>> ipalib/constants.py | 1 + >>> ipalib/plugins/location.py | 142 >>> +++++++++++++++++++++++++++++++++- >>> 8 files changed, 222 insertions(+), 3 deletions(-) >> [...] >> >>> diff --git a/VERSION b/VERSION >>> index >>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>> 100644 >>> --- a/VERSION >>> +++ b/VERSION >>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>> # # >>> ######################################################## >>> IPA_API_VERSION_MAJOR=2 >>> -IPA_API_VERSION_MINOR=165 >>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>> +IPA_API_VERSION_MINOR=166 >>> +# Last change: mbasti - location-* commands >> Needs rebase. >> >> >>> diff --git a/install/share/bootstrap-template.ldif >>> b/install/share/bootstrap-template.ldif >>> index >>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>> 100644 >>> --- a/install/share/bootstrap-template.ldif >>> +++ b/install/share/bootstrap-template.ldif >>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>> objectClass: top >>> cn: etc >>> +dn: cn=locations,cn=etc,$SUFFIX >>> +changetype: add >>> +objectClass: nsContainer >>> +objectClass: top >>> +cn: locations >>> + >>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>> changetype: add >>> objectClass: nsContainer >>> diff --git a/install/updates/37-locations.update >>> b/install/updates/37-locations.update >>> index >>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>> 100644 >>> --- a/install/updates/37-locations.update >>> +++ b/install/updates/37-locations.update >>> @@ -0,0 +1,4 @@ >>> +dn: cn=locations,cn=etc,$SUFFIX >>> +default: objectClass: nsContainer >>> +default: objectClass: top >>> +default: cn: locations >> Ok. >> >> [...] >> >>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>> index >>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>> 100644 >>> --- a/ipalib/plugins/location.py >>> +++ b/ipalib/plugins/location.py >> [...] >>> +__doc__ = _(""" >>> +IPA locations >>> +""") + _(""" >>> +Manipulate with DNS locations >> IMHO "with" should be omited. [...] >> >> >>> + at register() >>> +class location(LDAPObject): >>> + """ >>> + IPA locations >>> + """ >> [...] >> >>> + permission_filter_objectclasses = ['ipaLocationObject'] >>> + managed_permissions = { >>> + 'System: Read IPA Locations': { >>> + 'ipapermright': {'read', 'search', 'compare'}, >>> + 'ipapermdefaultattr': { >>> + 'objectclass', 'idnsname', 'description', >>> + }, >>> + 'default_privileges': {'DNS Administrators'}, >>> + }, >>> + 'System: Add IPA Locations': { >>> + 'ipapermright': {'add'}, >>> + 'default_privileges': {'DNS Administrators'}, >>> + }, >>> + 'System: Remove IPA Locations': { >>> + 'ipapermright': {'delete'}, >>> + 'default_privileges': {'DNS Administrators'}, >>> + }, >>> + 'System: Modify IPA Locations': { >>> + 'ipapermright': {'write'}, >>> + 'ipapermdefaultattr': { >>> + 'description', >>> + }, >>> + 'default_privileges': {'DNS Administrators'}, >>> + }, >>> + } >> Sounds reasonable. ACI does not allow renaming location but IMHO this is okay. >> Less renames we support the better. >> >> >>> + >>> + takes_params = ( >>> + DNSNameParam( >>> + 'idnsname', >>> + cli_name='name', >>> + primary_key=True, >>> + label=_('Location name'), >>> + doc=_('IPA location name'), >>> + # dns name must be relative, we will put it into middle of >>> + # location domain name for location records >>> + only_relative=True, >>> + ), >> Okay. We need to make sure that relative names with multiple labels work - but >> this should automagically work as long as we are handling DNS names using >> proper data types (not as strings). >> >> >>> + Str( >>> + 'description?', >>> + label=_('Description'), >>> + doc=_('IPA Location description'), >>> + ), >> After discussion with Honza we will keep description as single-value in the >> IPA framework and ignore that description attribute is multi-value in LDAP. >> This is done for consitency with mistakes from the past. >> >> [...] >> >>> + at register() >>> +class location_mod(LDAPUpdate): >>> + __doc__ = _('Modify information about an IPA location .') >> This should say 'Modify description' because nothing else can be modified. >> More specific text would hopefully stop some people from looking for rename >> options. > > I disagree, this is general description about the modify command, see > privilege-add it is the same as I made. I can see in future that we will > forgot to update description of command if we add something new there. This is really an invalid argument. "We must not touch XYZ because its documentation might become obsolete in future if we forget to update it!" :-) -- Petr^2 Spacek From mbasti at redhat.com Tue May 10 13:26:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 15:26:11 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> Message-ID: <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> On 10.05.2016 15:23, Petr Spacek wrote: > On 10.5.2016 14:44, Martin Basti wrote: >> >> On 10.05.2016 14:33, Petr Spacek wrote: >>> On 6.5.2016 10:20, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/2008 >>>> >>>> Patches attached. >>>> >>>> >>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>> >>>> >>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >>>> >>>> DNS privileges are important for handling DNS locations which can be >>>> created without DNS servers in IPA topology. We will also need this >>>> privileges presented for future feature 'External DNS support' >>> Seems reasonable, ACK. >>> >>> >>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>> >>>> >>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >>>> >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>> >>>> https://fedorahosted.org/freeipa/ticket/2008 >>>> --- >>>> install/share/60ipadns.ldif | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>> index >>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>> 100644 >>>> --- a/install/share/60ipadns.ldif >>>> +++ b/install/share/60ipadns.ldif >>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC >>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC >>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match >>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC >>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC >>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns >>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ >>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ >>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord >>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord >>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ >>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ >>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ >>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC >>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ idnsPersistentSearch ) ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top >>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC >>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) >>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC >>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ >>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC >>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( >>>> description ) X-ORIGIN 'IPA v4.4' ) >>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be >>> any other object class on the location object (at least not in the beginning). >>> >>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC >>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>> Conditional ACK if you fix ipaLocationObject. >>> >>> >>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>> >>>> >>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>> >>>> Added location-{add,mod,del,find,show} commands. Command are just >>>> prototypes and does not provide any information about server (will be >>>> done later) >>>> >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>> >>>> https://fedorahosted.org/freeipa/ticket/2008 >>>> --- >>>> ACI.txt | 8 ++ >>>> API.txt | 59 ++++++++++++++ >>>> VERSION | 4 +- >>>> install/share/bootstrap-template.ldif | 6 ++ >>>> install/updates/37-locations.update | 4 + >>>> install/updates/Makefile.am | 1 + >>>> ipalib/constants.py | 1 + >>>> ipalib/plugins/location.py | 142 >>>> +++++++++++++++++++++++++++++++++- >>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>> [...] >>> >>>> diff --git a/VERSION b/VERSION >>>> index >>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>> 100644 >>>> --- a/VERSION >>>> +++ b/VERSION >>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>> # # >>>> ######################################################## >>>> IPA_API_VERSION_MAJOR=2 >>>> -IPA_API_VERSION_MINOR=165 >>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>> +IPA_API_VERSION_MINOR=166 >>>> +# Last change: mbasti - location-* commands >>> Needs rebase. >>> >>> >>>> diff --git a/install/share/bootstrap-template.ldif >>>> b/install/share/bootstrap-template.ldif >>>> index >>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>> 100644 >>>> --- a/install/share/bootstrap-template.ldif >>>> +++ b/install/share/bootstrap-template.ldif >>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>> objectClass: top >>>> cn: etc >>>> +dn: cn=locations,cn=etc,$SUFFIX >>>> +changetype: add >>>> +objectClass: nsContainer >>>> +objectClass: top >>>> +cn: locations >>>> + >>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>> changetype: add >>>> objectClass: nsContainer >>>> diff --git a/install/updates/37-locations.update >>>> b/install/updates/37-locations.update >>>> index >>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>> 100644 >>>> --- a/install/updates/37-locations.update >>>> +++ b/install/updates/37-locations.update >>>> @@ -0,0 +1,4 @@ >>>> +dn: cn=locations,cn=etc,$SUFFIX >>>> +default: objectClass: nsContainer >>>> +default: objectClass: top >>>> +default: cn: locations >>> Ok. >>> >>> [...] >>> >>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>> index >>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>> 100644 >>>> --- a/ipalib/plugins/location.py >>>> +++ b/ipalib/plugins/location.py >>> [...] >>>> +__doc__ = _(""" >>>> +IPA locations >>>> +""") + _(""" >>>> +Manipulate with DNS locations >>> IMHO "with" should be omited. [...] >>> >>> >>>> + at register() >>>> +class location(LDAPObject): >>>> + """ >>>> + IPA locations >>>> + """ >>> [...] >>> >>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>> + managed_permissions = { >>>> + 'System: Read IPA Locations': { >>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>> + 'ipapermdefaultattr': { >>>> + 'objectclass', 'idnsname', 'description', >>>> + }, >>>> + 'default_privileges': {'DNS Administrators'}, >>>> + }, >>>> + 'System: Add IPA Locations': { >>>> + 'ipapermright': {'add'}, >>>> + 'default_privileges': {'DNS Administrators'}, >>>> + }, >>>> + 'System: Remove IPA Locations': { >>>> + 'ipapermright': {'delete'}, >>>> + 'default_privileges': {'DNS Administrators'}, >>>> + }, >>>> + 'System: Modify IPA Locations': { >>>> + 'ipapermright': {'write'}, >>>> + 'ipapermdefaultattr': { >>>> + 'description', >>>> + }, >>>> + 'default_privileges': {'DNS Administrators'}, >>>> + }, >>>> + } >>> Sounds reasonable. ACI does not allow renaming location but IMHO this is okay. >>> Less renames we support the better. >>> >>> >>>> + >>>> + takes_params = ( >>>> + DNSNameParam( >>>> + 'idnsname', >>>> + cli_name='name', >>>> + primary_key=True, >>>> + label=_('Location name'), >>>> + doc=_('IPA location name'), >>>> + # dns name must be relative, we will put it into middle of >>>> + # location domain name for location records >>>> + only_relative=True, >>>> + ), >>> Okay. We need to make sure that relative names with multiple labels work - but >>> this should automagically work as long as we are handling DNS names using >>> proper data types (not as strings). >>> >>> >>>> + Str( >>>> + 'description?', >>>> + label=_('Description'), >>>> + doc=_('IPA Location description'), >>>> + ), >>> After discussion with Honza we will keep description as single-value in the >>> IPA framework and ignore that description attribute is multi-value in LDAP. >>> This is done for consitency with mistakes from the past. >>> >>> [...] >>> >>>> + at register() >>>> +class location_mod(LDAPUpdate): >>>> + __doc__ = _('Modify information about an IPA location .') >>> This should say 'Modify description' because nothing else can be modified. >>> More specific text would hopefully stop some people from looking for rename >>> options. >> I disagree, this is general description about the modify command, see >> privilege-add it is the same as I made. I can see in future that we will >> forgot to update description of command if we add something new there. > This is really an invalid argument. > > "We must not touch XYZ because its documentation might become obsolete in > future if we forget to update it!" :-) > How about inconsistency with description of older commands? I don't think that command description should describe attributes that are allowed to change. Allowed attributes are shown in --help output Martin From akasurde at redhat.com Tue May 10 13:36:08 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 10 May 2016 19:06:08 +0530 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: <55868d8c-4913-50c1-5ae2-5bb969e70c02@redhat.com> References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> <55868d8c-4913-50c1-5ae2-5bb969e70c02@redhat.com> Message-ID: <5731E3C8.4090309@redhat.com> On 05/10/2016 06:48 PM, Martin Basti wrote: > > > > On 10.05.2016 14:50, Gabe Alford wrote: >> On Tue, May 10, 2016 at 6:47 AM, Martin Basti > > wrote: >> >> >> >> On 10.05.2016 14:42, Gabe Alford wrote: >>> On Tue, May 10, 2016 at 6:26 AM, Martin Basti >>> wrote: >>> >>> >>> >>> On 10.05.2016 14:13, Gabe Alford wrote: >>>> On Tue, May 10, 2016 at 2:00 AM, Martin Basti >>>> wrote: >>>> >>>> >>>> >>>> On 04.05.2016 15:14, Gabe Alford wrote: >>>>> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde >>>>> wrote: >>>>> >>>>> Hi Gabe, >>>>> >>>>> I am wondering, how are we handling >>>>> "CalledProcessError" exception ? >>>>> >>>>> >>>>> I am not sure 100% what you are asking, but from what >>>>> I understand, the "CalledProcessError" exception is >>>>> when a process returns a non-zero exit status. >>>>> However when running 'ipa-nis-manage enable', an >>>>> exception is never hit even if portmap is not >>>>> installed, hence portmap always being enabled. >>>>> >>>>> So it seems that if the process is not installed, >>>>> "CalledProcessError" doesn't catch an error. >>>>> >>>>> Gabe >>>> Hello, >>>> >>>> portmap.enable() may raise the "CalledProcessError" in >>>> case that systemct enable failed and we should catch >>>> this exception and handle it in the same way as it is >>>> done now. i.e catch that exception and set proper >>>> return state. >>>> >>>> Martin^2 >>>> >>>> >>>> Shouldn't "CalledProcessError" raise an exception in this >>>> case? In my testing, it doesn't seem to raise an exception >>>> when the service does not even exist on the system. >>>> >>>> Gabe >>>> >>> You are right, there is try-except-pass, so no exception can >>> be raised >>> >>> def __enable(self, instance_name=""): >>> try: >>> ipautil.run([paths.SYSTEMCTL,"enable", >>> self.service_instance(instance_name)]) >>> except ipautil.CalledProcessError: >>> pass >>> >>> >>> Martin >>> >>> >>> It is also the case for disable(), mask(), unmask(), etc. Should >>> we update the exception in __enable() or is there a reason that >>> it just passes at exception? >>> >>> Gabe >> >> I dont think that we should chnge behavior there, what I'm >> missing there is proper logging :) If you want you can create >> ticket for it. Leave try-except-pass there, changing this may >> affect a lot of places, and there is no time to fix it in 4.4 >> release. >> >> Martin^2 >> >> >> Sounds good. Do you also want to keep the try-except-pass in >> ipa-nis-manage as well or does my patch suffice? >> >> Gabe > > I'm fine with your patch if Abhijeet agree, we can push it. > Martin^2 > ACK. >> >>>> >>>>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>>>>> Hello, >>>>>> >>>>>> Fix for https://fedorahosted.org/freeipa/ticket/5857 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gabe >>>>>> >>>>>> >>>>> Thanks, >>>>> Abhijeet Kasurde >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 10 13:38:29 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 15:38:29 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> Message-ID: <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> On 10.5.2016 15:26, Martin Basti wrote: > > > On 10.05.2016 15:23, Petr Spacek wrote: >> On 10.5.2016 14:44, Martin Basti wrote: >>> >>> On 10.05.2016 14:33, Petr Spacek wrote: >>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>> >>>>> Patches attached. >>>>> >>>>> >>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>> >>>>> >>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >>>>> From: Martin Basti >>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >>>>> >>>>> DNS privileges are important for handling DNS locations which can be >>>>> created without DNS servers in IPA topology. We will also need this >>>>> privileges presented for future feature 'External DNS support' >>>> Seems reasonable, ACK. >>>> >>>> >>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>> >>>>> >>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >>>>> From: Martin Basti >>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >>>>> >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>> --- >>>>> install/share/60ipadns.ldif | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>>> index >>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>> >>>>> 100644 >>>>> --- a/install/share/60ipadns.ldif >>>>> +++ b/install/share/60ipadns.ldif >>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC >>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch >>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC >>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match >>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC >>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC >>>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns >>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ >>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ >>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord >>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord >>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ >>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ >>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ >>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC >>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>> idnsPersistentSearch ) ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top >>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC >>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) >>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC >>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ >>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC >>>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( >>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be >>>> any other object class on the location object (at least not in the >>>> beginning). >>>> >>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC >>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>> Conditional ACK if you fix ipaLocationObject. >>>> >>>> >>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>> >>>>> >>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >>>>> From: Martin Basti >>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>> >>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>> prototypes and does not provide any information about server (will be >>>>> done later) >>>>> >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>> --- >>>>> ACI.txt | 8 ++ >>>>> API.txt | 59 ++++++++++++++ >>>>> VERSION | 4 +- >>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>> install/updates/37-locations.update | 4 + >>>>> install/updates/Makefile.am | 1 + >>>>> ipalib/constants.py | 1 + >>>>> ipalib/plugins/location.py | 142 >>>>> +++++++++++++++++++++++++++++++++- >>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>> [...] >>>> >>>>> diff --git a/VERSION b/VERSION >>>>> index >>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>> >>>>> 100644 >>>>> --- a/VERSION >>>>> +++ b/VERSION >>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>> # # >>>>> ######################################################## >>>>> IPA_API_VERSION_MAJOR=2 >>>>> -IPA_API_VERSION_MINOR=165 >>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>> +IPA_API_VERSION_MINOR=166 >>>>> +# Last change: mbasti - location-* commands >>>> Needs rebase. >>>> >>>> >>>>> diff --git a/install/share/bootstrap-template.ldif >>>>> b/install/share/bootstrap-template.ldif >>>>> index >>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>> >>>>> 100644 >>>>> --- a/install/share/bootstrap-template.ldif >>>>> +++ b/install/share/bootstrap-template.ldif >>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>> objectClass: top >>>>> cn: etc >>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>> +changetype: add >>>>> +objectClass: nsContainer >>>>> +objectClass: top >>>>> +cn: locations >>>>> + >>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>> changetype: add >>>>> objectClass: nsContainer >>>>> diff --git a/install/updates/37-locations.update >>>>> b/install/updates/37-locations.update >>>>> index >>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>> >>>>> 100644 >>>>> --- a/install/updates/37-locations.update >>>>> +++ b/install/updates/37-locations.update >>>>> @@ -0,0 +1,4 @@ >>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>> +default: objectClass: nsContainer >>>>> +default: objectClass: top >>>>> +default: cn: locations >>>> Ok. >>>> >>>> [...] >>>> >>>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>>> index >>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>> >>>>> 100644 >>>>> --- a/ipalib/plugins/location.py >>>>> +++ b/ipalib/plugins/location.py >>>> [...] >>>>> +__doc__ = _(""" >>>>> +IPA locations >>>>> +""") + _(""" >>>>> +Manipulate with DNS locations >>>> IMHO "with" should be omited. [...] >>>> >>>> >>>>> + at register() >>>>> +class location(LDAPObject): >>>>> + """ >>>>> + IPA locations >>>>> + """ >>>> [...] >>>> >>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>> + managed_permissions = { >>>>> + 'System: Read IPA Locations': { >>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>> + 'ipapermdefaultattr': { >>>>> + 'objectclass', 'idnsname', 'description', >>>>> + }, >>>>> + 'default_privileges': {'DNS Administrators'}, >>>>> + }, >>>>> + 'System: Add IPA Locations': { >>>>> + 'ipapermright': {'add'}, >>>>> + 'default_privileges': {'DNS Administrators'}, >>>>> + }, >>>>> + 'System: Remove IPA Locations': { >>>>> + 'ipapermright': {'delete'}, >>>>> + 'default_privileges': {'DNS Administrators'}, >>>>> + }, >>>>> + 'System: Modify IPA Locations': { >>>>> + 'ipapermright': {'write'}, >>>>> + 'ipapermdefaultattr': { >>>>> + 'description', >>>>> + }, >>>>> + 'default_privileges': {'DNS Administrators'}, >>>>> + }, >>>>> + } >>>> Sounds reasonable. ACI does not allow renaming location but IMHO this is >>>> okay. >>>> Less renames we support the better. >>>> >>>> >>>>> + >>>>> + takes_params = ( >>>>> + DNSNameParam( >>>>> + 'idnsname', >>>>> + cli_name='name', >>>>> + primary_key=True, >>>>> + label=_('Location name'), >>>>> + doc=_('IPA location name'), >>>>> + # dns name must be relative, we will put it into middle of >>>>> + # location domain name for location records >>>>> + only_relative=True, >>>>> + ), >>>> Okay. We need to make sure that relative names with multiple labels work - >>>> but >>>> this should automagically work as long as we are handling DNS names using >>>> proper data types (not as strings). >>>> >>>> >>>>> + Str( >>>>> + 'description?', >>>>> + label=_('Description'), >>>>> + doc=_('IPA Location description'), >>>>> + ), >>>> After discussion with Honza we will keep description as single-value in the >>>> IPA framework and ignore that description attribute is multi-value in LDAP. >>>> This is done for consitency with mistakes from the past. >>>> >>>> [...] >>>> >>>>> + at register() >>>>> +class location_mod(LDAPUpdate): >>>>> + __doc__ = _('Modify information about an IPA location .') >>>> This should say 'Modify description' because nothing else can be modified. >>>> More specific text would hopefully stop some people from looking for rename >>>> options. >>> I disagree, this is general description about the modify command, see >>> privilege-add it is the same as I made. I can see in future that we will >>> forgot to update description of command if we add something new there. >> This is really an invalid argument. >> >> "We must not touch XYZ because its documentation might become obsolete in >> future if we forget to update it!" :-) >> > > How about inconsistency with description of older commands? I don't think that > command description should describe attributes that are allowed to change. > Allowed attributes are shown in --help output I do not agree but push whatever variant you like, it costed too much already. -- Petr^2 Spacek From amarecek at redhat.com Tue May 10 14:23:38 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Tue, 10 May 2016 10:23:38 -0400 (EDT) Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <20160421073451.GR18277@dhcp-40-8.bne.redhat.com> References: <57163D29.8030400@redhat.com> <57164967.2020800@redhat.com> <20160421064945.GP18277@dhcp-40-8.bne.redhat.com> <20160421072233.GA24892@redhat.com> <20160421073451.GR18277@dhcp-40-8.bne.redhat.com> Message-ID: <298766626.1249914.1462890218862.JavaMail.zimbra@redhat.com> Greetings! I've received the information from Milan who was UQE reviewer for this design document - ACK on the current version. Have a nice day, - alich - ----- Original Message ----- > From: "Fraser Tweedale" > To: "Alexander Bokovoy" > Cc: "freeipa-devel" > Sent: Thursday, April 21, 2016 9:34:51 AM > Subject: Re: [Freeipa-devel] V4/RFC 2818 review > > On Thu, Apr 21, 2016 at 10:22:33AM +0300, Alexander Bokovoy wrote: > > On Thu, 21 Apr 2016, Fraser Tweedale wrote: > > >On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > > >>Christian Heimes wrote: > > >>>Hi Fraser, > > >>> > > >>>and now to the review of your design doc for RFC 2818-compliant subject > > >>>alternative names in certs, > > >>>http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > >>> > > >>> > > >>>1) RFC 2818 vs. RFC 6125 > > >>> > > >>>First I like to address a more general topic. Your design mentions RFC > > >>>6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > > >>>verification and we should follow the rules in RFC 6125, whenever 2818 > > >>>lacks specification or there is a conflict between both RFCs. I can tell > > >>>you some horror stories from Python's ssl module related to both RFCs. > > >>> > > >>>https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > >>> > > >>>https://tools.ietf.org/html/rfc6125, Representation and Verification of > > >>>Domain-Based Application Service Identity within Internet Public Key > > >>>Infrastructure Using X.509 (PKIX) Certificates in the Context of > > >>>Transport Layer Security (TLS) > > >>> > > >>>As far as I'm familiar with RFC 6125, your proposal doesn't conflict > > >>>with the more modern RFC. It also makes sense to name the design after > > >>>the RFC, which has deprecated CN. I still like to check your design > > >>>against RFC 6125. > > >>> > > >>>Fraser, do you agree? > > >>> > > >>> > > >>>2) SAN validation in ipa cert-request > > >>> > > >>>In the paragraph "ipa cert-request changes" you write that the plugin > > >>>"[...] ensure that one element of the DNS names list matches the > > >>>principal name". Shouldn't the plugin validate *all* DNS names and > > >>>verify that the principal is allowed to request a cert for all fields in > > >>>SAN? > > >> > > >>Are there plans for any other SAN types? IP address or other oddball > > >>types > > >>like MS UPN? > > >> > > >We support almost all of them in Dogtag, and only support a few > > >types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). > > > > > >We should work out what we can do with IP address; I recall it is > > >needed (or wanted) for some cloud/IaaS use cases. > > Yes, some of Openstack code expects IP address in the certificates. > > > > >DirectoryName would be simple to support (just check that it matches > > >DN of target principal). I wonder if there is a use case for it, or > > >for any other SAN types... > > dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT > > Kerberos for host-based principals. id-pkinit-san is also in use for > > mapping of the principal in general. > > > > In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate > > and > > allows to match them by the matching rules -- id-pkinit-san goes to list > > of principals, id-ms-san-upn goes to the list of UPNs which are then > > merged together and can be addressed with keyword in the matching > > rule. > > > > This allows very flexible matching: > > pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM > > pkinit_cert_match = > > &&msScLogin,clientAuth.*DoE.* > > pkinit_cert_match = > > msScLogin,clientAuthdigitalSignature > > > Thank you for the information! > > > > > > > >>> > > >>>3) Should FreeIPA deprecate cert request without SAN or at least warn > > >>>the user? > > >>> > > >>>IMHO it makes sense to deprecate CN only cert requests. > > >> > > >>I'd mark it as deprecated over at least a major release in order to > > >>handle > > >>older versions that may still make requests without a SAN. > > >> > > >We have to be careful here. CN is depreated for DNS name checking > > >in HTTP (or other network protocols using TLS). Fine - but there > > >could be other certificate use cases that require CN, e.g. user > > >certs where Subject DN corresponds to a directory name. > > Yes. pkinit_cert_match's rule is using Subject DN for checks. > > > > > > >We can deprecate it and eventually reject requests that include CN - > > >but only for service cert profile(s). (This would require a new > > >profile component designed for this purpose). > > Please do not do it. There are known uses for it at least with Kerberos. > > Of course, most of them are rather for user certificates but in reality > > Kerberos does not require you to have service principals always as DNS > > names. > > > There is the option of implementing the component that prohibits CN. > I was by no means suggesting it should be used for all profiles. > Customers can use it on a custom profile if they want. We could use > it on the default service cert profile if we want. > > 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 > From mbasti at redhat.com Tue May 10 14:31:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 16:31:36 +0200 Subject: [Freeipa-devel] [PATCH 0069] ipa-nis-manage enable: change service name from 'portmap' to 'rpcbind' In-Reply-To: <5731E3C8.4090309@redhat.com> References: <57298605.60203@redhat.com> <450c6d59-7b2c-1620-7cf9-bfd7a1ff7cd9@redhat.com> <07b75ea3-323c-dbd0-bf1e-875d17cb66ff@redhat.com> <55868d8c-4913-50c1-5ae2-5bb969e70c02@redhat.com> <5731E3C8.4090309@redhat.com> Message-ID: <67a4b7aa-0566-9f50-79c9-ef714011855f@redhat.com> On 10.05.2016 15:36, Abhijeet Kasurde wrote: > > > On 05/10/2016 06:48 PM, Martin Basti wrote: >> >> >> >> On 10.05.2016 14:50, Gabe Alford wrote: >>> On Tue, May 10, 2016 at 6:47 AM, Martin Basti wrote: >>> >>> >>> >>> On 10.05.2016 14:42, Gabe Alford wrote: >>>> On Tue, May 10, 2016 at 6:26 AM, Martin Basti >>>> wrote: >>>> >>>> >>>> >>>> On 10.05.2016 14:13, Gabe Alford wrote: >>>>> On Tue, May 10, 2016 at 2:00 AM, Martin Basti >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 04.05.2016 15:14, Gabe Alford wrote: >>>>>> On Tue, May 3, 2016 at 11:17 PM, Abhijeet Kasurde >>>>>> wrote: >>>>>> >>>>>> Hi Gabe, >>>>>> >>>>>> I am wondering, how are we handling >>>>>> "CalledProcessError" exception ? >>>>>> >>>>>> >>>>>> I am not sure 100% what you are asking, but from what >>>>>> I understand, the "CalledProcessError" exception is >>>>>> when a process returns a non-zero exit status. >>>>>> However when running 'ipa-nis-manage enable', an >>>>>> exception is never hit even if portmap is not >>>>>> installed, hence portmap always being enabled. >>>>>> >>>>>> So it seems that if the process is not installed, >>>>>> "CalledProcessError" doesn't catch an error. >>>>>> >>>>>> Gabe >>>>> Hello, >>>>> >>>>> portmap.enable() may raise the "CalledProcessError" in >>>>> case that systemct enable failed and we should catch >>>>> this exception and handle it in the same way as it is >>>>> done now. i.e catch that exception and set proper >>>>> return state. >>>>> >>>>> Martin^2 >>>>> >>>>> >>>>> Shouldn't "CalledProcessError" raise an exception in this >>>>> case? In my testing, it doesn't seem to raise an exception >>>>> when the service does not even exist on the system. >>>>> >>>>> Gabe >>>>> >>>> You are right, there is try-except-pass, so no exception >>>> can be raised >>>> >>>> def __enable(self, instance_name=""): >>>> try: >>>> ipautil.run([paths.SYSTEMCTL,"enable", >>>> self.service_instance(instance_name)]) >>>> except ipautil.CalledProcessError: >>>> pass >>>> >>>> >>>> Martin >>>> >>>> >>>> It is also the case for disable(), mask(), unmask(), etc. >>>> Should we update the exception in __enable() or is there a >>>> reason that it just passes at exception? >>>> >>>> Gabe >>> >>> I dont think that we should chnge behavior there, what I'm >>> missing there is proper logging :) If you want you can create >>> ticket for it. Leave try-except-pass there, changing this may >>> affect a lot of places, and there is no time to fix it in 4.4 >>> release. >>> >>> Martin^2 >>> >>> >>> Sounds good. Do you also want to keep the try-except-pass in >>> ipa-nis-manage as well or does my patch suffice? >>> >>> Gabe >> >> I'm fine with your patch if Abhijeet agree, we can push it. >> Martin^2 >> > ACK. Pushed to master: bede6c282e6d321c348dc2d33c6d1f9c14093a57 >>> >>>>> >>>>>> On 05/04/2016 09:17 AM, Gabe Alford wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/5857 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gabe >>>>>>> >>>>>>> >>>>>> Thanks, >>>>>> Abhijeet Kasurde >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Tue May 10 14:52:47 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 10 May 2016 16:52:47 +0200 Subject: [Freeipa-devel] [PATCH] 0033 webui: Mention SAN names in 'Issue new certificate' Message-ID: Hi all, please review the patch for webUI which adds SAN names into 'Issue new certificate' dialog. The SAN names are mentioned only in dialogs for requesting for host and service certificate, according to the design page: http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance . I'm not sure whether this change provides enough information. If you think that we should add more information to these dialogs or even extend also dialog on Authentication -> Certificates page, just let me know. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0033-Extend-the-certificate-request-dialog.patch Type: text/x-patch Size: 5533 bytes Desc: not available URL: From ofayans at redhat.com Tue May 10 15:08:01 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 10 May 2016 17:08:01 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <57173F56.5020308@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> <5715F6B5.3070003@redhat.com> <57173F56.5020308@redhat.com> Message-ID: <5731F951.1020700@redhat.com> Hi David, After quite a while and some more struggles here comes the updated version of the patch together with other patches fixing things in ipatests/test_integration/tasks.py Server and replica installation was refactored in a way to utilize the code from tasks.py as much as it is possible The full set of necessary patches is attached On 04/20/2016 10:35 AM, David Kupka wrote: > On 19/04/16 11:13, Oleg Fayans wrote: >> OK, that one, though passing lint, did not actually work. I gave up my >> attempts to define method decorators inside the class. Now it passes >> lint AND works:) >> > > Hi Oleg! > > 1) Current commit message is useless. Please use it to describe what is > the point of the patch. > > 2) $ git show -U0 | pep8 --diff > ./ipatests/test_integration/test_caless.py:66:1: E302 expected 2 blank > lines, found 1 > ./ipatests/test_integration/test_caless.py:74:1: E302 expected 2 blank > lines, found 1 > ./ipatests/test_integration/test_caless.py:820:5: E303 too many blank > lines (2) > ./ipatests/test_integration/test_caless.py:825:80: E501 line too long > (80 > 79 characters) > ./ipatests/test_integration/test_caless.py:1035:44: E225 missing > whitespace around operator > > > 3) Isn't there a way to do this with pytest's fixtures? > >> +def server_install_teardown(func): >> + def wrapped(*args): >> + try: >> + func(*args) >> + finally: >> + args[0].uninstall_server() >> + return wrapped >> + >> +def replica_install_teardown(func): >> + def wrapped(*args): >> + try: >> + func(*args) >> + finally: >> + # Uninstall replica >> + replica = args[0].replicas[0] >> + tasks.kinit_admin(args[0].master) >> + args[0].uninstall_server(replica) >> + args[0].master.run_command(['ipa-replica-manage', 'del', >> + replica.hostname, '--force'], >> + raiseonerr=False) >> + args[0].master.run_command(['ipa', 'host-del', >> + replica.hostname], >> + raiseonerr=False) >> + return wrapped >> + There is a standard pytest method called 'method_teardown', that is indent to be executed after each test method, but with our setup it does not work. > > 4) Is it necessary to create the $TEST_DIR in the test? Isn't it created > by the framework? > >> + host.transport.mkdir_recursive(host.config.test_dir) > Removed. > > 5) I don't think the comment match the code. > >> >> + # Remove CA cert in /etc/pki/nssdb, in case of failed >> (un)install >> + for host in cls.get_all_hosts(): >> + cls.uninstall_server(host) >> + >> super(CALessBase, cls).uninstall(mh) > Not actual anymore > > 6) No! Create list with one element, iterate that list and append every > item to the other list. Maybe there's better way (Hint: append). > I've seen this on multiple places. > >> if unattended: >> args.extend(['-U']) Agreed > > 7) Why don't you (extend and) use > ipatests.test_integaration.tasks.(un)install_{master,replica}? > This could be done pretty much all over the code. > >> host.run_command(['ipa-server-install', '--uninstall', '-U']) > > 8) Use ipaplatform.paths for certutil and other binaries. If the binary > is not there feel free to add it. > I've seen this on multiple places. > >> + host.run_command(['certutil', '-d', paths.NSS_DB_DIR, '-D', >> + '-n', 'External CA cert'], >> + raiseonerr=False) >> + # A workaround forhttps://fedorahosted.org/freeipa/ticket/4639 >> + result = host.run_command(['certutil', '-L', '-d', >> + paths.HTTPD_ALIAS_DIR]) >> + for rawcert in result.stdout_text.split('\n')[4: -1]: >> + cert = rawcert.split(' ')[0] >> + host.run_command(['certutil', '-D', '-d', >> paths.HTTPD_ALIAS_DIR, >> + '-n', cert]) >> Done > > 9) certmonger is system service. You can check if is is .enabled() and > .running(). And IIUC the comment is negation of what the code does. > >> >> # Verify certmonger was not started >> result = host.run_command(['getcert', 'list'], >> raiseonerr=False) >> - assert result > 0 >> - assert ('Please verify that the certmonger service has >> been ' >> - 'started.' in result.stdout_text), >> result.stdout_text >> + assert result.returncode == 0 > > 10) What is the point of calling uninstall_server() when it will be > called in the finally block of server_install_teardown anyway? > >> + @server_install_teardown >> def test_revoked_http(self): >> "IPA server install with revoked HTTP certificate" >> >> if result.returncode == 0: >> + self.uninstall_server() >> raise nose.SkipTest( >> "Known CA-less installation defect, see " >> +"https://fedorahosted.org/freeipa/ticket/4270") >> >> assert result.returncode > 0 >> Removed > > Nitpick) Do not mix fixing typos/grammar/spelling/style with functional > changes. > >> - def test_incorect_http_pin(self): >> + @pytest.mark.xfail(reason='freeipa ticket 5378') >> + def test_incorrect_http_pin(self): >> "Install new HTTP certificate with incorrect PKCS#12 password" Removed > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0013.1-Updated-the-script-creating-test-certificate-chains.patch Type: text/x-patch Size: 2642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.6-Fixed-numerous-errors-in-ca-less-tests.patch Type: text/x-patch Size: 47033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0039-Updated-generic-installation-methods-for-ca-less-tests.patch Type: text/x-patch Size: 6971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0040-Added-cleaning-of-etc-httpd-alias-upon-server-uninstall.patch Type: text/x-patch Size: 1308 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0041-Fixed-method-failures-during-second-call-for-the-method.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From mbasti at redhat.com Tue May 10 15:33:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 May 2016 17:33:16 +0200 Subject: [Freeipa-devel] [PATCH 0030] fix clean-dangling-ruv in topologies with only one CA In-Reply-To: <5723560C.7000804@redhat.com> References: <5723560C.7000804@redhat.com> Message-ID: On 29.04.2016 14:39, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/5840 > > Please review the attached patch. > > ACK Pushed to: master: 7098d98100d61f9ed2efc6d4db635c24f9786040 ipa-4-3: 040e9a12b0a7c9f73b899ad2b0df24ae27957417 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue May 10 15:50:38 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 10 May 2016 17:50:38 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: References: <5729E929.6010307@redhat.com> Message-ID: <5732034E.5080405@redhat.com> On 05/05/2016 03:44 PM, Petr Vobornik wrote: > On 05/04/2016 02:20 PM, thierry bordaz wrote: >> Hello, >> >> I have been doing some tests/measures using >> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >> The tool creates a set of typical users/hosts/groups... to import with a >> ldapadd. >> >> I wrote down some finding in >> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >> I still have to do some cleanup around the performance but the basic of a >> possible improvement is to do provisioning in several steps (disabling >> plugins, provisioning, enabling plugin, running fixup tasks). >> >> Before going further in the design I wanted to share those ideas and know if >> it raise any concern. >> >> thanks >> thierry >> > Hi Thierry, > > Thanks for the analysis. Very nice. > > Knowing this will help us suggesting workarounds also for old releases. > > Couple questions: > > Have you tested retrCL disabled with memberOf enabled. It seems that it > would eliminate 550K adds and 0.8M searches. What would be the time > improvement? > > Do you know what is the time when memberof is enabled but slapi-nis and > retroCL are disabled? The culprit of the performance issue is very likely related to SRCH (internal) triggered by memberof. If retroCL is disabled and memberof enabled, #SRCH is 13.8M. If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is 14.8 When all of them are enabled the #SRCH is 15M. You are right if retroCL is disabled the #ADD drops but it has no significant effect on the duration. Regarding the duration of the provisioning, values are not really stable as performance of VM fluctuates. But as soon as memberof is enabled the provisioning lasts > 4hours where the same provisioning lasts 6mins as soon as memberof is disabled. I need to confirm the average time for internal searches but assuming 1ms per SRCH it consumes >90% of the provisioning. > > From the text it was not clear to me, if you find or investigate > possible improvements in memberof plugin which would improve the > performance without stopping and starting DS. From pspacek at redhat.com Tue May 10 16:56:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 May 2016 18:56:51 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> Message-ID: <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> On 10.5.2016 15:38, Petr Spacek wrote: > On 10.5.2016 15:26, Martin Basti wrote: >> >> >> On 10.05.2016 15:23, Petr Spacek wrote: >>> On 10.5.2016 14:44, Martin Basti wrote: >>>> >>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>> >>>>>> Patches attached. >>>>>> >>>>>> >>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>> >>>>>> >>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Basti >>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >>>>>> >>>>>> DNS privileges are important for handling DNS locations which can be >>>>>> created without DNS servers in IPA topology. We will also need this >>>>>> privileges presented for future feature 'External DNS support' >>>>> Seems reasonable, ACK. >>>>> >>>>> >>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>> >>>>>> >>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Basti >>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >>>>>> >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>> --- >>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>> 1 file changed, 4 insertions(+) >>>>>> >>>>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>>>> index >>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>> >>>>>> 100644 >>>>>> --- a/install/share/60ipadns.ldif >>>>>> +++ b/install/share/60ipadns.ldif >>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC >>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch >>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC >>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match >>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC >>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC >>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns >>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ >>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ >>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord >>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord >>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ >>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ >>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ >>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC >>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>> idnsPersistentSearch ) ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top >>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC >>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) >>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC >>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ >>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC >>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( >>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be >>>>> any other object class on the location object (at least not in the >>>>> beginning). >>>>> >>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC >>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>> Conditional ACK if you fix ipaLocationObject. >>>>> >>>>> >>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>> >>>>>> >>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Basti >>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>> >>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>> prototypes and does not provide any information about server (will be >>>>>> done later) >>>>>> >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>> --- >>>>>> ACI.txt | 8 ++ >>>>>> API.txt | 59 ++++++++++++++ >>>>>> VERSION | 4 +- >>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>> install/updates/37-locations.update | 4 + >>>>>> install/updates/Makefile.am | 1 + >>>>>> ipalib/constants.py | 1 + >>>>>> ipalib/plugins/location.py | 142 >>>>>> +++++++++++++++++++++++++++++++++- >>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>> [...] >>>>> >>>>>> diff --git a/VERSION b/VERSION >>>>>> index >>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>> >>>>>> 100644 >>>>>> --- a/VERSION >>>>>> +++ b/VERSION >>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>> # # >>>>>> ######################################################## >>>>>> IPA_API_VERSION_MAJOR=2 >>>>>> -IPA_API_VERSION_MINOR=165 >>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>> +IPA_API_VERSION_MINOR=166 >>>>>> +# Last change: mbasti - location-* commands >>>>> Needs rebase. >>>>> >>>>> >>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>> b/install/share/bootstrap-template.ldif >>>>>> index >>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>> >>>>>> 100644 >>>>>> --- a/install/share/bootstrap-template.ldif >>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>> objectClass: top >>>>>> cn: etc >>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>> +changetype: add >>>>>> +objectClass: nsContainer >>>>>> +objectClass: top >>>>>> +cn: locations >>>>>> + >>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>> changetype: add >>>>>> objectClass: nsContainer >>>>>> diff --git a/install/updates/37-locations.update >>>>>> b/install/updates/37-locations.update >>>>>> index >>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>> >>>>>> 100644 >>>>>> --- a/install/updates/37-locations.update >>>>>> +++ b/install/updates/37-locations.update >>>>>> @@ -0,0 +1,4 @@ >>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>> +default: objectClass: nsContainer >>>>>> +default: objectClass: top >>>>>> +default: cn: locations >>>>> Ok. >>>>> >>>>> [...] >>>>> >>>>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>>>> index >>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>> >>>>>> 100644 >>>>>> --- a/ipalib/plugins/location.py >>>>>> +++ b/ipalib/plugins/location.py >>>>> [...] >>>>>> +__doc__ = _(""" >>>>>> +IPA locations >>>>>> +""") + _(""" >>>>>> +Manipulate with DNS locations >>>>> IMHO "with" should be omited. [...] >>>>> >>>>> >>>>>> + at register() >>>>>> +class location(LDAPObject): >>>>>> + """ >>>>>> + IPA locations >>>>>> + """ >>>>> [...] >>>>> >>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>> + managed_permissions = { >>>>>> + 'System: Read IPA Locations': { >>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>> + 'ipapermdefaultattr': { >>>>>> + 'objectclass', 'idnsname', 'description', >>>>>> + }, >>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>> + }, >>>>>> + 'System: Add IPA Locations': { >>>>>> + 'ipapermright': {'add'}, >>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>> + }, >>>>>> + 'System: Remove IPA Locations': { >>>>>> + 'ipapermright': {'delete'}, >>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>> + }, >>>>>> + 'System: Modify IPA Locations': { >>>>>> + 'ipapermright': {'write'}, >>>>>> + 'ipapermdefaultattr': { >>>>>> + 'description', >>>>>> + }, >>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>> + }, >>>>>> + } >>>>> Sounds reasonable. ACI does not allow renaming location but IMHO this is >>>>> okay. >>>>> Less renames we support the better. >>>>> >>>>> >>>>>> + >>>>>> + takes_params = ( >>>>>> + DNSNameParam( >>>>>> + 'idnsname', >>>>>> + cli_name='name', >>>>>> + primary_key=True, >>>>>> + label=_('Location name'), >>>>>> + doc=_('IPA location name'), >>>>>> + # dns name must be relative, we will put it into middle of >>>>>> + # location domain name for location records >>>>>> + only_relative=True, >>>>>> + ), >>>>> Okay. We need to make sure that relative names with multiple labels work - >>>>> but >>>>> this should automagically work as long as we are handling DNS names using >>>>> proper data types (not as strings). >>>>> >>>>> >>>>>> + Str( >>>>>> + 'description?', >>>>>> + label=_('Description'), >>>>>> + doc=_('IPA Location description'), >>>>>> + ), >>>>> After discussion with Honza we will keep description as single-value in the >>>>> IPA framework and ignore that description attribute is multi-value in LDAP. >>>>> This is done for consitency with mistakes from the past. >>>>> >>>>> [...] >>>>> >>>>>> + at register() >>>>>> +class location_mod(LDAPUpdate): >>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>> This should say 'Modify description' because nothing else can be modified. >>>>> More specific text would hopefully stop some people from looking for rename >>>>> options. >>>> I disagree, this is general description about the modify command, see >>>> privilege-add it is the same as I made. I can see in future that we will >>>> forgot to update description of command if we add something new there. >>> This is really an invalid argument. >>> >>> "We must not touch XYZ because its documentation might become obsolete in >>> future if we forget to update it!" :-) >>> >> >> How about inconsistency with description of older commands? I don't think that >> command description should describe attributes that are allowed to change. >> Allowed attributes are shown in --help output > > I do not agree but push whatever variant you like, it costed too much already. NACK anyway. ipa-dns-install screams if you install a server without DNS and run ipa-dns-install later on: The log contains this: add objectClass: top groupofnames nestedgroup add cn: DNS Administrators add description: DNS Administrators adding new entry "cn=DNS Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 ldap_add: Already exists (68) 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket -Y EXTERNAL' returned non-zero exit status 68 -- Petr^2 Spacek From mbasti at redhat.com Wed May 11 07:41:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 09:41:02 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> Message-ID: <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> On 10.05.2016 18:56, Petr Spacek wrote: > On 10.5.2016 15:38, Petr Spacek wrote: >> On 10.5.2016 15:26, Martin Basti wrote: >>> >>> On 10.05.2016 15:23, Petr Spacek wrote: >>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>> >>>>>>> Patches attached. >>>>>>> >>>>>>> >>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>> >>>>>>> >>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 00:00:00 2001 >>>>>>> From: Martin Basti >>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related privileges >>>>>>> >>>>>>> DNS privileges are important for handling DNS locations which can be >>>>>>> created without DNS servers in IPA topology. We will also need this >>>>>>> privileges presented for future feature 'External DNS support' >>>>>> Seems reasonable, ACK. >>>>>> >>>>>> >>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>> >>>>>>> >>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 00:00:00 2001 >>>>>>> From: Martin Basti >>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and objectclasses >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>> --- >>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>> 1 file changed, 4 insertions(+) >>>>>>> >>>>>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>>>>> index >>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>> >>>>>>> 100644 >>>>>>> --- a/install/share/60ipadns.ldif >>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC >>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch >>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC >>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match >>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC >>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC >>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns >>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ >>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ >>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord >>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord >>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ >>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ >>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ >>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC >>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>> idnsPersistentSearch ) ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top >>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC >>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) >>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC >>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ >>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC >>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName ) MAY ( >>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there will not be >>>>>> any other object class on the location object (at least not in the >>>>>> beginning). >>>>>> >>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC >>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>> >>>>>> >>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>> >>>>>>> >>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 00:00:00 2001 >>>>>>> From: Martin Basti >>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>> >>>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>>> prototypes and does not provide any information about server (will be >>>>>>> done later) >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>> --- >>>>>>> ACI.txt | 8 ++ >>>>>>> API.txt | 59 ++++++++++++++ >>>>>>> VERSION | 4 +- >>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>> install/updates/37-locations.update | 4 + >>>>>>> install/updates/Makefile.am | 1 + >>>>>>> ipalib/constants.py | 1 + >>>>>>> ipalib/plugins/location.py | 142 >>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>> [...] >>>>>> >>>>>>> diff --git a/VERSION b/VERSION >>>>>>> index >>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>> >>>>>>> 100644 >>>>>>> --- a/VERSION >>>>>>> +++ b/VERSION >>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>> # # >>>>>>> ######################################################## >>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>> +# Last change: mbasti - location-* commands >>>>>> Needs rebase. >>>>>> >>>>>> >>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>> b/install/share/bootstrap-template.ldif >>>>>>> index >>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>> >>>>>>> 100644 >>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>> objectClass: top >>>>>>> cn: etc >>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>> +changetype: add >>>>>>> +objectClass: nsContainer >>>>>>> +objectClass: top >>>>>>> +cn: locations >>>>>>> + >>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>> changetype: add >>>>>>> objectClass: nsContainer >>>>>>> diff --git a/install/updates/37-locations.update >>>>>>> b/install/updates/37-locations.update >>>>>>> index >>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>> >>>>>>> 100644 >>>>>>> --- a/install/updates/37-locations.update >>>>>>> +++ b/install/updates/37-locations.update >>>>>>> @@ -0,0 +1,4 @@ >>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>> +default: objectClass: nsContainer >>>>>>> +default: objectClass: top >>>>>>> +default: cn: locations >>>>>> Ok. >>>>>> >>>>>> [...] >>>>>> >>>>>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>>>>> index >>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>> >>>>>>> 100644 >>>>>>> --- a/ipalib/plugins/location.py >>>>>>> +++ b/ipalib/plugins/location.py >>>>>> [...] >>>>>>> +__doc__ = _(""" >>>>>>> +IPA locations >>>>>>> +""") + _(""" >>>>>>> +Manipulate with DNS locations >>>>>> IMHO "with" should be omited. [...] >>>>>> >>>>>> >>>>>>> + at register() >>>>>>> +class location(LDAPObject): >>>>>>> + """ >>>>>>> + IPA locations >>>>>>> + """ >>>>>> [...] >>>>>> >>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>> + managed_permissions = { >>>>>>> + 'System: Read IPA Locations': { >>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>> + 'ipapermdefaultattr': { >>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>> + }, >>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>> + }, >>>>>>> + 'System: Add IPA Locations': { >>>>>>> + 'ipapermright': {'add'}, >>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>> + }, >>>>>>> + 'System: Remove IPA Locations': { >>>>>>> + 'ipapermright': {'delete'}, >>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>> + }, >>>>>>> + 'System: Modify IPA Locations': { >>>>>>> + 'ipapermright': {'write'}, >>>>>>> + 'ipapermdefaultattr': { >>>>>>> + 'description', >>>>>>> + }, >>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>> + }, >>>>>>> + } >>>>>> Sounds reasonable. ACI does not allow renaming location but IMHO this is >>>>>> okay. >>>>>> Less renames we support the better. >>>>>> >>>>>> >>>>>>> + >>>>>>> + takes_params = ( >>>>>>> + DNSNameParam( >>>>>>> + 'idnsname', >>>>>>> + cli_name='name', >>>>>>> + primary_key=True, >>>>>>> + label=_('Location name'), >>>>>>> + doc=_('IPA location name'), >>>>>>> + # dns name must be relative, we will put it into middle of >>>>>>> + # location domain name for location records >>>>>>> + only_relative=True, >>>>>>> + ), >>>>>> Okay. We need to make sure that relative names with multiple labels work - >>>>>> but >>>>>> this should automagically work as long as we are handling DNS names using >>>>>> proper data types (not as strings). >>>>>> >>>>>> >>>>>>> + Str( >>>>>>> + 'description?', >>>>>>> + label=_('Description'), >>>>>>> + doc=_('IPA Location description'), >>>>>>> + ), >>>>>> After discussion with Honza we will keep description as single-value in the >>>>>> IPA framework and ignore that description attribute is multi-value in LDAP. >>>>>> This is done for consitency with mistakes from the past. >>>>>> >>>>>> [...] >>>>>> >>>>>>> + at register() >>>>>>> +class location_mod(LDAPUpdate): >>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>> This should say 'Modify description' because nothing else can be modified. >>>>>> More specific text would hopefully stop some people from looking for rename >>>>>> options. >>>>> I disagree, this is general description about the modify command, see >>>>> privilege-add it is the same as I made. I can see in future that we will >>>>> forgot to update description of command if we add something new there. >>>> This is really an invalid argument. >>>> >>>> "We must not touch XYZ because its documentation might become obsolete in >>>> future if we forget to update it!" :-) >>>> >>> How about inconsistency with description of older commands? I don't think that >>> command description should describe attributes that are allowed to change. >>> Allowed attributes are shown in --help output >> I do not agree but push whatever variant you like, it costed too much already. > NACK anyway. ipa-dns-install screams if you install a server without DNS and > run ipa-dns-install later on: > > The log contains this: > > add objectClass: > top > groupofnames > nestedgroup > add cn: > DNS Administrators > add description: > DNS Administrators > adding new entry "cn=DNS > Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > > > 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( > ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base > ) > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > ldap_add: Already exists (68) > > 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command > '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H > ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket -Y > EXTERNAL' returned non-zero exit status 68 > Well I cannot reproduce it, this should be resolved by patch 473 From mbasti at redhat.com Wed May 11 07:50:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 09:50:07 +0200 Subject: [Freeipa-devel] [PATCH 0103] DNS installer: accept --auto-forwarders option in unattended mode In-Reply-To: <01eef55d-e6ee-a339-c990-e8590cb7eea1@redhat.com> References: <01eef55d-e6ee-a339-c990-e8590cb7eea1@redhat.com> Message-ID: <1fa7a20d-c392-d591-dd40-e1d36b62dbbe@redhat.com> On 06.05.2016 22:20, Martin Basti wrote: > > > > On 03.05.2016 14:56, Petr Spacek wrote: >> Hello, >> >> DNS installer: accept --auto-forwarders option in unattended mode >> >> https://fedorahosted.org/freeipa/ticket/5869 >> >> >> > ACK > > Pushed to: master: e345b53f35b920c1d8ffd9fed2ec636d3bde11df ipa-4-3: ce2d09ee93c6db985242f415ed7b3d22088ca3bc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed May 11 07:57:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 09:57:29 +0200 Subject: [Freeipa-devel] [PATCH 0111] Remove unused file install/share/fedora-ds.init.patc In-Reply-To: <13d915b1-bc76-cbd2-f3f2-34521e607171@redhat.com> References: <13d915b1-bc76-cbd2-f3f2-34521e607171@redhat.com> Message-ID: <456416a5-c5ce-ca29-b612-76db8278f665@redhat.com> On 10.05.2016 13:09, Petr Spacek wrote: > Hello, > > Remove unused file install/share/fedora-ds.init.patch > > > ACK Pushed to master: ea794f3dec52694c58689c6dac267a42b71e5af9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed May 11 09:01:59 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 May 2016 19:01:59 +1000 Subject: [Freeipa-devel] [PATCH] 0057 Prevent replica-install from overwriting cert profile Message-ID: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> Hi team, Attached patch fixes https://fedorahosted.org/freeipa/ticket/5881. It will prevent the issue; I will send a separate mail with my ideas about how to repair installations that were already affected. Cheers, Fraser -------------- next part -------------- From 017da750cff1be553e94673735722656a75bc837 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a21f7d2671461dfb99797d39fc7ee5706317241f..7ba5a5ae72bea656c5818a9fd5909926eb4886d1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1664,7 +1664,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1716,12 +1718,17 @@ def migrate_profiles_to_ldap(): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1732,9 +1739,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 -------------- next part -------------- From b4e12ae1616fdb8c281fa039665f554876c31da6 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 10bc2afc416737e89ffa7255e50bec96eb86fcce..274694012d5afc8690c4d69356d5ae56ae0a44e1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1665,7 +1665,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1717,12 +1719,17 @@ def migrate_profiles_to_ldap(): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1733,9 +1740,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 -------------- next part -------------- From 02cf81b70e5ddf9c4b6ad37c4545d806c959507a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 3ca4fa8d373ebc3375a9fc75b59969292f0198f0..7e68b832831c3487c7bda466ba04d1a3eb51e780 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1764,7 +1764,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1816,12 +1818,17 @@ def migrate_profiles_to_ldap(dogtag_constants): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1832,9 +1839,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 From ftweedal at redhat.com Wed May 11 09:22:48 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 May 2016 19:22:48 +1000 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile Message-ID: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> Hi, Re: Bug 1327092 - URI details missing and OCSP-URI details are incorrectly displayed when certificate generated using IPA. This issue occurs when replica installation overwrites the existing IPA version of the caIPAserviceCert profile with the version shipped with Dogtag. My patch 0057 prevents the issue from occuring but does not repair installations where the problem already happened. For repair, one possibility is to detect when this has occured, and re-import the IPA version of the profile. IMO this would be quite brittle, e.g. if the profile shipped with Dogtag changes or if user has made other changes to the profile it may no longer work. I propose to add a new option to ``ipa certprofile-mod`` which can be used to restore profiles shipped with IPA to a "pristine" state. This would allow admins of affected installations to run a single command to repair the profile, but I think it is an independently useful feature, e.g. if admin messes up a profile but didn't keep a backup of the original config, they can easily get back to the original state. The new option would only be applicable to included profiles (error otherwise). I suggest it be called ``--reset``. Example usage: ipa certprofile-mod caIPAserviceCert --reset All comments welcome! Cheers, Fraser From mbasti at redhat.com Wed May 11 10:08:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 12:08:54 +0200 Subject: [Freeipa-devel] [PATCH 0104-0109] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> Message-ID: On 03.05.2016 14:59, Petr Spacek wrote: > Hello, > > DNS upgrade: change forwarding policy to "only" if private IPs are used. > > https://fedorahosted.org/freeipa/ticket/5710 > > This is the upgrade part. I will add one more patch to print a warning in > dnsforwardzone* commands to avoid surprises. Please do not close the ticket yet. > > > 1) Upgrade failed with 'BindInstance' object has no attribute 'named_conf_get_directive' IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. ('IPA upgrade failed.', 1) The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no attribute 'named_conf_get_directive' 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 213, in __upgrade self.modified = (ld.update(self.files) or self.modified) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 917, in update self._run_updates(all_updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 889, in _run_updates self._run_update_plugin(update['plugin']) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 862, in _run_update_plugin restart_ds, updates = self.api.Updater[plugin_name]() File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1418, in __call__ return self.execute(**options) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line 547, in execute self.update_global_named_conf_forwarder(bind) File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line 508, in update_global_named_conf_forwarder if bind.named_conf_get_directive( AttributeError: 'BindInstance' object has no attribute 'named_conf_get_directive' 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 447, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 437, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 221, in __upgrade raise RuntimeError(e) RuntimeError: 'BindInstance' object has no attribute 'named_conf_get_directive' PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new attribute * 2) + Int('ipadnsversion?', + label=_('IPA DNS version'), + ), Shouldn't be this part of System: Read DNS Configuration permission? 3) - def postprocess_result(self, result): + def postprocess_result(self, result, show_version): if not any(param in result['result'] for param in self.params): result['summary'] = unicode(_('Global DNS configuration is empty')) show_version param was added but I don't see it used in this patch. 4) + Int('ipadnsversion?', + label=_('IPA DNS version'), + ), Could we add comment here that this option is accessible only from installers and upgrade? 5) + for config_option in container_entry.get("ipaConfigString", []): + matched = re.match("^DNSVersion\s+(?P\d+)$", + config_option, flags=re.I) + if matched: + version = int(matched.group("version")) Shouldn't we print error if version cannot be parsed? PATCH * DNS upgrade: separate backup logic to make it reusable * LGTM PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * 7) I'm curious why do you need to check superdomains? PATCH * DNS upgrade: change forwarding policy to = only for conflicting forward zones* 8) + self.log.debug('Zone %s was sucessfully modified to use ' + 'forward policy "only"', zone['idnsname'][0]) <---missing empty line----> + def execute(self, **options): PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if private IPs are used * 9) - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) + dnsutil.related_to_auto_empty_zone( + dnsutil.DNSName(zone.get('idnsname')[0])) Should be in previous commit 10) - return + return False, [] This should be fixed in the previous commit PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" if private IPs are used * 11) IMO this is an upgrade of configuration and this should be in ipaserver/install/server/upgrade.py, upgrade plugins are used only for updating of LDAP values Unless you really want to use this as precedence, but then it requires broader discussion. 12) bind.named_conf_get_directive should be bindinstance.named_conf_get_directive see 1) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Wed May 11 10:27:29 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 11 May 2016 12:27:29 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <4d3efef2-c57a-0f6c-14a6-0d7d36aa870c@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> <572C94FB.8050408@redhat.com> <4d3efef2-c57a-0f6c-14a6-0d7d36aa870c@redhat.com> Message-ID: <57330911.9010004@redhat.com> Hi Martin, Here as per discussion on monday meeting, I removed from the patch everything unrelated to the workaround itself and added a separate test that runs a standard dnssec-enabled zone and queries it without restarting of named. The test is marked as xfail with strict=True, which means, once the bug is fixed it will start to unexpectedly pass causing the whole testrun to fail, so we will know precisely when to revert this change. This test is (apart from restarting named) an exact copy of the existing one, so it would be safe to remove it. Patch 0038 was rebased. On 05/06/2016 04:11 PM, Martin Basti wrote: > > > On 06.05.2016 14:58, Oleg Fayans wrote: >> >> On 05/06/2016 11:42 AM, Martin Basti wrote: >>> >>> On 06.05.2016 11:14, Oleg Fayans wrote: >>>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>>> Tests are finally stable: >>>>>> >>>>>> ============================= test session starts >>>>>> ============================== >>>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: >>>>>> pytest.ini >>>>>> plugins: multihost, sourceorder >>>>>> collected 8 items >>>>>> >>>>>> test_integration/test_dnssec.py ........ >>>>>> >>>>>> ========================= 8 passed in 5561.48 seconds >>>>>> ========================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> PATCH 38 LGTM >>>>> >>>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>>> send this (almost the same) patch for first time, are you sure that we >>>>> want to hide real issues in tests, to just have green color there? >>>>> >>>> The underlying issue is 7 months old. Latest update in the issue from >>>> Peter Spacek is: "I do not have time to investigate this issue now", >>>> which means, that it will stay there for unpredictable amount of time >>>> more. If we want to have a "green" jenkins that actually tests existing >>>> features, we have to accept workarounds for such long-term issues >>>> >>>>> Martin >>> I leave decision if push this or not to different people, however I will >>> do review on this. >>> >>> >>> NACK >>> >>> 1) >>> Why do you change sleep time? How is it related to workaround? >>> >>> - time.sleep(20) # sleep a bit until LDAP changes are applied to >>> DNS >>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>> DNS >> 10 seconds proved to be enough even in our super-slow brno rhevm lab > Unrelated to workaround, send it as new patch > >> >>> >>> 2) >>> why do you removes sleep from several places? How is this related to >>> workaround? >>> @@ -281,13 +302,19 @@ class TestInstallDNSSECFirst(IntegrationTest): >>> "--a-rec=" + self.master.ip >>> ] >>> self.master.run_command(args) >>> - time.sleep(10) # sleep a bit until data are provided by >>> bind-dyndb-ldap >>> >>> args = [ >>> "ipa", "dnsrecord-add", root_zone, >>> self.master.domain.name, >>> "--ns-rec=" + self.master.hostname >>> ] >>> self.master.run_command(args) >> Because it's more reasonable to make changes on all hosts and then wait. > Now, this is NACK. > Yes, that is true wait when all changes are done, but you completely > misunderstood why that sleep is there. > Sleep is there because an A record was added, and it took time until > this change is propagated to DNS, without A record following command > (adding NS record) will fail. > Bind-dyndb-ldap feels happy so it can work today, but it may not work > tomorrow. > >> >>> 3) >>> You restart the same replica twice >>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>> DNS >>> + # A workaround for ticket N 5348 >>> + self.replicas[0].run_command(["systemctl", "restart", >>> + "named-pkcs11.service"]) >>> + self.replicas[0].run_command(["systemctl", "restart", >>> + "named-pkcs11.service"]) >>> + # End of workaround >> My bad. >> >>> 4) >>> Can you create a function doing workaround instead of copying the same >>> code several times? >>> >>> something like >>> def restart_named(*args): >>> for host in args: >>> # host$ systemctl restart named-pkcs11 >>> >>> where args are instances self.host, or self.master, or self.replica >> Now, that's a marvelous idea! Implemented. And put the sleep interval in >> it too just to keep it in one place > I wanted *args to have > restart_named(self.replicas[0], self.replicas[1]) > instead creating an additional list > restart_named([self.replicas[0], self.replicas[1]]) > but whatever it works. > >> >>> 5) >>> Why did you removed this comment? >>> - # wait until zone is signed >> Because this is kin of obvious from the name of the function: >> wait_until_record_is_signed > Unrelated to this workaround, send it as separate patch "Removing > mbasti's useless DNSSEC comments" > >> >>> 6) >>> I'm not sure, but is sleep there needed? Because restart of named will >>> download all LDAP data again. >> It turns out, without this interval the restart does not always help >> >>> If timeout is required maybe reason why >>> time is there should be rephrased, to something like, make sure the >>> dnssec keys were exported for named, or so. >> Rephrased >> >>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>> DNS >>> + # A workaround for ticket N 5348 >>> + self.master.run_command(["systemctl", "restart", >>> + "named-pkcs11.service"]) >>> + self.replicas[0].run_command(["systemctl", "restart", >>> + "named-pkcs11.service"]) >>> + # End of workaround >>> >>> Martin^2 > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0037.2-A-workaround-for-ticket-N-5348.patch Type: text/x-patch Size: 7402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0038.1-Added-necessary-A-record-for-replica-to-root-zone.patch Type: text/x-patch Size: 1218 bytes Desc: not available URL: From pvomacka at redhat.com Wed May 11 11:08:58 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 11 May 2016 13:08:58 +0200 Subject: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators Message-ID: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> Hi, the patch adds webui part for authentication indicators. Ticket: https://fedorahosted.org/freeipa/ticket/5872 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0034-Add-authentication-indicators-to-webui.patch Type: text/x-patch Size: 4767 bytes Desc: not available URL: From mbasti at redhat.com Wed May 11 11:20:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 13:20:43 +0200 Subject: [Freeipa-devel] [TEST][patch-0037]Fixes of dnssec tests In-Reply-To: <57330911.9010004@redhat.com> References: <572C498B.4060202@redhat.com> <19b3d1c7-ffe6-acb4-cf85-f93422932417@redhat.com> <572C6092.3010804@redhat.com> <2fa66a2c-3c7d-76a9-78ad-9f5bbbc34d5d@redhat.com> <572C94FB.8050408@redhat.com> <4d3efef2-c57a-0f6c-14a6-0d7d36aa870c@redhat.com> <57330911.9010004@redhat.com> Message-ID: <55a0ea3f-97c1-0e8a-f798-05d81a1d5853@redhat.com> On 11.05.2016 12:27, Oleg Fayans wrote: > Hi Martin, > > Here as per discussion on monday meeting, I removed from the patch > everything unrelated to the workaround itself and added a separate test > that runs a standard dnssec-enabled zone and queries it without > restarting of named. The test is marked as xfail with strict=True, which > means, once the bug is fixed it will start to unexpectedly pass causing > the whole testrun to fail, so we will know precisely when to revert this > change. This test is (apart from restarting named) an exact copy of the > existing one, so it would be safe to remove it. > > Patch 0038 was rebased. > > On 05/06/2016 04:11 PM, Martin Basti wrote: >> >> On 06.05.2016 14:58, Oleg Fayans wrote: >>> On 05/06/2016 11:42 AM, Martin Basti wrote: >>>> On 06.05.2016 11:14, Oleg Fayans wrote: >>>>> On 05/06/2016 09:48 AM, Martin Basti wrote: >>>>>> On 06.05.2016 09:36, Oleg Fayans wrote: >>>>>>> Tests are finally stable: >>>>>>> >>>>>>> ============================= test session starts >>>>>>> ============================== >>>>>>> platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 >>>>>>> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: >>>>>>> pytest.ini >>>>>>> plugins: multihost, sourceorder >>>>>>> collected 8 items >>>>>>> >>>>>>> test_integration/test_dnssec.py ........ >>>>>>> >>>>>>> ========================= 8 passed in 5561.48 seconds >>>>>>> ========================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> PATCH 38 LGTM >>>>>> >>>>>> PATCH 37 IIRC I refused to accept workaround for this issue when you >>>>>> send this (almost the same) patch for first time, are you sure that we >>>>>> want to hide real issues in tests, to just have green color there? >>>>>> >>>>> The underlying issue is 7 months old. Latest update in the issue from >>>>> Peter Spacek is: "I do not have time to investigate this issue now", >>>>> which means, that it will stay there for unpredictable amount of time >>>>> more. If we want to have a "green" jenkins that actually tests existing >>>>> features, we have to accept workarounds for such long-term issues >>>>> >>>>>> Martin >>>> I leave decision if push this or not to different people, however I will >>>> do review on this. >>>> >>>> >>>> NACK >>>> >>>> 1) >>>> Why do you change sleep time? How is it related to workaround? >>>> >>>> - time.sleep(20) # sleep a bit until LDAP changes are applied to >>>> DNS >>>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>>> DNS >>> 10 seconds proved to be enough even in our super-slow brno rhevm lab >> Unrelated to workaround, send it as new patch >> >>>> 2) >>>> why do you removes sleep from several places? How is this related to >>>> workaround? >>>> @@ -281,13 +302,19 @@ class TestInstallDNSSECFirst(IntegrationTest): >>>> "--a-rec=" + self.master.ip >>>> ] >>>> self.master.run_command(args) >>>> - time.sleep(10) # sleep a bit until data are provided by >>>> bind-dyndb-ldap >>>> >>>> args = [ >>>> "ipa", "dnsrecord-add", root_zone, >>>> self.master.domain.name, >>>> "--ns-rec=" + self.master.hostname >>>> ] >>>> self.master.run_command(args) >>> Because it's more reasonable to make changes on all hosts and then wait. >> Now, this is NACK. >> Yes, that is true wait when all changes are done, but you completely >> misunderstood why that sleep is there. >> Sleep is there because an A record was added, and it took time until >> this change is propagated to DNS, without A record following command >> (adding NS record) will fail. >> Bind-dyndb-ldap feels happy so it can work today, but it may not work >> tomorrow. >> >>>> 3) >>>> You restart the same replica twice >>>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>>> DNS >>>> + # A workaround for ticket N 5348 >>>> + self.replicas[0].run_command(["systemctl", "restart", >>>> + "named-pkcs11.service"]) >>>> + self.replicas[0].run_command(["systemctl", "restart", >>>> + "named-pkcs11.service"]) >>>> + # End of workaround >>> My bad. >>> >>>> 4) >>>> Can you create a function doing workaround instead of copying the same >>>> code several times? >>>> >>>> something like >>>> def restart_named(*args): >>>> for host in args: >>>> # host$ systemctl restart named-pkcs11 >>>> >>>> where args are instances self.host, or self.master, or self.replica >>> Now, that's a marvelous idea! Implemented. And put the sleep interval in >>> it too just to keep it in one place >> I wanted *args to have >> restart_named(self.replicas[0], self.replicas[1]) >> instead creating an additional list >> restart_named([self.replicas[0], self.replicas[1]]) >> but whatever it works. >> >>>> 5) >>>> Why did you removed this comment? >>>> - # wait until zone is signed >>> Because this is kin of obvious from the name of the function: >>> wait_until_record_is_signed >> Unrelated to this workaround, send it as separate patch "Removing >> mbasti's useless DNSSEC comments" >> >>>> 6) >>>> I'm not sure, but is sleep there needed? Because restart of named will >>>> download all LDAP data again. >>> It turns out, without this interval the restart does not always help >>> >>>> If timeout is required maybe reason why >>>> time is there should be rephrased, to something like, make sure the >>>> dnssec keys were exported for named, or so. >>> Rephrased >>> >>>> + time.sleep(10) # sleep a bit until LDAP changes are applied to >>>> DNS >>>> + # A workaround for ticket N 5348 >>>> + self.master.run_command(["systemctl", "restart", >>>> + "named-pkcs11.service"]) >>>> + self.replicas[0].run_command(["systemctl", "restart", >>>> + "named-pkcs11.service"]) >>>> + # End of workaround >>>> >>>> Martin^2 Patch 0037: Pushed to: ipa-4-3: 377d75b98b3e62a6c224940420b61c6e8a7846a1 master: 5567dff4b46cc05bf0ea44dd03afdd12645143a5 Patch 0038: ACK Pushed to master: 84e5065b398eec722b30123319dc7725286a2a74 From pvomacka at redhat.com Wed May 11 11:25:35 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 11 May 2016 13:25:35 +0200 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: On 05/06/2016 02:44 PM, Sumit Bose wrote: > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote: >> This series of patches implements authentication indicator insertion, >> evaluation and management in FreeIPA. Besides these patches, two other >> patches are needed to round out support. >> >> First, we need a UI patch: https://fedorahosted.org/freeipa/ticket/5872 I've already sent the patch to the ML. I use the API doc string as a tooltip for the authentication indicator field in webui and now there is only "Authentication indicator whitelist" and I think that we might provide more information in webui. So there are two solutions I can write my own tooltip text or we can extend the API doc string for this new option. Actually, there is another one - leave it as it is. What do you think would be better? >> >> Second, we need a SSSD patch to handle the new case where multiple >> responders are set (when either 1FA or 2FA can be used). > I've already some initial work done here and will continue with your > patches. > >> Please note that the last patch in this series (0093) is untested and >> simply represents my desire to get these patches off of my hard disk >> before I take a long weekend. This patch also requires mrogers' patch >> 0001 (already merged to master). I tried to apply your patches and the last patch (93) needs change in VERSION file. IPA_API_VERSION_MINOR is the same as in master. So it needs to be incremented. Pavel^3 >> >> Also worthy of note is the need for an OID for the authentication >> control. Hopefully Simo can assign this after we agree that this >> control method is sufficient. One question I had was whether or not it >> would be possible to send the control only on UNIX sockets (0089; >> report_auth_method()). >> >> Please review the approaches taken here. I plan to hit this hard on >> Monday. > I'm on a conference next week and currently busy preparing my > presentation. I will give you feedback in the following week. > > bye, > Sumit > >> Nathaniel From jcholast at redhat.com Wed May 11 11:31:36 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 May 2016 13:31:36 +0200 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile In-Reply-To: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> References: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> Message-ID: <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> On 11.5.2016 11:22, Fraser Tweedale wrote: > Hi, > > Re: Bug 1327092 - URI details missing and OCSP-URI details are > incorrectly displayed when certificate generated using IPA. > > This issue occurs when replica installation overwrites the existing > IPA version of the caIPAserviceCert profile with the version shipped > with Dogtag. My patch 0057 prevents the issue from occuring but > does not repair installations where the problem already happened. > > For repair, one possibility is to detect when this has occured, and > re-import the IPA version of the profile. IMO this would be quite > brittle, e.g. if the profile shipped with Dogtag changes or if user > has made other changes to the profile it may no longer work. > > I propose to add a new option to ``ipa certprofile-mod`` which can > be used to restore profiles shipped with IPA to a "pristine" state. > This would allow admins of affected installations to run a single > command to repair the profile, but I think it is an independently > useful feature, e.g. if admin messes up a profile but didn't keep a > backup of the original config, they can easily get back to the > original state. > > The new option would only be applicable to included profiles (error > otherwise). I suggest it be called ``--reset``. Example usage: > > ipa certprofile-mod caIPAserviceCert --reset > > All comments welcome! NACK, 1) This is a separate operation, so it should be a separate command. 2) I don't think it is generally a good idea to have a command which relies on some file being existent or having expected content on all replicas. 3) I would rather avoid adding new commands just to work around bugs. IMO "certprofile-import caIPAserviceCert /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this case. Honza -- Jan Cholasta From mbasti at redhat.com Wed May 11 12:55:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 May 2016 14:55:49 +0200 Subject: [Freeipa-devel] [PATCH 0015] Added exception handling for mal-formatted XML Parsing In-Reply-To: <5731CD3D.9090306@redhat.com> References: <57301F9B.6070005@redhat.com> <8524648f-ff10-6747-07d3-b1ca6bafb13d@redhat.com> <5731CD3D.9090306@redhat.com> Message-ID: <88dc6d05-b882-38ae-1d35-fde83074749e@redhat.com> On 10.05.2016 13:59, Abhijeet Kasurde wrote: > Hi All, > > Please find the patch for review. > > Thanks, > Abhijeet Kasurde > > On 05/10/2016 01:13 PM, Martin Basti wrote: >> >> >> >> On 09.05.2016 07:26, Abhijeet Kasurde wrote: >>> Hi all, >>> >>> Please review the patch. >>> >>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1333755 >>> >>> Thanks, >>> Abhijeet Kasurde >>> >>> >>> >> Hello, >> >> + self.raise_certificate_operation_error('parse', >> + detail=e.msg) >> >> Please use detail=str(e), e.msg is deprecated >> >> Martin^2 >> > > > For future: * patches should contain trac ticket instead of a BZ link (I amended patch with ticket) * BZ was marked as wontfix, but because patch was trivial I reopened BZ and cloned ticket to trac. Please don't do any wontfix tickets/bz, any patches for these will be rejected ACK master: * 2df25cb359723dd72077c60a12bc037d5c77f931 Added exception handling for mal-formatted XML Parsing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed May 11 13:04:18 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 May 2016 23:04:18 +1000 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile In-Reply-To: <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> References: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> Message-ID: <20160511130418.GW1237@dhcp-40-8.bne.redhat.com> On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote: > On 11.5.2016 11:22, Fraser Tweedale wrote: > >Hi, > > > >Re: Bug 1327092 - URI details missing and OCSP-URI details are > >incorrectly displayed when certificate generated using IPA. > > > >This issue occurs when replica installation overwrites the existing > >IPA version of the caIPAserviceCert profile with the version shipped > >with Dogtag. My patch 0057 prevents the issue from occuring but > >does not repair installations where the problem already happened. > > > >For repair, one possibility is to detect when this has occured, and > >re-import the IPA version of the profile. IMO this would be quite > >brittle, e.g. if the profile shipped with Dogtag changes or if user > >has made other changes to the profile it may no longer work. > > > >I propose to add a new option to ``ipa certprofile-mod`` which can > >be used to restore profiles shipped with IPA to a "pristine" state. > >This would allow admins of affected installations to run a single > >command to repair the profile, but I think it is an independently > >useful feature, e.g. if admin messes up a profile but didn't keep a > >backup of the original config, they can easily get back to the > >original state. > > > >The new option would only be applicable to included profiles (error > >otherwise). I suggest it be called ``--reset``. Example usage: > > > > ipa certprofile-mod caIPAserviceCert --reset > > > >All comments welcome! > > NACK, > Honza, thanks for your feedback. > 1) This is a separate operation, so it should be a separate command. > certprofile-mod already supports updating the Dogtag profile configuration, via `--file ` option. However, we cannot use that with /usr/share/ipa/profiles/* because these are templates that have installation-specific values substituted into them. Consequently, your suggestion at (3) is not feasible. The need to do the template substitutions is what led me to this proposal. > 2) I don't think it is generally a good idea to have a command which relies > on some file being existent or having expected content on all replicas. > The operation would only need to be performed on a single replica (Dogtag profiles are stored in LDAP and replicated), so there is no such reliance. > 3) I would rather avoid adding new commands just to work around bugs. IMO > "certprofile-import caIPAserviceCert > /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this > case. > As discussed above, I'm afraid it is not, unless users manually do the substitutions. If we provide some code to do the substitutions, we have essentially reach what I have proposed. Other suggestions are welcome. BTW, there is another option I did not already mention: do nothing in code, and help users on a case-by-case basis / point them to a guide / KB article? Cheers, Fraser From pvoborni at redhat.com Wed May 11 13:28:40 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 May 2016 15:28:40 +0200 Subject: [Freeipa-devel] [PATCH] 0011 webui: Offer OTP generation for host enrollment in the UI In-Reply-To: <56FD3B3C.9020307@redhat.com> References: <56FD3B3C.9020307@redhat.com> Message-ID: <3a1c38eb-2283-a7c4-fef3-5e5269cd127d@redhat.com> On 03/31/2016 04:59 PM, Pavel Vomacka wrote: > Hello, > > This patch adds option to add host dialog which allows to show generated > OTP. > The patch also changes the way of informing user about success of adding > host > but only when the 'Generate OTP' option is checked. > > https://fedorahosted.org/freeipa/ticket/4602 The patch copy&pastes behavior of entity adder dialog buttons when the purpose is to do additional stuff on success. IMHO it copies to much logic. Also the following method of redefining add handler is not very object oriented: that.get_button('add_and_edit').click = function() { Wouldn't it be better to move anonymous success handlers in entity_adder_dialog to a class methods to achieve it. E.g: """ click: function() { that.hide_message(); that.add( function(data, text_status, xhr) { that.added.notify([data], that); that.close(); var result = data.result.result; that.show_edit_page(that.entity, result); that.notify_success(data); }, that.on_error); } """ to """ click: function() { that.hide_message(); that.add(that.on_add_success, that.on_error); } that.on_add_success = function(data, text_status, xhr) { that.added.notify([data], that); that.close(); var result = data.result.result; that.show_edit_page(that.entity, result); that.notify_success(data); }; that.entity_adder_dialog_on_add_success = that.on_add_success; """ so in child class it would be overriden e.g. by: that.on_add_success = function(data, text_status, xhr) { that.entity_adder_dialog_on_add_success(data, text_status, xhr); // .. my new code }; It follows the pattern as in other code. Other possible emthod is to implement in parent class handle_notifications override point and then change calls of that.notify_success(data); to that.handle_notifications(data, method); Which could be overridden in child. Or probably my favorite: entity_adder_dialog has 'added' event which is raised prior closing the dialog (in 'add' and 'add and edit'). We could either register new event handler which would to the stuff. It will need a way to distinguish buttons. The button name/method could be added as addional param in the base class: that.added.notify([data, 'add'], that); Or a new event could be created if it is important to call it after dialog is closed. that.post_added = IPA.observer(); that.post_added.notify([data, 'add'], that); dialog.post_added.attach(function(data, method) { // do something; }); -- Petr Vobornik From jcholast at redhat.com Wed May 11 14:36:34 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 May 2016 16:36:34 +0200 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile In-Reply-To: <20160511130418.GW1237@dhcp-40-8.bne.redhat.com> References: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> <20160511130418.GW1237@dhcp-40-8.bne.redhat.com> Message-ID: <02b20cfc-f2b0-1c14-1a07-6d1a2280fb5f@redhat.com> On 11.5.2016 15:04, Fraser Tweedale wrote: > On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote: >> On 11.5.2016 11:22, Fraser Tweedale wrote: >>> Hi, >>> >>> Re: Bug 1327092 - URI details missing and OCSP-URI details are >>> incorrectly displayed when certificate generated using IPA. >>> >>> This issue occurs when replica installation overwrites the existing >>> IPA version of the caIPAserviceCert profile with the version shipped >>> with Dogtag. My patch 0057 prevents the issue from occuring but >>> does not repair installations where the problem already happened. >>> >>> For repair, one possibility is to detect when this has occured, and >>> re-import the IPA version of the profile. IMO this would be quite >>> brittle, e.g. if the profile shipped with Dogtag changes or if user >>> has made other changes to the profile it may no longer work. >>> >>> I propose to add a new option to ``ipa certprofile-mod`` which can >>> be used to restore profiles shipped with IPA to a "pristine" state. >>> This would allow admins of affected installations to run a single >>> command to repair the profile, but I think it is an independently >>> useful feature, e.g. if admin messes up a profile but didn't keep a >>> backup of the original config, they can easily get back to the >>> original state. >>> >>> The new option would only be applicable to included profiles (error >>> otherwise). I suggest it be called ``--reset``. Example usage: >>> >>> ipa certprofile-mod caIPAserviceCert --reset >>> >>> All comments welcome! >> >> NACK, >> > Honza, thanks for your feedback. > >> 1) This is a separate operation, so it should be a separate command. >> > certprofile-mod already supports updating the Dogtag profile > configuration, via `--file ` option. However, we cannot use > that with /usr/share/ipa/profiles/* because these are templates that > have installation-specific values substituted into them. > Consequently, your suggestion at (3) is not feasible. The need to > do the template substitutions is what led me to this proposal. I stand corrected. > >> 2) I don't think it is generally a good idea to have a command which relies >> on some file being existent or having expected content on all replicas. >> > The operation would only need to be performed on a single replica > (Dogtag profiles are stored in LDAP and replicated), so there is no > such reliance. Sure, but how are you going to guarantee the command is executed on a replica with the right version of the file? The short answer is that you can't, but an API command should do the same thing no matter what replica you are talking to. > >> 3) I would rather avoid adding new commands just to work around bugs. IMO >> "certprofile-import caIPAserviceCert >> /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this >> case. >> > As discussed above, I'm afraid it is not, unless users manually do > the substitutions. If we provide some code to do the substitutions, > we have essentially reach what I have proposed. > > Other suggestions are welcome. > > BTW, there is another option I did not already mention: do nothing > in code, and help users on a case-by-case basis / point them to a > guide / KB article? This option is my favorite :-) (If automatic fix during upgrade is indeed out of the picture.) -- Jan Cholasta From ftweedal at redhat.com Wed May 11 22:56:52 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 12 May 2016 08:56:52 +1000 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile In-Reply-To: <02b20cfc-f2b0-1c14-1a07-6d1a2280fb5f@redhat.com> References: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> <20160511130418.GW1237@dhcp-40-8.bne.redhat.com> <02b20cfc-f2b0-1c14-1a07-6d1a2280fb5f@redhat.com> Message-ID: <20160511225606.GY1237@dhcp-40-8.bne.redhat.com> On Wed, May 11, 2016 at 04:36:34PM +0200, Jan Cholasta wrote: > On 11.5.2016 15:04, Fraser Tweedale wrote: > >On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote: > >>On 11.5.2016 11:22, Fraser Tweedale wrote: > >>>Hi, > >>> > >>>Re: Bug 1327092 - URI details missing and OCSP-URI details are > >>>incorrectly displayed when certificate generated using IPA. > >>> > >>>This issue occurs when replica installation overwrites the existing > >>>IPA version of the caIPAserviceCert profile with the version shipped > >>>with Dogtag. My patch 0057 prevents the issue from occuring but > >>>does not repair installations where the problem already happened. > >>> > >>>For repair, one possibility is to detect when this has occured, and > >>>re-import the IPA version of the profile. IMO this would be quite > >>>brittle, e.g. if the profile shipped with Dogtag changes or if user > >>>has made other changes to the profile it may no longer work. > >>> > >>>I propose to add a new option to ``ipa certprofile-mod`` which can > >>>be used to restore profiles shipped with IPA to a "pristine" state. > >>>This would allow admins of affected installations to run a single > >>>command to repair the profile, but I think it is an independently > >>>useful feature, e.g. if admin messes up a profile but didn't keep a > >>>backup of the original config, they can easily get back to the > >>>original state. > >>> > >>>The new option would only be applicable to included profiles (error > >>>otherwise). I suggest it be called ``--reset``. Example usage: > >>> > >>> ipa certprofile-mod caIPAserviceCert --reset > >>> > >>>All comments welcome! > >> > >>NACK, > >> > >Honza, thanks for your feedback. > > > >>1) This is a separate operation, so it should be a separate command. > >> > >certprofile-mod already supports updating the Dogtag profile > >configuration, via `--file ` option. However, we cannot use > >that with /usr/share/ipa/profiles/* because these are templates that > >have installation-specific values substituted into them. > >Consequently, your suggestion at (3) is not feasible. The need to > >do the template substitutions is what led me to this proposal. > > I stand corrected. > > > > >>2) I don't think it is generally a good idea to have a command which relies > >>on some file being existent or having expected content on all replicas. > >> > >The operation would only need to be performed on a single replica > >(Dogtag profiles are stored in LDAP and replicated), so there is no > >such reliance. > > Sure, but how are you going to guarantee the command is executed on a > replica with the right version of the file? The short answer is that you > can't, but an API command should do the same thing no matter what replica > you are talking to. > That's true. The longer answer is that every replica has the same version of the file, and when we need to change the default profile we should be implementing a mechanism to automatically update to latest version: https://fedorahosted.org/freeipa/ticket/5323. So I don't think it would be a problem in practice. > > > >>3) I would rather avoid adding new commands just to work around bugs. IMO > >>"certprofile-import caIPAserviceCert > >>/usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this > >>case. > >> > >As discussed above, I'm afraid it is not, unless users manually do > >the substitutions. If we provide some code to do the substitutions, > >we have essentially reach what I have proposed. > > > >Other suggestions are welcome. > > > >BTW, there is another option I did not already mention: do nothing > >in code, and help users on a case-by-case basis / point them to a > >guide / KB article? > > This option is my favorite :-) (If automatic fix during upgrade is indeed > out of the picture.) > Martin, if the profile is incorrect, do we have to fix it automatically? What are our obligations / customer expectations here? From slaznick at redhat.com Thu May 12 07:17:19 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 12 May 2016 09:17:19 +0200 Subject: [Freeipa-devel] [PATCH 0470] remove unused code in SchemaCache In-Reply-To: <572370D2.6060407@redhat.com> References: <572370D2.6060407@redhat.com> Message-ID: <57342DFF.8080703@redhat.com> ACK, I see no reason for the code to be present there. On 04/29/2016 04:33 PM, Martin Basti wrote: > Patch attached. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Thu May 12 08:04:14 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 12 May 2016 10:04:14 +0200 Subject: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure In-Reply-To: <572771C7.7000203@redhat.com> References: <5727639F.1030108@redhat.com> <572771C7.7000203@redhat.com> Message-ID: <573438FE.6010905@redhat.com> ACK On 05/02/2016 05:27 PM, Martin Basti wrote: > > > On 02.05.2016 17:19, Petr Vobornik wrote: >> On 05/02/2016 04:26 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5820 >>> >>> Patch attached. >>> >>> >> Copying the err message 3 times is not very nice. It should be in a >> constant otherwise we risk that they will get out of sync in a future. > Updated patch attached. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 12 09:01:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 May 2016 11:01:06 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> Message-ID: On 11.05.2016 09:41, Martin Basti wrote: > > > On 10.05.2016 18:56, Petr Spacek wrote: >> On 10.5.2016 15:38, Petr Spacek wrote: >>> On 10.5.2016 15:26, Martin Basti wrote: >>>> >>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>> >>>>>>>> Patches attached. >>>>>>>> >>>>>>>> >>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>> 00:00:00 2001 >>>>>>>> From: Martin Basti >>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>> privileges >>>>>>>> >>>>>>>> DNS privileges are important for handling DNS locations which >>>>>>>> can be >>>>>>>> created without DNS servers in IPA topology. We will also need >>>>>>>> this >>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>> Seems reasonable, ACK. >>>>>>> >>>>>>> >>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>> 00:00:00 2001 >>>>>>>> From: Martin Basti >>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>> objectclasses >>>>>>>> >>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>> --- >>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>> >>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>> b/install/share/60ipadns.ldif >>>>>>>> index >>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 >>>>>>>> NAME >>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>> 'idnsSecKeySep' DESC >>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>> booleanMatch >>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>> v4.1' ) >>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>> caseIgnoreIA5Match >>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE >>>>>>>> SYNTAX >>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>> 'ipaLocation' DESC >>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>> 'ipaLocationWeight' DESC >>>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch >>>>>>>> SYNTAX >>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>> 'idnsRecord' DESC 'dns >>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( >>>>>>>> cn $ >>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ >>>>>>>> a6Record $ >>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>> mXRecord $ >>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord >>>>>>>> $ KeyRecord >>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ >>>>>>>> dNameRecord >>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>> IPSECKEYRecord $ >>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' >>>>>>>> DESC 'Zone >>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>> idnsSOAmName $ >>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>> idnsAllowQuery $ >>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>> idnsForwarders $ >>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>> 'idnsConfigObject' DESC >>>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>> idnsPersistentSearch ) ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>> 'ipaDNSZone' SUP top >>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>> 'idnsForwardZone' DESC >>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>> idnsZoneActive ) >>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>> 'idnsSecKey' DESC 'DNSSEC >>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>> idnsSecKeyCreated $ >>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>> idnsSecKeyRevoke $ >>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>> 'ipaLocationObject' DESC >>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>> idnsName ) MAY ( >>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there >>>>>>> will not be >>>>>>> any other object class on the location object (at least not in the >>>>>>> beginning). >>>>>>> >>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>> 'ipaLocationMember' DESC >>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>> >>>>>>> >>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>> >>>>>>>> >>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>> 00:00:00 2001 >>>>>>>> From: Martin Basti >>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>> >>>>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>>>> prototypes and does not provide any information about server >>>>>>>> (will be >>>>>>>> done later) >>>>>>>> >>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>> --- >>>>>>>> ACI.txt | 8 ++ >>>>>>>> API.txt | 59 ++++++++++++++ >>>>>>>> VERSION | 4 +- >>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>> ipalib/constants.py | 1 + >>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>> [...] >>>>>>> >>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>> index >>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/VERSION >>>>>>>> +++ b/VERSION >>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>> # # >>>>>>>> ######################################################## >>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>> +# Last change: mbasti - location-* commands >>>>>>> Needs rebase. >>>>>>> >>>>>>> >>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>> index >>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>> objectClass: top >>>>>>>> cn: etc >>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>> +changetype: add >>>>>>>> +objectClass: nsContainer >>>>>>>> +objectClass: top >>>>>>>> +cn: locations >>>>>>>> + >>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>> changetype: add >>>>>>>> objectClass: nsContainer >>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>> b/install/updates/37-locations.update >>>>>>>> index >>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/install/updates/37-locations.update >>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>> +default: objectClass: nsContainer >>>>>>>> +default: objectClass: top >>>>>>>> +default: cn: locations >>>>>>> Ok. >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>> b/ipalib/plugins/location.py >>>>>>>> index >>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>> [...] >>>>>>>> +__doc__ = _(""" >>>>>>>> +IPA locations >>>>>>>> +""") + _(""" >>>>>>>> +Manipulate with DNS locations >>>>>>> IMHO "with" should be omited. [...] >>>>>>> >>>>>>> >>>>>>>> + at register() >>>>>>>> +class location(LDAPObject): >>>>>>>> + """ >>>>>>>> + IPA locations >>>>>>>> + """ >>>>>>> [...] >>>>>>> >>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>> + managed_permissions = { >>>>>>>> + 'System: Read IPA Locations': { >>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>> + 'ipapermdefaultattr': { >>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>> + }, >>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>> + }, >>>>>>>> + 'System: Add IPA Locations': { >>>>>>>> + 'ipapermright': {'add'}, >>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>> + }, >>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>> + }, >>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>> + 'ipapermright': {'write'}, >>>>>>>> + 'ipapermdefaultattr': { >>>>>>>> + 'description', >>>>>>>> + }, >>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>> + }, >>>>>>>> + } >>>>>>> Sounds reasonable. ACI does not allow renaming location but IMHO >>>>>>> this is >>>>>>> okay. >>>>>>> Less renames we support the better. >>>>>>> >>>>>>> >>>>>>>> + >>>>>>>> + takes_params = ( >>>>>>>> + DNSNameParam( >>>>>>>> + 'idnsname', >>>>>>>> + cli_name='name', >>>>>>>> + primary_key=True, >>>>>>>> + label=_('Location name'), >>>>>>>> + doc=_('IPA location name'), >>>>>>>> + # dns name must be relative, we will put it into >>>>>>>> middle of >>>>>>>> + # location domain name for location records >>>>>>>> + only_relative=True, >>>>>>>> + ), >>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>> labels work - >>>>>>> but >>>>>>> this should automagically work as long as we are handling DNS >>>>>>> names using >>>>>>> proper data types (not as strings). >>>>>>> >>>>>>> >>>>>>>> + Str( >>>>>>>> + 'description?', >>>>>>>> + label=_('Description'), >>>>>>>> + doc=_('IPA Location description'), >>>>>>>> + ), >>>>>>> After discussion with Honza we will keep description as >>>>>>> single-value in the >>>>>>> IPA framework and ignore that description attribute is >>>>>>> multi-value in LDAP. >>>>>>> This is done for consitency with mistakes from the past. >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> + at register() >>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>> This should say 'Modify description' because nothing else can be >>>>>>> modified. >>>>>>> More specific text would hopefully stop some people from looking >>>>>>> for rename >>>>>>> options. >>>>>> I disagree, this is general description about the modify command, >>>>>> see >>>>>> privilege-add it is the same as I made. I can see in future that >>>>>> we will >>>>>> forgot to update description of command if we add something new >>>>>> there. >>>>> This is really an invalid argument. >>>>> >>>>> "We must not touch XYZ because its documentation might become >>>>> obsolete in >>>>> future if we forget to update it!" :-) >>>>> >>>> How about inconsistency with description of older commands? I don't >>>> think that >>>> command description should describe attributes that are allowed to >>>> change. >>>> Allowed attributes are shown in --help output >>> I do not agree but push whatever variant you like, it costed too >>> much already. >> NACK anyway. ipa-dns-install screams if you install a server without >> DNS and >> run ipa-dns-install later on: >> >> The log contains this: >> >> add objectClass: >> top >> groupofnames >> nestedgroup >> add cn: >> DNS Administrators >> add description: >> DNS Administrators >> adding new entry "cn=DNS >> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >> >> >> >> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >> >> ) >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> ldap_add: Already exists (68) >> >> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >> -Y >> EXTERNAL' returned non-zero exit status 68 >> > Well I cannot reproduce it, this should be resolved by patch 473 > Updated patches attached I found that IDNA did not work with previous version, fixed + IDNA tests added -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0473.2-DNS-Locations-Always-create-DNS-related-privileges.patch Type: text/x-patch Size: 4774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0474.2-DNS-Locations-add-new-attributes-and-objectclasses.patch Type: text/x-patch Size: 4065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0475.2-DNS-Locations-location-commands.patch Type: text/x-patch Size: 14221 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0476.2-DNS-Locations-API-tests.patch Type: text/x-patch Size: 9331 bytes Desc: not available URL: From mbasti at redhat.com Thu May 12 09:18:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 May 2016 11:18:15 +0200 Subject: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure In-Reply-To: <573438FE.6010905@redhat.com> References: <5727639F.1030108@redhat.com> <572771C7.7000203@redhat.com> <573438FE.6010905@redhat.com> Message-ID: <951e9538-fa40-952c-063f-d6c20969ec72@redhat.com> On 12.05.2016 10:04, Stanislav Laznicka wrote: > ACK > > On 05/02/2016 05:27 PM, Martin Basti wrote: >> >> >> On 02.05.2016 17:19, Petr Vobornik wrote: >>> On 05/02/2016 04:26 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5820 >>>> >>>> Patch attached. >>>> >>>> >>> Copying the err message 3 times is not very nice. It should be in a >>> constant otherwise we risk that they will get out of sync in a future. >> Updated patch attached. >> >> > Pushed to master: ab2ebf489fa5afb57e5f49a8c025d555f583eb1a -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 12 09:19:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 May 2016 11:19:06 +0200 Subject: [Freeipa-devel] [PATCH 0470] remove unused code in SchemaCache In-Reply-To: <57342DFF.8080703@redhat.com> References: <572370D2.6060407@redhat.com> <57342DFF.8080703@redhat.com> Message-ID: <9019852c-65b7-2555-ac4c-fe001b87f2bd@redhat.com> On 12.05.2016 09:17, Stanislav Laznicka wrote: > ACK, I see no reason for the code to be present there. > > On 04/29/2016 04:33 PM, Martin Basti wrote: >> Patch attached. >> >> > Pushed to master: 93332bcf4dd0189b7136db7fe4f900fc04171d20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu May 12 11:29:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 May 2016 13:29:17 +0200 Subject: [Freeipa-devel] [PATCH 0096] Batch command: avoid accessing potentially undefined context.principa In-Reply-To: References: <571A0AD3.3090507@redhat.com> <4e5bc6fe-d0d1-c331-7651-32224d6b5f4b@redhat.com> Message-ID: <93e1e7e5-b38e-945d-a63e-e2dfe727f726@redhat.com> On 10.5.2016 12:34, Petr Spacek wrote: > On 4.5.2016 15:04, Jan Cholasta wrote: >> Hi, >> >> On 22.4.2016 13:28, Petr Spacek wrote: >>> Hello, >>> >>> Batch command: avoid accessing potentially undefined context.principal >>> >>> This might happen when the command is called directly in Python, >>> e.g. in installers and so on. >>> >>> Pylint pylint-1.5.5-1.fc24.noarch caught this. >>> >>> https://fedorahosted.org/freeipa/ticket/5838 >> >> LGTM, but please use 'UNKNOWN' as the default value, for consistency with >> ipalib.rpcserver code. > > Here you are. Thanks, ACK. Pushed to: master: 89cdf6ee1e796e5ba4c302a19da4862e18b99c4a ipa-4-2: da06be4ba891b1ad86af866fa4d9699bbaa5ab35 ipa-4-3: 2980e7851cba9bacefbc0adfab556634ec5fb6e6 -- Jan Cholasta From thozza at redhat.com Thu May 12 11:27:20 2016 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 12 May 2016 13:27:20 +0200 Subject: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release In-Reply-To: <0200bd34-1390-b096-8e18-a0b643e12dfa@redhat.com> References: <1dc06d62-9894-6e43-ccb5-0fe79b4db1c0@redhat.com> <0200bd34-1390-b096-8e18-a0b643e12dfa@redhat.com> Message-ID: <9626d811-6612-dec8-79f7-0a14d621c3c3@redhat.com> On 05/09/2016 04:30 PM, Petr Spacek wrote: > On 9.5.2016 16:25, Petr Spacek wrote: > > Hello, > > > > following patch should cover most misleading warnings produced by new code > > handling empty zones. > > > > If it is okay I will release version 9.0 with it. > > > > Please review it ASAP. Thank you very much! > > ... and here are patches :-) > ACK. I tested the changes and warning is now logged only if the empty zone is still loaded. In case the configuration changes after the empty zone is already unloaded, no message is logged. Other than that, the changes look good to me. Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Thu May 12 11:39:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 May 2016 13:39:41 +0200 Subject: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release In-Reply-To: <9626d811-6612-dec8-79f7-0a14d621c3c3@redhat.com> References: <1dc06d62-9894-6e43-ccb5-0fe79b4db1c0@redhat.com> <0200bd34-1390-b096-8e18-a0b643e12dfa@redhat.com> <9626d811-6612-dec8-79f7-0a14d621c3c3@redhat.com> Message-ID: On 12.5.2016 13:27, Tomas Hozza wrote: > On 05/09/2016 04:30 PM, Petr Spacek wrote: >> On 9.5.2016 16:25, Petr Spacek wrote: >>> Hello, >>> >>> following patch should cover most misleading warnings produced by new code >>> handling empty zones. >>> >>> If it is okay I will release version 9.0 with it. >>> >>> Please review it ASAP. Thank you very much! >> >> ... and here are patches :-) >> > ACK. > > I tested the changes and warning is now logged only if the empty zone is still loaded. In case the configuration changes after the empty zone is already unloaded, no message is logged. Other than that, the changes look good to me. Thanks, pushed to master: 210b6240d24a1e9dd778a5bd251ba2a3dc9fb5ab Bump NVR to 9.0. 3cd3da4d6de70a392d0ea64da674fbd1b8c39ae5 Update NEWS for upcoming 9.0 release. 64be537656310049ca4769ea05e728187370b415 Document new empty zone handling mechanism. 4a2ef2eb491596870cf1b7bdc12c3eb2cc0015f5 Do not log warning about empty zones which are already disabled or unloaded. 3232aa4f35850c5164e7ec0b9cc523e3cf7bdb5d Unload automatic empty zones only if conflicting forward zone has policy 'only'. -- Petr^2 Spacek From pvoborni at redhat.com Thu May 12 12:16:01 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 May 2016 14:16:01 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5732034E.5080405@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> Message-ID: <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> On 05/10/2016 05:50 PM, thierry bordaz wrote: > > > On 05/05/2016 03:44 PM, Petr Vobornik wrote: >> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>> Hello, >>> >>> I have been doing some tests/measures using >>> >>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>> >>> The tool creates a set of typical users/hosts/groups... to >>> import with a >>> ldapadd. >>> >>> I wrote down some finding in >>> >>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>> >>> I still have to do some cleanup around the performance but the >>> basic of a >>> possible improvement is to do provisioning in several steps >>> (disabling >>> plugins, provisioning, enabling plugin, running fixup tasks). >>> >>> Before going further in the design I wanted to share those ideas >>> and know if >>> it raise any concern. >>> >>> thanks >>> thierry >>> >> Hi Thierry, >> >> Thanks for the analysis. Very nice. >> >> Knowing this will help us suggesting workarounds also for old releases. >> >> Couple questions: >> >> Have you tested retrCL disabled with memberOf enabled. It seems that it >> would eliminate 550K adds and 0.8M searches. What would be the time >> improvement? >> >> Do you know what is the time when memberof is enabled but slapi-nis and >> retroCL are disabled? > The culprit of the performance issue is very likely related to SRCH > (internal) triggered by memberof. > > If retroCL is disabled and memberof enabled, #SRCH is 13.8M. > If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is > 14.8 > When all of them are enabled the #SRCH is 15M. > > You are right if retroCL is disabled the #ADD drops but it has no > significant effect on the duration. ok, thanks for the analysis > > Regarding the duration of the provisioning, values are not really stable > as performance of VM fluctuates. But as soon as memberof is enabled the > provisioning lasts > 4hours where the same provisioning lasts 6mins as > soon as memberof is disabled. > > I need to confirm the average time for internal searches but assuming > 1ms per SRCH it consumes >90% of the provisioning. > > >> >> From the text it was not clear to me, if you find or investigate >> possible improvements in memberof plugin which would improve the >> performance without stopping and starting DS. > As was discussed at mtg, have you tried if the DS restart is really necessary? And if it is required, what would be needed to not require restart. The workaround should be easy to use. -- Petr Vobornik From pvomacka at redhat.com Thu May 12 12:49:38 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 12 May 2016 14:49:38 +0200 Subject: [Freeipa-devel] [PATCH] 0011 webui: Offer OTP generation for host enrollment in the UI In-Reply-To: <3a1c38eb-2283-a7c4-fef3-5e5269cd127d@redhat.com> References: <56FD3B3C.9020307@redhat.com> <3a1c38eb-2283-a7c4-fef3-5e5269cd127d@redhat.com> Message-ID: On 05/11/2016 03:28 PM, Petr Vobornik wrote: > On 03/31/2016 04:59 PM, Pavel Vomacka wrote: >> Hello, >> >> This patch adds option to add host dialog which allows to show generated >> OTP. >> The patch also changes the way of informing user about success of adding >> host >> but only when the 'Generate OTP' option is checked. >> >> https://fedorahosted.org/freeipa/ticket/4602 > > The patch copy&pastes behavior of entity adder dialog buttons when the > purpose is to do additional stuff on success. IMHO it copies to much logic. > > Also the following method of redefining add handler is not very object > oriented: > that.get_button('add_and_edit').click = function() { > > Wouldn't it be better to move anonymous success handlers in > entity_adder_dialog to a class methods to achieve it. E.g: > > """ > click: function() { > that.hide_message(); > that.add( > function(data, text_status, xhr) { > that.added.notify([data], that); > that.close(); > var result = data.result.result; > that.show_edit_page(that.entity, result); > that.notify_success(data); > }, > that.on_error); > } > """ > to > """ > click: function() { > that.hide_message(); > that.add(that.on_add_success, that.on_error); > } > > that.on_add_success = function(data, text_status, xhr) { > that.added.notify([data], that); > that.close(); > var result = data.result.result; > that.show_edit_page(that.entity, result); > that.notify_success(data); > }; > > that.entity_adder_dialog_on_add_success = that.on_add_success; > > """ > > so in child class it would be overriden e.g. by: > > that.on_add_success = function(data, text_status, xhr) { > that.entity_adder_dialog_on_add_success(data, text_status, xhr); > // .. my new code > }; > > It follows the pattern as in other code. > > Other possible emthod is to implement in parent class > handle_notifications override point and then change calls of > that.notify_success(data); to that.handle_notifications(data, method); > Which could be overridden in child. > > Or probably my favorite: > entity_adder_dialog has 'added' event which is raised prior closing the > dialog (in 'add' and 'add and edit'). We could either register new event > handler which would to the stuff. It will need a way to distinguish > buttons. The button name/method could be added as addional param in the > base class: > that.added.notify([data, 'add'], that); > > Or a new event could be created if it is important to call it after > dialog is closed. > that.post_added = IPA.observer(); > that.post_added.notify([data, 'add'], that); > > dialog.post_added.attach(function(data, method) { > // do something; > }); > > Thank you for awesome explanation of how it should be done. I've chosen the last solution which you described. I added another parameter to the 'added' event and I also added init method which allows to register listener to 'added' event only once. Edited patch is attached. Pavel^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0011-2-Add-option-to-show-OTP-when-adding-host.patch Type: text/x-patch Size: 7474 bytes Desc: not available URL: From lkrispen at redhat.com Thu May 12 13:45:11 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 12 May 2016 15:45:11 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> Message-ID: <573488E7.7030103@redhat.com> On 05/12/2016 02:16 PM, Petr Vobornik wrote: > On 05/10/2016 05:50 PM, thierry bordaz wrote: >> >> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>> Hello, >>>> >>>> I have been doing some tests/measures using >>>> >>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>> >>>> The tool creates a set of typical users/hosts/groups... to >>>> import with a >>>> ldapadd. >>>> >>>> I wrote down some finding in >>>> >>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>> >>>> I still have to do some cleanup around the performance but the >>>> basic of a >>>> possible improvement is to do provisioning in several steps >>>> (disabling >>>> plugins, provisioning, enabling plugin, running fixup tasks). >>>> >>>> Before going further in the design I wanted to share those ideas >>>> and know if >>>> it raise any concern. >>>> >>>> thanks >>>> thierry >>>> >>> Hi Thierry, >>> >>> Thanks for the analysis. Very nice. >>> >>> Knowing this will help us suggesting workarounds also for old releases. >>> >>> Couple questions: >>> >>> Have you tested retrCL disabled with memberOf enabled. It seems that it >>> would eliminate 550K adds and 0.8M searches. What would be the time >>> improvement? >>> >>> Do you know what is the time when memberof is enabled but slapi-nis and >>> retroCL are disabled? >> The culprit of the performance issue is very likely related to SRCH >> (internal) triggered by memberof. >> >> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is >> 14.8 >> When all of them are enabled the #SRCH is 15M. >> >> You are right if retroCL is disabled the #ADD drops but it has no >> significant effect on the duration. > ok, thanks for the analysis > >> Regarding the duration of the provisioning, values are not really stable >> as performance of VM fluctuates. But as soon as memberof is enabled the >> provisioning lasts > 4hours where the same provisioning lasts 6mins as >> soon as memberof is disabled. >> >> I need to confirm the average time for internal searches but assuming >> 1ms per SRCH it consumes >90% of the provisioning. >> >> >>> From the text it was not clear to me, if you find or investigate >>> possible improvements in memberof plugin which would improve the >>> performance without stopping and starting DS. > As was discussed at mtg, have you tried if the DS restart is really > necessary? memberof plugin can be enabled and disabled while the server is running, BUT to achieve this the "enable-dynamic-plugins" feature has to be turned on. And then any enable/disable of a plugin would try to do it dynamically an dnot wait for the restart. And I think not all plugins are able to handle this, TomasB was once working on it for IPA plugins, but it was not completed as far as I know > > And if it is required, what would be needed to not require restart. > > The workaround should be easy to use. -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From mbabinsk at redhat.com Thu May 12 14:07:41 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 12 May 2016 16:07:41 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <20160509062557.kal42vxwur7obauc@redhat.com> References: <5707C9F2.8060903@redhat.com> <20160509062557.kal42vxwur7obauc@redhat.com> Message-ID: On 05/09/2016 08:26 AM, Alexander Bokovoy wrote: > On Fri, 06 May 2016, Martin Babinsky wrote: >> On 05/05/2016 02:58 PM, Milan Kub?k wrote: >>> On 04/08/2016 05:10 PM, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I have put together a draft [1] outlining the effort to reimplement >>>> the handling of Kerberos principals in both backend and frontend >>>> layers of FreeIPA so that we may have multiple aliases per user, host >>>> or service and thus implement stuff like >>>> https://fedorahosted.org/freeipa/ticket/3961 and >>>> https://fedorahosted.org/freeipa/ticket/5413 . >>>> >>>> Since much of the plumbing was already implemented,[2] the document >>>> mainly describes what the patches do. Some parts required by other use >>>> cases may be missing so please point these out. >>>> >>>> I would also be happy if you could correct all factual inacurracies, I >>>> did research on this issue a long time ago and my knowledge turned a >>>> bit rusty. >>>> >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>>> [2] >>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>>> >>>> >>> >>> Hi! >>> >>> I went through the design document and the related email thread here on >>> the list and I have few questions: >>> >>> 1. Is there any progress on what's to happen if MODRDN would colide with >>> an existing alias on a different entry? >>> >> Both krbPrincipalName and krbCanonicalName will be guarded by >> uniqueness plugin so this should raise an error in the DS backend. >> >> It will need some more investigation though and will probably warrant >> a separate test case in the future test plan. >> >>> 2. How does this RFE change the behavior of stage user plugin? Is the >>> principal (as in the canonical name) assigned at this stage of user >>> lifetime? >>> >> I didn't think about staged users when designing/doing patches. Thank >> you for pointing this out. The principal name is assigned when >> creating the staged user and it is also checked during activation and >> again added if it is not present. We will need to handle both of these >> cases. I will update the design to reflect this. >> >>> 3. Will there be any constraints on what string can be used as an alias? >>> (The document mentions email address as one use case) >>> >> The e-mail case can be tricky, since having two '@' in the principal >> name can break parsing/unparsing of principal name in KDB DAL. We will >> likely have to implement some sort of escaping to handle this >> correctly. This should be discussed in more detail with >> Simo/Alexander/Sumit. > We should not allow anything after @ not belonging to the list of > realm domains. We also will need to extend realm domains to include > non-domain-based UPN suffixes. This actually flies close to what I need > to finish in my AD trust UPN patches, so I need to make sure we have the > same approach there. > Does this mean that we would not be able to implement e-mail as principal alias [1]? >> >>> 4. Will this RFE have any impact on AD trust (possibility of cross realm >>> routing, RFC 6806 section 9) >>> >> >> IIRC there should be no impact on trusts. > We should never allow to specify alias from the realm we don't own. This > means the code needs to look into the namespaces associated with any of > the trusted domains and reject them. > So if I understand correctly we should reject tickets incoming from trusted domains if they do not contain canonical principal name (i.e. UPN)? [1] https://fedorahosted.org/freeipa/ticket/5413 -- Martin^3 Babinsky From mkosek at redhat.com Thu May 12 14:14:28 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 May 2016 16:14:28 +0200 Subject: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile In-Reply-To: <20160511225606.GY1237@dhcp-40-8.bne.redhat.com> References: <20160511092248.GV1237@dhcp-40-8.bne.redhat.com> <6ac74460-766a-8e0c-30fd-e90df46d28e6@redhat.com> <20160511130418.GW1237@dhcp-40-8.bne.redhat.com> <02b20cfc-f2b0-1c14-1a07-6d1a2280fb5f@redhat.com> <20160511225606.GY1237@dhcp-40-8.bne.redhat.com> Message-ID: <689e0cf1-d7a1-f91c-9129-2dd20df3edfd@redhat.com> On 05/12/2016 12:56 AM, Fraser Tweedale wrote: > On Wed, May 11, 2016 at 04:36:34PM +0200, Jan Cholasta wrote: >> On 11.5.2016 15:04, Fraser Tweedale wrote: >>> On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote: ... >>>> 3) I would rather avoid adding new commands just to work around bugs. IMO >>>> "certprofile-import caIPAserviceCert >>>> /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this >>>> case. >>>> >>> As discussed above, I'm afraid it is not, unless users manually do >>> the substitutions. If we provide some code to do the substitutions, >>> we have essentially reach what I have proposed. >>> >>> Other suggestions are welcome. >>> >>> BTW, there is another option I did not already mention: do nothing >>> in code, and help users on a case-by-case basis / point them to a >>> guide / KB article? >> >> This option is my favorite :-) (If automatic fix during upgrade is indeed >> out of the picture.) >> > Martin, if the profile is incorrect, do we have to fix it > automatically? What are our obligations / customer expectations > here? I would love to hear customer expectations, but in that case you should ask the users/customers, not me :-) But having documented procedure in a KB/wiki article how to fix a broken profile seems as a good enough for me, we can build the API command later if we see a pressing need. Martin From lkrispen at redhat.com Thu May 12 14:16:42 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 12 May 2016 16:16:42 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <573488E7.7030103@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> Message-ID: <5734904A.1090905@redhat.com> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: > > On 05/12/2016 02:16 PM, Petr Vobornik wrote: >> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>> >>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>> Hello, >>>>> >>>>> I have been doing some tests/measures using >>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>> >>>>> The tool creates a set of typical users/hosts/groups... to >>>>> import with a >>>>> ldapadd. >>>>> >>>>> I wrote down some finding in >>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>> >>>>> I still have to do some cleanup around the performance but the >>>>> basic of a >>>>> possible improvement is to do provisioning in several steps >>>>> (disabling >>>>> plugins, provisioning, enabling plugin, running fixup tasks). >>>>> >>>>> Before going further in the design I wanted to share those >>>>> ideas >>>>> and know if >>>>> it raise any concern. >>>>> >>>>> thanks >>>>> thierry >>>>> >>>> Hi Thierry, >>>> >>>> Thanks for the analysis. Very nice. >>>> >>>> Knowing this will help us suggesting workarounds also for old >>>> releases. >>>> >>>> Couple questions: >>>> >>>> Have you tested retrCL disabled with memberOf enabled. It seems >>>> that it >>>> would eliminate 550K adds and 0.8M searches. What would be the time >>>> improvement? >>>> >>>> Do you know what is the time when memberof is enabled but slapi-nis >>>> and >>>> retroCL are disabled? >>> The culprit of the performance issue is very likely related to SRCH >>> (internal) triggered by memberof. >>> >>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>> If retroCL is disabled, slapi-nis disabled and memberof enabled >>> #SRCH is >>> 14.8 >>> When all of them are enabled the #SRCH is 15M. >>> >>> You are right if retroCL is disabled the #ADD drops but it has no >>> significant effect on the duration. >> ok, thanks for the analysis >> >>> Regarding the duration of the provisioning, values are not really >>> stable >>> as performance of VM fluctuates. But as soon as memberof is enabled the >>> provisioning lasts > 4hours where the same provisioning lasts 6mins as >>> soon as memberof is disabled. >>> >>> I need to confirm the average time for internal searches but assuming >>> 1ms per SRCH it consumes >90% of the provisioning. >>> >>> >>>> From the text it was not clear to me, if you find or investigate >>>> possible improvements in memberof plugin which would improve the >>>> performance without stopping and starting DS. >> As was discussed at mtg, have you tried if the DS restart is really >> necessary? > memberof plugin can be enabled and disabled while the server is > running, BUT > to achieve this the "enable-dynamic-plugins" feature has to be turned > on. And then any enable/disable of a plugin would try to do it > dynamically an dnot wait for the restart. > And I think not all plugins are able to handle this, TomasB was once > working on it for IPA plugins, but it was not completed as far as I know but enabling dynamic plugins can be done without restart, so what can be done is. - enable dynamic plugins - disable memberof - do some work - enable memberof - disable dynamic plugins >> >> And if it is required, what would be needed to not require restart. >> >> The workaround should be easy to use. > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From mbasti at redhat.com Thu May 12 14:16:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 May 2016 16:16:40 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> Message-ID: On 12.05.2016 11:01, Martin Basti wrote: > > > On 11.05.2016 09:41, Martin Basti wrote: >> >> >> On 10.05.2016 18:56, Petr Spacek wrote: >>> On 10.5.2016 15:38, Petr Spacek wrote: >>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>> >>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>> >>>>>>>>> Patches attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>> 00:00:00 2001 >>>>>>>>> From: Martin Basti >>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>>> privileges >>>>>>>>> >>>>>>>>> DNS privileges are important for handling DNS locations which >>>>>>>>> can be >>>>>>>>> created without DNS servers in IPA topology. We will also need >>>>>>>>> this >>>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>>> Seems reasonable, ACK. >>>>>>>> >>>>>>>> >>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>> 00:00:00 2001 >>>>>>>>> From: Martin Basti >>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>> objectclasses >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>> --- >>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>> index >>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>> booleanMatch >>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>> v4.1' ) >>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>> caseIgnoreIA5Match >>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE >>>>>>>>> SYNTAX >>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>> 'ipaLocation' DESC >>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>> SYNTAX >>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch >>>>>>>>> SYNTAX >>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>> 'idnsRecord' DESC 'dns >>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( >>>>>>>>> cn $ >>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord >>>>>>>>> $ a6Record $ >>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>> mXRecord $ >>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord >>>>>>>>> $ KeyRecord >>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord >>>>>>>>> $ dNameRecord >>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>> IPSECKEYRecord $ >>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' >>>>>>>>> DESC 'Zone >>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>> idnsSOAmName $ >>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>> idnsAllowQuery $ >>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>> idnsForwarders $ >>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>> 'ipaDNSZone' SUP top >>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>> idnsZoneActive ) >>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>> 'idnsSecKey' DESC 'DNSSEC >>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>> idnsSecKeyCreated $ >>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>> idnsName ) MAY ( >>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>> there will not be >>>>>>>> any other object class on the location object (at least not in the >>>>>>>> beginning). >>>>>>>> >>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>> >>>>>>>> >>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>> 00:00:00 2001 >>>>>>>>> From: Martin Basti >>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>> >>>>>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>>>>> prototypes and does not provide any information about server >>>>>>>>> (will be >>>>>>>>> done later) >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>> --- >>>>>>>>> ACI.txt | 8 ++ >>>>>>>>> API.txt | 59 ++++++++++++++ >>>>>>>>> VERSION | 4 +- >>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>> [...] >>>>>>>> >>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>> index >>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/VERSION >>>>>>>>> +++ b/VERSION >>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>> # # >>>>>>>>> ######################################################## >>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>> Needs rebase. >>>>>>>> >>>>>>>> >>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>> index >>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>> objectClass: top >>>>>>>>> cn: etc >>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>> +changetype: add >>>>>>>>> +objectClass: nsContainer >>>>>>>>> +objectClass: top >>>>>>>>> +cn: locations >>>>>>>>> + >>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>> changetype: add >>>>>>>>> objectClass: nsContainer >>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>> b/install/updates/37-locations.update >>>>>>>>> index >>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>> +default: objectClass: nsContainer >>>>>>>>> +default: objectClass: top >>>>>>>>> +default: cn: locations >>>>>>>> Ok. >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>> index >>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>> [...] >>>>>>>>> +__doc__ = _(""" >>>>>>>>> +IPA locations >>>>>>>>> +""") + _(""" >>>>>>>>> +Manipulate with DNS locations >>>>>>>> IMHO "with" should be omited. [...] >>>>>>>> >>>>>>>> >>>>>>>>> + at register() >>>>>>>>> +class location(LDAPObject): >>>>>>>>> + """ >>>>>>>>> + IPA locations >>>>>>>>> + """ >>>>>>>> [...] >>>>>>>> >>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>> + managed_permissions = { >>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>> + }, >>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>> + }, >>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>> + }, >>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>> + }, >>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>> + 'description', >>>>>>>>> + }, >>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>> + }, >>>>>>>>> + } >>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>> IMHO this is >>>>>>>> okay. >>>>>>>> Less renames we support the better. >>>>>>>> >>>>>>>> >>>>>>>>> + >>>>>>>>> + takes_params = ( >>>>>>>>> + DNSNameParam( >>>>>>>>> + 'idnsname', >>>>>>>>> + cli_name='name', >>>>>>>>> + primary_key=True, >>>>>>>>> + label=_('Location name'), >>>>>>>>> + doc=_('IPA location name'), >>>>>>>>> + # dns name must be relative, we will put it into >>>>>>>>> middle of >>>>>>>>> + # location domain name for location records >>>>>>>>> + only_relative=True, >>>>>>>>> + ), >>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>> labels work - >>>>>>>> but >>>>>>>> this should automagically work as long as we are handling DNS >>>>>>>> names using >>>>>>>> proper data types (not as strings). >>>>>>>> >>>>>>>> >>>>>>>>> + Str( >>>>>>>>> + 'description?', >>>>>>>>> + label=_('Description'), >>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>> + ), >>>>>>>> After discussion with Honza we will keep description as >>>>>>>> single-value in the >>>>>>>> IPA framework and ignore that description attribute is >>>>>>>> multi-value in LDAP. >>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> + at register() >>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>>> This should say 'Modify description' because nothing else can >>>>>>>> be modified. >>>>>>>> More specific text would hopefully stop some people from >>>>>>>> looking for rename >>>>>>>> options. >>>>>>> I disagree, this is general description about the modify >>>>>>> command, see >>>>>>> privilege-add it is the same as I made. I can see in future that >>>>>>> we will >>>>>>> forgot to update description of command if we add something new >>>>>>> there. >>>>>> This is really an invalid argument. >>>>>> >>>>>> "We must not touch XYZ because its documentation might become >>>>>> obsolete in >>>>>> future if we forget to update it!" :-) >>>>>> >>>>> How about inconsistency with description of older commands? I >>>>> don't think that >>>>> command description should describe attributes that are allowed to >>>>> change. >>>>> Allowed attributes are shown in --help output >>>> I do not agree but push whatever variant you like, it costed too >>>> much already. >>> NACK anyway. ipa-dns-install screams if you install a server without >>> DNS and >>> run ipa-dns-install later on: >>> >>> The log contains this: >>> >>> add objectClass: >>> top >>> groupofnames >>> nestedgroup >>> add cn: >>> DNS Administrators >>> add description: >>> DNS Administrators >>> adding new entry "cn=DNS >>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>> >>> >>> >>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>> >>> ) >>> SASL/EXTERNAL authentication started >>> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>> SASL SSF: 0 >>> ldap_add: Already exists (68) >>> >>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>> -Y >>> EXTERNAL' returned non-zero exit status 68 >>> >> Well I cannot reproduce it, this should be resolved by patch 473 >> > > Updated patches attached > > I found that IDNA did not work with previous version, fixed + IDNA > tests added > > Fixed here, I sent wrong patches before -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0473.3-DNS-Locations-Always-create-DNS-related-privileges.patch Type: text/x-patch Size: 4774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0474.3-DNS-Locations-add-new-attributes-and-objectclasses.patch Type: text/x-patch Size: 4065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0475.3-DNS-Locations-location-commands.patch Type: text/x-patch Size: 14464 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0476.3-DNS-Locations-API-tests.patch Type: text/x-patch Size: 9331 bytes Desc: not available URL: From pspacek at redhat.com Thu May 12 14:17:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 May 2016 16:17:35 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <572228FA.6040007@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> Message-ID: <16cdb8b8-bb50-c633-2eef-326d7367f40c@redhat.com> On 28.4.2016 17:15, Petr Spacek wrote: > On 28.4.2016 14:52, Abhijeet Kasurde wrote: >> Hi Petr, >> >> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>> Hello, >>> >>> ipa-nis-manage: add status option >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>> >>> >>> >> Can you reword the error message here as well ? >> >> if len(args) != 1: >> sys.exit("You must specify one action, either enable or disable") >> >> Thanks, >> Abhijeet Kasurde > > Good catch! Please review this, thanks. -- Petr^2 Spacek From mbasti at redhat.com Thu May 12 14:34:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 May 2016 16:34:39 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA Message-ID: Patch attached. https://fedorahosted.org/freeipa/ticket/5868 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0477-Upgrade-always-start-CA.patch Type: text/x-patch Size: 2005 bytes Desc: not available URL: From lhellebr at redhat.com Thu May 12 16:28:42 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Thu, 12 May 2016 18:28:42 +0200 Subject: [Freeipa-devel] URI in HBAC - code In-Reply-To: <5720BFDD.7010403@redhat.com> References: <571E1219.9060100@redhat.com> <571F5C36.7090803@redhat.com> <20160426131637.GA7871@redhat.com> <571F739C.1080706@redhat.com> <5720BFDD.7010403@redhat.com> Message-ID: <5734AF3A.6030400@redhat.com> On 04/27/2016 03:34 PM, Luk?? Hellebrandt wrote: > SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac > Apache module: https://github.com/lhellebr/mod_hbacauthz_pam > FreeIPA: http://pastebin.com/X6H9BTwk > > On 04/26/2016 03:56 PM, Petr Spacek wrote: >> On 26.4.2016 15:16, Jan Pazdziora wrote: >>> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote: >>>>>> >>>>>> * For backwards compatibility, lack of URI in request means any URI is >>>>>> matched (as described in the design document). Is it a good idea? Any >>>>>> other solution? >>>>> >>>>> For other attributes in HBAC rules, the lack of a value means nothing is >>>>> matched. To match anything, you have to set "${attribute}category" to "all". I >>>>> would prefer if URI matching was consistent with this, if it's possible. >>>> >>>> My understanding is that requests lacking URI parameter should not match any >>>> HBAC rules with non-empty URI. This will be backwards compatible because old >>>> clients will simply ignore new rules which cannot be evaluated properly anyway >>>> (for lack of information in client's request). >>> >>> The problem is that old clients will not ack for the new attributes >>> (they have no idea they should ask for them), so they will only see >>> parts of the HBAC rules. >>> >>> So the question is -- what is the correct way to make sure that old >>> clients (that would not ask for the new attributes) are not served >>> any rules that have those new attributes set? >>> >>>>> BTW what is the reason to split URIs into separate fields? If it's just case >>>>> sensitivity, I would like to point out that you can switch case sensitivity on >>>>> and off in the middle of a Perl regex using "(?i)" and "(?-i)". >>>> >>>> Personally I would rather see host+scheme+port split into separate attributes. >>>> That would allow reporting like 'give me all rules for FTP' etc. without >>>> substring magic. >>>> >>>> And yes, I agree with Honza that multiple values should be evaluated as >>>> logical OR. >>>> >>>> E.g. >>>> >>>> schemes: {http, https, ftp, ftps} >>>> URI: /home/pspacek >>>> host: any >>>> allow: pspacek >>>> should grant user pspacek access to directory /home/pspacek on any host as >>>> long as the scheme is http/https/ftp/ftps. >>> >>> So you propose cartesian product of the schemes and URI attributes >>> to be used? >> >> Yes. >> >> >> Before we can discuss this further we need to see current LDAP schema and >> code. Lukas, please share the code with us. >> > > Added a patch for backwards compatibility using different objectClass for rules containing some of the new attributes: SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac FreeIPA: attached patch file (works together with the previously submitted patch) -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-new-objectClass-for-backwards-compatibility.patch Type: text/x-patch Size: 10618 bytes Desc: not available URL: From rcritten at redhat.com Thu May 12 17:48:52 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 May 2016 13:48:52 -0400 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <571F5D4A.7060003@redhat.com> References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> <5719E7AC.5020908@redhat.com> <571A0920.5020406@redhat.com> <571F5D4A.7060003@redhat.com> Message-ID: <5734C204.30701@redhat.com> Martin Basti wrote: > > > On 22.04.2016 13:21, David Kupka wrote: >> On 22/04/16 10:58, Martin Basti wrote: >>> >>> >>> On 21.04.2016 09:17, Martin Basti wrote: >>>> >>>> >>>> On 20.04.2016 16:57, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5281 >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> selfNACK >>>> >>>> >>> Updated patch attached. >>> >>> >>> >> Works for me, ACK. >> > pushed to master: > * fe2ce02a6f7664e377c367e16e9c2e1ad960c9d7 Performace: don't download > password attributes in host/user-find > It occurs to me, won't this break the UI somewhat. Isn't Enrolled one of the attributes on the default host page. Won't this show all hosts as unenrolled? rob From npmccallum at redhat.com Thu May 12 21:13:32 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 May 2016 17:13:32 -0400 Subject: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators In-Reply-To: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> References: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> Message-ID: <1463087612.2785.10.camel@redhat.com> On Wed, 2016-05-11 at 13:08 +0200, Pavel Vomacka wrote: > Hi, > > the patch adds webui part for authentication indicators. > > Ticket: https://fedorahosted.org/freeipa/ticket/5872 The otp option displays as: OTP. The radius option displays as: Radius. However, both are acronyms. The capitalization should be consistent. From npmccallum at redhat.com Thu May 12 21:33:26 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 May 2016 17:33:26 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1463088806.2785.23.camel@redhat.com> On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote: > > This series of patches implements authentication indicator > > insertion, > > evaluation and management in FreeIPA. Besides these patches, two > > other > > patches are needed to round out support. > > > > First, we need a UI patch:?https://fedorahosted.org/freeipa/ticket/ > > 5872 > > > > Second, we need a SSSD patch to handle the new case where multiple > > responders are set (when either 1FA or 2FA can be used). > > I've already some initial work done here and will continue with your > patches. > > > > > Please note that the last patch in this series (0093) is untested > > and > > simply represents my desire to get these patches off of my hard > > disk > > before I take a long weekend. This patch also requires mrogers' > > patch > > 0001 (already merged to master). > > > > Also worthy of note is the need for an OID for the authentication > > control. Hopefully Simo can assign this after we agree that this > > control method is sufficient. One question I had was whether or not > > it > > would be possible to send the control only on UNIX sockets (0089; > > report_auth_method()). > > > > Please review the approaches taken here. I plan to hit this hard on > > Monday. > > I'm on a conference next week and currently busy preparing my > presentation. I will give you feedback in the following week. Thanks! The attached patches offer the latest version of the work. The only major outstanding item that I see is OID assignment (which we can do just before committing). I have tested the full stack both for appropriate approvals and denials across all possible scenarios. In short it works. The easiest way to test this is as following: # After Clean Install of FreeIPA $ kinit admin # Add a service allowed by either 1FA or 2FA $ ipa service-add ANY/ipa.example.com $ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab # Add a service allowed only by 2FA $ ipa service-add OTP/ipa.example.com --auth-ind=otp $ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab # Add the test user $ ipa user-add test --user-auth-type=otp --user-auth-type=password $ ipa passwd test $ kinit test # Try to get tickets for the services $ kvno ANY/ipa.example.com # Expected success $ kvno OTP/ipa.example.com # Expected failure # Add a token and login with 2FA $ ipa otptoken-add $ kinit -T test # Log in with 2FA # Try to get tickets for the services $ kvno ANY/ipa.example.com # Expected success $ kvno OTP/ipa.example.com # Expected success -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 6254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Enable-authentication-indicators-for-OTP-and-RADIUS.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Return-password-only-preauth-if-passwords-are-allowe.patch Type: text/x-patch Size: 1676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Ensure-that-ipa-otpd-bind-auths-validate-an-OTP.patch Type: text/x-patch Size: 5568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rename-syncreq.-ch-to-otpctrl.-ch.patch Type: text/x-patch Size: 4934 bytes Desc: not available URL: From mbasti at redhat.com Fri May 13 06:17:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 May 2016 08:17:53 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <5734C204.30701@redhat.com> References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> <5719E7AC.5020908@redhat.com> <571A0920.5020406@redhat.com> <571F5D4A.7060003@redhat.com> <5734C204.30701@redhat.com> Message-ID: On 12.05.2016 19:48, Rob Crittenden wrote: > Martin Basti wrote: >> >> >> On 22.04.2016 13:21, David Kupka wrote: >>> On 22/04/16 10:58, Martin Basti wrote: >>>> >>>> >>>> On 21.04.2016 09:17, Martin Basti wrote: >>>>> >>>>> >>>>> On 20.04.2016 16:57, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5281 >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> >>>>> selfNACK >>>>> >>>>> >>>> Updated patch attached. >>>> >>>> >>>> >>> Works for me, ACK. >>> >> pushed to master: >> * fe2ce02a6f7664e377c367e16e9c2e1ad960c9d7 Performace: don't download >> password attributes in host/user-find >> > > It occurs to me, won't this break the UI somewhat. Isn't Enrolled one > of the attributes on the default host page. Won't this show all hosts > as unenrolled? > > rob Hi Rob, how exactly is webUI broken? I tried host section and it works. IIUC the Web UI uses just host-find --pkey-only, which is not affected by this change. For additional details webUI call host-show for each listed entry Martin From mkosek at redhat.com Fri May 13 07:26:17 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 May 2016 09:26:17 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5734904A.1090905@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> Message-ID: On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: > > On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >> >> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>> >>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>> Hello, >>>>>> >>>>>> I have been doing some tests/measures using >>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>> >>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>> import with a >>>>>> ldapadd. >>>>>> >>>>>> I wrote down some finding in >>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>> >>>>>> >>>>>> I still have to do some cleanup around the performance but the >>>>>> basic of a >>>>>> possible improvement is to do provisioning in several steps >>>>>> (disabling >>>>>> plugins, provisioning, enabling plugin, running fixup tasks). >>>>>> >>>>>> Before going further in the design I wanted to share those ideas >>>>>> and know if >>>>>> it raise any concern. >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> >>>>> Hi Thierry, >>>>> >>>>> Thanks for the analysis. Very nice. >>>>> >>>>> Knowing this will help us suggesting workarounds also for old releases. >>>>> >>>>> Couple questions: >>>>> >>>>> Have you tested retrCL disabled with memberOf enabled. It seems that it >>>>> would eliminate 550K adds and 0.8M searches. What would be the time >>>>> improvement? >>>>> >>>>> Do you know what is the time when memberof is enabled but slapi-nis and >>>>> retroCL are disabled? >>>> The culprit of the performance issue is very likely related to SRCH >>>> (internal) triggered by memberof. >>>> >>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is >>>> 14.8 >>>> When all of them are enabled the #SRCH is 15M. >>>> >>>> You are right if retroCL is disabled the #ADD drops but it has no >>>> significant effect on the duration. >>> ok, thanks for the analysis >>> >>>> Regarding the duration of the provisioning, values are not really stable >>>> as performance of VM fluctuates. But as soon as memberof is enabled the >>>> provisioning lasts > 4hours where the same provisioning lasts 6mins as >>>> soon as memberof is disabled. >>>> >>>> I need to confirm the average time for internal searches but assuming >>>> 1ms per SRCH it consumes >90% of the provisioning. >>>> >>>> >>>>> From the text it was not clear to me, if you find or investigate >>>>> possible improvements in memberof plugin which would improve the >>>>> performance without stopping and starting DS. >>> As was discussed at mtg, have you tried if the DS restart is really >>> necessary? >> memberof plugin can be enabled and disabled while the server is running, BUT >> to achieve this the "enable-dynamic-plugins" feature has to be turned on. And >> then any enable/disable of a plugin would try to do it dynamically an dnot >> wait for the restart. >> And I think not all plugins are able to handle this, TomasB was once working >> on it for IPA plugins, but it was not completed as far as I know > but enabling dynamic plugins can be done without restart, so what can be done is. > - enable dynamic plugins > - disable memberof > - do some work > - enable memberof > - disable dynamic plugins Please see https://fedorahosted.org/freeipa/ticket/4203#comment:9 I do not think this will be that easy. We would first need to invest into updating FreeIPA plugins to work with dynamic plugins setting and then we could do things alike above. It looks like that for FreeIPA 4.4, we will need to live with DS restart unless there is some workaround... Martin From pspacek at redhat.com Fri May 13 07:42:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 May 2016 09:42:50 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> Message-ID: On 13.5.2016 09:26, Martin Kosek wrote: > On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >> >> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>> >>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>> >>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I have been doing some tests/measures using >>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>> >>>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>>> import with a >>>>>>> ldapadd. >>>>>>> >>>>>>> I wrote down some finding in >>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>> >>>>>>> >>>>>>> I still have to do some cleanup around the performance but the >>>>>>> basic of a >>>>>>> possible improvement is to do provisioning in several steps >>>>>>> (disabling >>>>>>> plugins, provisioning, enabling plugin, running fixup tasks). >>>>>>> >>>>>>> Before going further in the design I wanted to share those ideas >>>>>>> and know if >>>>>>> it raise any concern. >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>>> >>>>>> Hi Thierry, >>>>>> >>>>>> Thanks for the analysis. Very nice. >>>>>> >>>>>> Knowing this will help us suggesting workarounds also for old releases. >>>>>> >>>>>> Couple questions: >>>>>> >>>>>> Have you tested retrCL disabled with memberOf enabled. It seems that it >>>>>> would eliminate 550K adds and 0.8M searches. What would be the time >>>>>> improvement? >>>>>> >>>>>> Do you know what is the time when memberof is enabled but slapi-nis and >>>>>> retroCL are disabled? >>>>> The culprit of the performance issue is very likely related to SRCH >>>>> (internal) triggered by memberof. >>>>> >>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is >>>>> 14.8 >>>>> When all of them are enabled the #SRCH is 15M. >>>>> >>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>> significant effect on the duration. >>>> ok, thanks for the analysis >>>> >>>>> Regarding the duration of the provisioning, values are not really stable >>>>> as performance of VM fluctuates. But as soon as memberof is enabled the >>>>> provisioning lasts > 4hours where the same provisioning lasts 6mins as >>>>> soon as memberof is disabled. >>>>> >>>>> I need to confirm the average time for internal searches but assuming >>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>> >>>>> >>>>>> From the text it was not clear to me, if you find or investigate >>>>>> possible improvements in memberof plugin which would improve the >>>>>> performance without stopping and starting DS. >>>> As was discussed at mtg, have you tried if the DS restart is really >>>> necessary? >>> memberof plugin can be enabled and disabled while the server is running, BUT >>> to achieve this the "enable-dynamic-plugins" feature has to be turned on. And >>> then any enable/disable of a plugin would try to do it dynamically an dnot >>> wait for the restart. >>> And I think not all plugins are able to handle this, TomasB was once working >>> on it for IPA plugins, but it was not completed as far as I know >> but enabling dynamic plugins can be done without restart, so what can be done is. >> - enable dynamic plugins >> - disable memberof >> - do some work >> - enable memberof >> - disable dynamic plugins > > Please see > https://fedorahosted.org/freeipa/ticket/4203#comment:9 > I do not think this will be that easy. We would first need to invest into > updating FreeIPA plugins to work with dynamic plugins setting and then we could > do things alike above. > > It looks like that for FreeIPA 4.4, we will need to live with DS restart unless > there is some workaround... One more thing: How does it affect topologies with replicas? I might be wrong, but if memberOf is always computed locally then we have to disable it on *all* replicas. If we disabled it only on one replica and not others, the chosen replica would be way faster than rest of the topology and I'm not sure what would happen later on. Thierry, Ludwig, can you comment on this? -- Petr^2 Spacek From lkrispen at redhat.com Fri May 13 08:18:15 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 13 May 2016 10:18:15 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> Message-ID: <57358DC7.9030905@redhat.com> On 05/13/2016 09:42 AM, Petr Spacek wrote: > On 13.5.2016 09:26, Martin Kosek wrote: >> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have been doing some tests/measures using >>>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>>> >>>>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>>>> import with a >>>>>>>> ldapadd. >>>>>>>> >>>>>>>> I wrote down some finding in >>>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>>> >>>>>>>> >>>>>>>> I still have to do some cleanup around the performance but the >>>>>>>> basic of a >>>>>>>> possible improvement is to do provisioning in several steps >>>>>>>> (disabling >>>>>>>> plugins, provisioning, enabling plugin, running fixup tasks). >>>>>>>> >>>>>>>> Before going further in the design I wanted to share those ideas >>>>>>>> and know if >>>>>>>> it raise any concern. >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>>> >>>>>>> Hi Thierry, >>>>>>> >>>>>>> Thanks for the analysis. Very nice. >>>>>>> >>>>>>> Knowing this will help us suggesting workarounds also for old releases. >>>>>>> >>>>>>> Couple questions: >>>>>>> >>>>>>> Have you tested retrCL disabled with memberOf enabled. It seems that it >>>>>>> would eliminate 550K adds and 0.8M searches. What would be the time >>>>>>> improvement? >>>>>>> >>>>>>> Do you know what is the time when memberof is enabled but slapi-nis and >>>>>>> retroCL are disabled? >>>>>> The culprit of the performance issue is very likely related to SRCH >>>>>> (internal) triggered by memberof. >>>>>> >>>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is >>>>>> 14.8 >>>>>> When all of them are enabled the #SRCH is 15M. >>>>>> >>>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>>> significant effect on the duration. >>>>> ok, thanks for the analysis >>>>> >>>>>> Regarding the duration of the provisioning, values are not really stable >>>>>> as performance of VM fluctuates. But as soon as memberof is enabled the >>>>>> provisioning lasts > 4hours where the same provisioning lasts 6mins as >>>>>> soon as memberof is disabled. >>>>>> >>>>>> I need to confirm the average time for internal searches but assuming >>>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>>> >>>>>> >>>>>>> From the text it was not clear to me, if you find or investigate >>>>>>> possible improvements in memberof plugin which would improve the >>>>>>> performance without stopping and starting DS. >>>>> As was discussed at mtg, have you tried if the DS restart is really >>>>> necessary? >>>> memberof plugin can be enabled and disabled while the server is running, BUT >>>> to achieve this the "enable-dynamic-plugins" feature has to be turned on. And >>>> then any enable/disable of a plugin would try to do it dynamically an dnot >>>> wait for the restart. >>>> And I think not all plugins are able to handle this, TomasB was once working >>>> on it for IPA plugins, but it was not completed as far as I know >>> but enabling dynamic plugins can be done without restart, so what can be done is. >>> - enable dynamic plugins >>> - disable memberof >>> - do some work >>> - enable memberof >>> - disable dynamic plugins >> Please see >> https://fedorahosted.org/freeipa/ticket/4203#comment:9 >> I do not think this will be that easy. We would first need to invest into >> updating FreeIPA plugins to work with dynamic plugins setting and then we could >> do things alike above. >> >> It looks like that for FreeIPA 4.4, we will need to live with DS restart unless >> there is some workaround... couldn't the scenario I outline above with enabling dynamic plugins only temporary work, are there any attempts to enable/disable plugins during provisioning ? If that would be the case that would also require a restart > One more thing: > > How does it affect topologies with replicas? > > I might be wrong, but if memberOf is always computed locally then we have to > disable it on *all* replicas. > > If we disabled it only on one replica and not others, the chosen replica would > be way faster than rest of the topology and I'm not sure what would happen > later on. good point. we exclude memberof from replication as it is regenerated on every server, so each replica would suffer from the performance problem > > Thierry, Ludwig, can you comment on this? > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From abokovoy at redhat.com Fri May 13 10:07:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 May 2016 13:07:55 +0300 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: References: <5707C9F2.8060903@redhat.com> <20160509062557.kal42vxwur7obauc@redhat.com> Message-ID: <20160513100755.hqrw5mqbfjm46c7l@redhat.com> On Thu, 12 May 2016, Martin Babinsky wrote: >>We should not allow anything after @ not belonging to the list of >>realm domains. We also will need to extend realm domains to include >>non-domain-based UPN suffixes. This actually flies close to what I need >>to finish in my AD trust UPN patches, so I need to make sure we have the >>same approach there. >> > >Does this mean that we would not be able to implement e-mail as >principal alias [1]? Why? I have not said that. I have said that you should not be able to specify UPN with a suffix that does not belong to us. I don't want us to allow to have Kerberos principals aliased to a trusted forest namespaces as this is violation of a forest trust. >>>>4. Will this RFE have any impact on AD trust (possibility of cross realm >>>>routing, RFC 6806 section 9) >>>> >>> >>>IIRC there should be no impact on trusts. >>We should never allow to specify alias from the realm we don't own. This >>means the code needs to look into the namespaces associated with any of >>the trusted domains and reject them. >> > >So if I understand correctly we should reject tickets incoming from >trusted domains if they do not contain canonical principal name (i.e. >UPN)? Again, no, this is not what I said. For UPNs from trusted domains I already have code to detect them and issue correct referral for clients to go to the proper KDC. -- / Alexander Bokovoy From ldoudova at redhat.com Fri May 13 11:08:29 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 13 May 2016 13:08:29 +0200 Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set Message-ID: <5735B5AD.9050803@redhat.com> Patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0013-Test-Maximum-username-length-higher-than-255-cannot-.patch Type: text/x-patch Size: 1776 bytes Desc: not available URL: From mkosek at redhat.com Fri May 13 11:32:11 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 May 2016 13:32:11 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations Message-ID: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Hello, As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat employee, which of course does not mean he cannot contribute to the FreeIPA project, but that he won't have as much time for contributions as previously. One of Tomas' responsibilities was taking care of FreeIPA translations (Translation Maintainer role). As far as I know, there 2 main tasks associated with the Translation Maintainer role: 1) Periodically uploading new upstream strings to the FreeIPA translation platform of choice, which is the Fedora Zanata instance: https://fedora.zanata.org/project/view/freeipa The upload should happen periodically, on the right occasions, so that the translators (especially the French and Ukrainian translations which have 100% translated) have sufficient time to translate strings for the next version and do not have to translate it all in couple days before release. (This was one of the feedback I heard recently). 2) Downloading translated strings, Tomas added a short HowTo to our Release page: http://www.freeipa.org/page/Release#Translations We will need a new volunteer who would help doing 1) and 2) for the planned releases and making sure this process runs. The first task would be uploading current strings in master as the next release is FreeIPA 4.4 planned for June, so it may be nice to already upload new strings we have in FreeIPA already to Zanata, so that they can be translated in sufficient time. Volunteer(s)? As part of the learning process, I think it would be useful to do more documentation of the steps taken in every translation life-cycle, current HowTo in Release page is rather vague. I for example did not find information how to work with translation versions that I saw defined in Zanata (branching may work similarly as in current FreeIPA git). -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. From mkosek at redhat.com Fri May 13 11:43:50 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 May 2016 13:43:50 +0200 Subject: [Freeipa-devel] I plan to delete my FreeIPA COPR repos Message-ID: Hi all, When we were starting building FreeIPA in the Fedora COPR service [1], the service did not support the organizations as it can do now and we did the official repos in my personal name space [2] as I was the common denominator for the project at the time. However, since that time, COPR support supports organizations, we created the FreeIPA organization [3] and do the official builds there. FreeIPA should have all currently supported repos, usually around 4.3 and master FreeIPA versions. Now, is anyone still using any of my FreeIPA related repos? Can I delete them so that it does not confuse people about what is the official repo? Comparing what I see in FreeIPA organization repos and personal repos, the FreeIPA organization miss FreeIPA 4.0 and 4.1 versions, but I think these can be safely removed. So my current plan is to delete all my personal FreeIPA repos unless I hear any blocker. So please holler if you depend on some of my repos. [1] https://copr.fedorainfracloud.org [2] https://copr.fedorainfracloud.org/coprs/mkosek/ [3] https://copr.fedorainfracloud.org/groups/g/freeipa/coprs/ -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. From slaznick at redhat.com Fri May 13 11:50:15 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 13 May 2016 13:50:15 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies Message-ID: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, Standa From placko at redhat.com Fri May 13 11:59:45 2016 From: placko at redhat.com (Peter Lacko) Date: Fri, 13 May 2016 07:59:45 -0400 (EDT) Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> Message-ID: <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> Hi, Thanks again, will remember that. I also changed header to short one. Peter ----- Original Message ----- From: "Martin Basti" To: "Peter Lacko" , freeipa-devel at redhat.com Sent: Tuesday, May 10, 2016 12:23:13 PM Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way On 28.04.2016 16:09, Martin Basti wrote: > > > On 08.04.2016 10:32, Peter Lacko wrote: >> >> > > Hello, > > I have a few comments: > > 1) > Please set up your git name and email correctly (consistently for all > patches) > this is not right From: root > > 2) > -# Copyright (C) 2012 Red Hat > +# Copyright (C) 2016 Red Hat > > leave there both years please > +# Copyright (C) 2012, 2016 Red Hat > > 3) > Please put the patch number to the email subject, it is easier to find correct patch for us > > Otherwise LGTM and works for me. > > Martin^2 > > Sorry I didn't noticed earlier, but your patch doesn't work under python3 from xmlrpc_test import XMLRPC_test, raises_exact E ImportError: No module named 'xmlrpc_test' You must use absolute import, not relative in py3 Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0001-3-Ping-module-tests.patch Type: text/x-patch Size: 3448 bytes Desc: not available URL: From mbasti at redhat.com Fri May 13 12:02:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 May 2016 14:02:00 +0200 Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> Message-ID: <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> On 13.05.2016 13:59, Peter Lacko wrote: > Hi, > > Thanks again, will remember that. I also changed header to short one. > > Peter Whyyy? > > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" , freeipa-devel at redhat.com > Sent: Tuesday, May 10, 2016 12:23:13 PM > Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way > > > > On 28.04.2016 16:09, Martin Basti wrote: >> >> On 08.04.2016 10:32, Peter Lacko wrote: >>> >> Hello, >> >> I have a few comments: >> >> 1) >> Please set up your git name and email correctly (consistently for all >> patches) >> this is not right From: root >> >> 2) >> -# Copyright (C) 2012 Red Hat >> +# Copyright (C) 2016 Red Hat >> >> leave there both years please >> +# Copyright (C) 2012, 2016 Red Hat >> >> 3) >> Please put the patch number to the email subject, it is easier to find correct patch for us >> >> Otherwise LGTM and works for me. >> >> Martin^2 >> >> > Sorry I didn't noticed earlier, but your patch doesn't work under python3 > > from xmlrpc_test import XMLRPC_test, raises_exact > E ImportError: No module named 'xmlrpc_test' > > You must use absolute import, not relative in py3 > > Martin^2 From mbasti at redhat.com Fri May 13 12:04:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 May 2016 14:04:21 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Message-ID: On 13.05.2016 13:32, Martin Kosek wrote: > Hello, > > As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat > employee, which of course does not mean he cannot contribute to the FreeIPA > project, but that he won't have as much time for contributions as previously. > > One of Tomas' responsibilities was taking care of FreeIPA translations > (Translation Maintainer role). As far as I know, there 2 main tasks associated > with the Translation Maintainer role: > > 1) Periodically uploading new upstream strings to the FreeIPA translation > platform of choice, which is the Fedora Zanata instance: > https://fedora.zanata.org/project/view/freeipa > The upload should happen periodically, on the right occasions, so that the > translators (especially the French and Ukrainian translations which have 100% > translated) have sufficient time to translate strings for the next version and > do not have to translate it all in couple days before release. (This was one of > the feedback I heard recently). > > 2) Downloading translated strings, Tomas added a short HowTo to our Release page: > http://www.freeipa.org/page/Release#Translations > > We will need a new volunteer who would help doing 1) and 2) for the planned > releases and making sure this process runs. The first task would be uploading > current strings in master as the next release is FreeIPA 4.4 planned for June, > so it may be nice to already upload new strings we have in FreeIPA already to > Zanata, so that they can be translated in sufficient time. > > Volunteer(s)? > > As part of the learning process, I think it would be useful to do more > documentation of the steps taken in every translation life-cycle, current HowTo > in Release page is rather vague. I for example did not find information how to > work with translation versions that I saw defined in Zanata (branching may work > similarly as in current FreeIPA git). > I volunteer Martin^2 From mbabinsk at redhat.com Fri May 13 12:07:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 13 May 2016 14:07:23 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Message-ID: On 05/13/2016 01:32 PM, Martin Kosek wrote: > Hello, > > As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat > employee, which of course does not mean he cannot contribute to the FreeIPA > project, but that he won't have as much time for contributions as previously. > > One of Tomas' responsibilities was taking care of FreeIPA translations > (Translation Maintainer role). As far as I know, there 2 main tasks associated > with the Translation Maintainer role: > > 1) Periodically uploading new upstream strings to the FreeIPA translation > platform of choice, which is the Fedora Zanata instance: > https://fedora.zanata.org/project/view/freeipa > The upload should happen periodically, on the right occasions, so that the > translators (especially the French and Ukrainian translations which have 100% > translated) have sufficient time to translate strings for the next version and > do not have to translate it all in couple days before release. (This was one of > the feedback I heard recently). > > 2) Downloading translated strings, Tomas added a short HowTo to our Release page: > http://www.freeipa.org/page/Release#Translations > > We will need a new volunteer who would help doing 1) and 2) for the planned > releases and making sure this process runs. The first task would be uploading > current strings in master as the next release is FreeIPA 4.4 planned for June, > so it may be nice to already upload new strings we have in FreeIPA already to > Zanata, so that they can be translated in sufficient time. > > Volunteer(s)? > > As part of the learning process, I think it would be useful to do more > documentation of the steps taken in every translation life-cycle, current HowTo > in Release page is rather vague. I for example did not find information how to > work with translation versions that I saw defined in Zanata (branching may work > similarly as in current FreeIPA git). > I also volunteer for the job. -- Martin^3 Babinsky From rcritten at redhat.com Fri May 13 12:27:21 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 May 2016 08:27:21 -0400 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> <5719E7AC.5020908@redhat.com> <571A0920.5020406@redhat.com> <571F5D4A.7060003@redhat.com> <5734C204.30701@redhat.com> Message-ID: <5735C829.3070405@redhat.com> Martin Basti wrote: > > > On 12.05.2016 19:48, Rob Crittenden wrote: >> Martin Basti wrote: >>> >>> >>> On 22.04.2016 13:21, David Kupka wrote: >>>> On 22/04/16 10:58, Martin Basti wrote: >>>>> >>>>> >>>>> On 21.04.2016 09:17, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 20.04.2016 16:57, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5281 >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>>> >>>>>> selfNACK >>>>>> >>>>>> >>>>> Updated patch attached. >>>>> >>>>> >>>>> >>>> Works for me, ACK. >>>> >>> pushed to master: >>> * fe2ce02a6f7664e377c367e16e9c2e1ad960c9d7 Performace: don't download >>> password attributes in host/user-find >>> >> >> It occurs to me, won't this break the UI somewhat. Isn't Enrolled one >> of the attributes on the default host page. Won't this show all hosts >> as unenrolled? >> >> rob > > Hi Rob, > > how exactly is webUI broken? I tried host section and it works. IIUC the > Web UI uses just host-find --pkey-only, which is not affected by this > change. For additional details webUI call host-show for each listed entry You're right, it was based on a bad assumption on my part. I assumed the UI took the output of host_find and displayed the results. Next time I'll check first. rob From mbabinsk at redhat.com Fri May 13 12:36:15 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 13 May 2016 14:36:15 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <20160513100755.hqrw5mqbfjm46c7l@redhat.com> References: <5707C9F2.8060903@redhat.com> <20160509062557.kal42vxwur7obauc@redhat.com> <20160513100755.hqrw5mqbfjm46c7l@redhat.com> Message-ID: <65d9d7e1-f1f4-69a2-ef66-a88a5bfdbbc6@redhat.com> On 05/13/2016 12:07 PM, Alexander Bokovoy wrote: > On Thu, 12 May 2016, Martin Babinsky wrote: >>> We should not allow anything after @ not belonging to the list of >>> realm domains. We also will need to extend realm domains to include >>> non-domain-based UPN suffixes. This actually flies close to what I need >>> to finish in my AD trust UPN patches, so I need to make sure we have the >>> same approach there. >>> >> >> Does this mean that we would not be able to implement e-mail as >> principal alias [1]? > Why? I have not said that. I have said that you should not be able to > specify UPN with a suffix that does not belong to us. I don't want us to > allow to have Kerberos principals aliased to a trusted forest > namespaces as this is violation of a forest trust. > I see that my reading comprehension skills are slowly declining over time :D. I now hope that I understand what you mean: the alias suffix MUST NOT overlap with any UPN suffix of a trusted forest. We then need to add these checks onto alias manipulation commands and add this to the design document. >>>>> 4. Will this RFE have any impact on AD trust (possibility of cross >>>>> realm >>>>> routing, RFC 6806 section 9) >>>>> >>>> >>>> IIRC there should be no impact on trusts. >>> We should never allow to specify alias from the realm we don't own. This >>> means the code needs to look into the namespaces associated with any of >>> the trusted domains and reject them. >>> >> >> So if I understand correctly we should reject tickets incoming from >> trusted domains if they do not contain canonical principal name (i.e. >> UPN)? > Again, no, this is not what I said. For UPNs from trusted domains I > already have code to detect them and issue correct referral for clients > to go to the proper KDC. OK so it seems that we will need to coordinate our respective efforts. -- Martin^3 Babinsky From placko at redhat.com Fri May 13 13:05:14 2016 From: placko at redhat.com (Peter Lacko) Date: Fri, 13 May 2016 09:05:14 -0400 (EDT) Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> Message-ID: <1877307538.52247950.1463144714968.JavaMail.zimbra@redhat.com> Desciption added back, header changed to original. Peter ----- Original Message ----- From: "Martin Basti" To: "Peter Lacko" Cc: freeipa-devel at redhat.com Sent: Friday, May 13, 2016 2:02:00 PM Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way On 13.05.2016 13:59, Peter Lacko wrote: > Hi, > > Thanks again, will remember that. I also changed header to short one. > > Peter Whyyy? > > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" , freeipa-devel at redhat.com > Sent: Tuesday, May 10, 2016 12:23:13 PM > Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way > > > > On 28.04.2016 16:09, Martin Basti wrote: >> >> On 08.04.2016 10:32, Peter Lacko wrote: >>> >> Hello, >> >> I have a few comments: >> >> 1) >> Please set up your git name and email correctly (consistently for all >> patches) >> this is not right From: root >> >> 2) >> -# Copyright (C) 2012 Red Hat >> +# Copyright (C) 2016 Red Hat >> >> leave there both years please >> +# Copyright (C) 2012, 2016 Red Hat >> >> 3) >> Please put the patch number to the email subject, it is easier to find correct patch for us >> >> Otherwise LGTM and works for me. >> >> Martin^2 >> >> > Sorry I didn't noticed earlier, but your patch doesn't work under python3 > > from xmlrpc_test import XMLRPC_test, raises_exact > E ImportError: No module named 'xmlrpc_test' > > You must use absolute import, not relative in py3 > > Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0001-4-Ping-module-tests.patch Type: text/x-patch Size: 2990 bytes Desc: not available URL: From slaznick at redhat.com Fri May 13 13:30:16 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 13 May 2016 15:30:16 +0200 Subject: [Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server Message-ID: <7762e407-0401-174a-2baf-6ecdfd5eb9b4@redhat.com> https://fedorahosted.org/freeipa/ticket/5307 Please see the patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0031-fixes-premature-sys.exit-in-ipa-replica-manage-del.patch Type: text/x-patch Size: 1706 bytes Desc: not available URL: From slaznick at redhat.com Fri May 13 13:43:43 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 13 May 2016 15:43:43 +0200 Subject: [Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server In-Reply-To: <7762e407-0401-174a-2baf-6ecdfd5eb9b4@redhat.com> References: <7762e407-0401-174a-2baf-6ecdfd5eb9b4@redhat.com> Message-ID: <3cc137f2-6fab-2c6f-c3b7-d06d48bf1acc@redhat.com> Got distracted with the code, beautifying replacement of previous patch attached. On 05/13/2016 03:30 PM, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/5307 > > Please see the patch attached. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0031-2-fixes-premature-sys.exit-in-ipa-replica-manage-del.patch Type: text/x-patch Size: 1739 bytes Desc: not available URL: From slaznick at redhat.com Fri May 13 13:48:11 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 13 May 2016 15:48:11 +0200 Subject: [Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server In-Reply-To: <3cc137f2-6fab-2c6f-c3b7-d06d48bf1acc@redhat.com> References: <7762e407-0401-174a-2baf-6ecdfd5eb9b4@redhat.com> <3cc137f2-6fab-2c6f-c3b7-d06d48bf1acc@redhat.com> Message-ID: <7c3115cc-dc99-5708-4e68-7efc8870ba86@redhat.com> Fix. On 05/13/2016 03:43 PM, Stanislav Laznicka wrote: > Got distracted with the code, beautifying replacement of previous > patch attached. > > On 05/13/2016 03:30 PM, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/5307 >> >> Please see the patch attached. >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0031-3-fixes-premature-sys.exit-in-ipa-replica-manage-del.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: From pvoborni at redhat.com Fri May 13 16:56:42 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 May 2016 18:56:42 +0200 Subject: [Freeipa-devel] [PATCH] 0018-0030 webui: add support for more certificates In-Reply-To: <571F79E2.2000106@redhat.com> References: <571F520B.2000501@redhat.com> <571F58E7.1070703@redhat.com> <571F79E2.2000106@redhat.com> Message-ID: On 04/26/2016 04:23 PM, Pavel Vomacka wrote: > Self-NACK for patches 0027, 28, 29, 30 - used incorrect policy. I also attach > all patches which were not changed - it is easier to get the whole patchset. > > On 04/26/2016 02:02 PM, Pavel Vomacka wrote: >> I forgot to mention that my patches requires patches from : >> https://www.redhat.com/archives/freeipa-devel/2016-April/msg00209.html >> >> >> On 04/26/2016 01:33 PM, Pavel Vomacka wrote: >>> Hello, >>> >>> the attached patches add support for more certificates and ability to add and >>> remove certificates. Fixes these two tickets: >>> https://fedorahosted.org/freeipa/ticket/5108 >>> https://fedorahosted.org/freeipa/ticket/5381 >>> >>> These patches add ability to view, get, download, revoke, restore and delete >>> each certificate directly from user/host/service details page. There is also >>> button for adding new certificates. >>> >>> There is one known issue, that after page save action is performed some data >>> disappear (includes certificates). This issue has a ticket already: >>> https://fedorahosted.org/freeipa/ticket/5776 >>> >>> -- >>> Pavel^3 Vomacka >>> Great stuff, couple comments below. We can discuss some items in person. Not everything needs to be done. I didn't run it, just reading the code. Patch 0018: 1. Nit pick: When a value should be boolean, then following method won't make sure that dropdown_menu won't be e.g. an object. + that.dropdown_menu = spec.dropdown_menu || false; I would prefer: + that.dropdown_menu = !!spec.dropdown_menu; Which retypes it to boolean. If default should be true (not this case) then: that.dropdown_menu = spec.dropdown_menu !== undefined ? !!spec.dropdown_menu : true; Also the interface is very specific. It says that the child widget will have dropdown menu. What if the actions won't be in dropdown menu but, e.g., some overlay menu. Imho the interface should be: that.custom_actions = !!spec.custom_actions; Than the child object would have define,e.g., : action_object get_custom_actions() Interface of action_object would be e.g.: get_items() set_items(items) enable_item(name) disable_item(name) Dropdown menu would have to define these methods. Patch 0019: 1. Shouldn't disable_item or enable_item automatically rerender the items? 2. The rerender, used in later patches. Imo it should do only: if (this.ul_node) { construct.empty(this.ul_node); this._render_items(this.items); } Or just re-render the one item. $( "li[data-name=" + item.name +"]", this.ul_node ).replaceWith( this._render_item(item)); 3. in future for loops write: for (var i=0, l=this.items.length; i custom_actions change 3. "that.certificate &&" is not required it will be always true that.certificate = $.extend({}, certificate); if (that.certificate && that.certificate.revoked !== 'undefined') { that.get_cert_revoke_status(); } 4. update_link is weird name for a method which updates data in a table 5. "that.update_link = function(r)", "r" shouldn't be there 6. Following doesn't look future proof: """ that.get_cert_revoke_status = function() { // Double check whether the certificate is issued by our CA. var issuer = 'CN=' + that.ipa_issuer_commonname + ',' + that.ipa_issuer_subjbase; if (that.certificate.issuer !== issuer) return; """ Would check it with Fraser 7. in handle_revocation_reason, useless call: var dd_menu = that.get_dropdown_menu(); 8. in compose_dialog_title, there is a check for `cert.subject` if true it sets `cn`, `o`. But if false then the values are `undefined` which are then used in the r.replace calls. Is it intended? Patch 0028: Looks OK, "dropdown_menu: true" doesn't have to be there as mentioned earlier Will test later. Patch 0029: 1. What about extending value_state_evaluator with adapter and param property. So that it would use standard adapter by default and every child could use it's own? IMO other parts of UI could use it as well. The reason why it doesn't use adapter already is that adapters were introduced later. It would simplify both definitions + the definitions in patch 30. Patch 0030: Same as patch 0029. -- Petr Vobornik From jfenal at gmail.com Sat May 14 09:57:13 2016 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 14 May 2016 11:57:13 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Message-ID: 2016-05-13 13:32 GMT+02:00 Martin Kosek : > Hello, > > As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat > employee, which of course does not mean he cannot contribute to the FreeIPA > project, but that he won't have as much time for contributions as > previously. > > One of Tomas' responsibilities was taking care of FreeIPA translations > (Translation Maintainer role). As far as I know, there 2 main tasks > associated > with the Translation Maintainer role: > > 1) Periodically uploading new upstream strings to the FreeIPA translation > platform of choice, which is the Fedora Zanata instance: > https://fedora.zanata.org/project/view/freeipa > The upload should happen periodically, on the right occasions, so that the > translators (especially the French and Ukrainian translations which have > 100% > translated) have sufficient time to translate strings for the next version > and > do not have to translate it all in couple days before release. (This was > one of > the feedback I heard recently). > > 2) Downloading translated strings, Tomas added a short HowTo to our > Release page: > http://www.freeipa.org/page/Release#Translations > > We will need a new volunteer who would help doing 1) and 2) for the planned > releases and making sure this process runs. The first task would be > uploading > current strings in master as the next release is FreeIPA 4.4 planned for > June, > so it may be nice to already upload new strings we have in FreeIPA already > to > Zanata, so that they can be translated in sufficient time. > > Volunteer(s)? > > As part of the learning process, I think it would be useful to do more > documentation of the steps taken in every translation life-cycle, current > HowTo > in Release page is rather vague. I for example did not find information > how to > work with translation versions that I saw defined in Zanata (branching may > work > similarly as in current FreeIPA git). ?Thanks to the two volunteers?! Looking forward to see this happen! To reiterate on Martin K. message on uploads, I'd really like to see regular strings uploads to the master branch in Zanata, say once a week or every two weeks, so that translators can work on smaller strings batches. "Release early, release oftem" :) And strings that would be translated twice in a short time span wouldn't be entirely lost because they may stay in the Zanata translation memory and could help translators finalizing dot releases if the specific branches in Zanata. ?And if ?we can see the upload to master soon, translators can start working now before the branch for the 4.4 June release. ?Regards, J. -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurchor at ukr.net Sat May 14 11:29:15 2016 From: yurchor at ukr.net (Yuri Chornoivan) Date: Sat, 14 May 2016 14:29:15 +0300 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Message-ID: ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal : > 2016-05-13 13:32 GMT+02:00 Martin Kosek : > >> Hello, >> >> As you may or may not know, Tomas Babej left the FreeIPA team as a Red >> Hat >> employee, which of course does not mean he cannot contribute to the >> FreeIPA >> project, but that he won't have as much time for contributions as >> previously. >> >> One of Tomas' responsibilities was taking care of FreeIPA translations >> (Translation Maintainer role). As far as I know, there 2 main tasks >> associated >> with the Translation Maintainer role: >> >> 1) Periodically uploading new upstream strings to the FreeIPA >> translation >> platform of choice, which is the Fedora Zanata instance: >> https://fedora.zanata.org/project/view/freeipa >> The upload should happen periodically, on the right occasions, so that >> the >> translators (especially the French and Ukrainian translations which have >> 100% >> translated) have sufficient time to translate strings for the next >> version >> and >> do not have to translate it all in couple days before release. (This was >> one of >> the feedback I heard recently). >> >> 2) Downloading translated strings, Tomas added a short HowTo to our >> Release page: >> http://www.freeipa.org/page/Release#Translations >> >> We will need a new volunteer who would help doing 1) and 2) for the >> planned >> releases and making sure this process runs. The first task would be >> uploading >> current strings in master as the next release is FreeIPA 4.4 planned for >> June, >> so it may be nice to already upload new strings we have in FreeIPA >> already >> to >> Zanata, so that they can be translated in sufficient time. >> >> Volunteer(s)? >> >> As part of the learning process, I think it would be useful to do more >> documentation of the steps taken in every translation life-cycle, >> current >> HowTo >> in Release page is rather vague. I for example did not find information >> how to >> work with translation versions that I saw defined in Zanata (branching >> may >> work >> similarly as in current FreeIPA git). > > > ?Thanks to the two volunteers?! > > Looking forward to see this happen! > > To reiterate on Martin K. message on uploads, I'd really like to see > regular strings uploads to the master branch in Zanata, say once a week > or > every two weeks, so that translators can work on smaller strings batches. > "Release early, release oftem" :) > > And strings that would be translated twice in a short time span wouldn't > be > entirely lost because they may stay in the Zanata translation memory and > could help translators finalizing dot releases if the specific branches > in > Zanata. > > ?And if ?we can see the upload to master soon, translators can start > working now before the branch for the 4.4 June release. > > ?Regards, > > J. Hi, Similar thoughts here. Just a note on branches, I think that it is worth to keep the translation just for the current release because keeping several branches on Zanata (or any other translation platform) is proved to be not effective from both sides, developers and translators. It is a matter of just two commands (one for extraction and "zanata push" for pushing the catalog to Zanata). So, personally, I'd like to see the updates as soon as possible (something close to continuous integration). This allows us, translators, to react on any glitches in the initial strings and make the releases perfect. It would be good if each release preparation process is close to the libguestfs's one: http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release Just my 2 cents. Best regards, Yuri From mkosek at redhat.com Sun May 15 18:51:45 2016 From: mkosek at redhat.com (Martin Kosek) Date: Sun, 15 May 2016 20:51:45 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> Message-ID: <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: > ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal : > >> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >> >>> Hello, >>> >>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat >>> employee, which of course does not mean he cannot contribute to the FreeIPA >>> project, but that he won't have as much time for contributions as >>> previously. >>> >>> One of Tomas' responsibilities was taking care of FreeIPA translations >>> (Translation Maintainer role). As far as I know, there 2 main tasks >>> associated >>> with the Translation Maintainer role: >>> >>> 1) Periodically uploading new upstream strings to the FreeIPA translation >>> platform of choice, which is the Fedora Zanata instance: >>> https://fedora.zanata.org/project/view/freeipa >>> The upload should happen periodically, on the right occasions, so that the >>> translators (especially the French and Ukrainian translations which have >>> 100% >>> translated) have sufficient time to translate strings for the next version >>> and >>> do not have to translate it all in couple days before release. (This was >>> one of >>> the feedback I heard recently). >>> >>> 2) Downloading translated strings, Tomas added a short HowTo to our >>> Release page: >>> http://www.freeipa.org/page/Release#Translations >>> >>> We will need a new volunteer who would help doing 1) and 2) for the planned >>> releases and making sure this process runs. The first task would be >>> uploading >>> current strings in master as the next release is FreeIPA 4.4 planned for >>> June, >>> so it may be nice to already upload new strings we have in FreeIPA already >>> to >>> Zanata, so that they can be translated in sufficient time. >>> >>> Volunteer(s)? >>> >>> As part of the learning process, I think it would be useful to do more >>> documentation of the steps taken in every translation life-cycle, current >>> HowTo >>> in Release page is rather vague. I for example did not find information >>> how to >>> work with translation versions that I saw defined in Zanata (branching may >>> work >>> similarly as in current FreeIPA git). >> >> >> ?Thanks to the two volunteers?! >> >> Looking forward to see this happen! >> >> To reiterate on Martin K. message on uploads, I'd really like to see >> regular strings uploads to the master branch in Zanata, say once a week or >> every two weeks, so that translators can work on smaller strings batches. >> "Release early, release oftem" :) >> >> And strings that would be translated twice in a short time span wouldn't be >> entirely lost because they may stay in the Zanata translation memory and >> could help translators finalizing dot releases if the specific branches in >> Zanata. >> >> ?And if ?we can see the upload to master soon, translators can start >> working now before the branch for the 4.4 June release. >> >> ?Regards, >> >> J. > > Hi, > > Similar thoughts here. Thanks for feedback! > Just a note on branches, I think that it is worth to keep the translation just > for the current release because keeping several branches on Zanata (or any > other translation platform) is proved to be not effective from both sides, > developers and translators. I see. My expectation would be that these branches would be only used if there is a bug in the translation, not for active translation. The thing is, strings in master may change or may be deleted, so they may no longer be applied to the branched FreeIPA x.y.z releases. So practically, we would not be able to update the translations for branched release once we branch. Do you see that expected and acceptable? > It is a matter of just two commands (one for extraction and "zanata push" for > pushing the catalog to Zanata). So, personally, I'd like to see the updates as > soon as possible (something close to continuous integration). This allows us, > translators, to react on any glitches in the initial strings and make the > releases perfect. I think this can be done, there is just the risk that some strings would be added during master development and changed later when the code is revisited, but I assume this is expected by you - correct? > It would be good if each release preparation process is close to the > libguestfs's one: > > http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release > > Just my 2 cents. Thanks for the tip! Martin From jfenal at gmail.com Sun May 15 19:04:53 2016 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sun, 15 May 2016 21:04:53 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> Message-ID: 2016-05-15 20:51 GMT+02:00 Martin Kosek : > On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: > > ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal >: > > > >> 2016-05-13 13:32 GMT+02:00 Martin Kosek : > >> > >>> Hello, > >>> > >>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red > Hat > >>> employee, which of course does not mean he cannot contribute to the > FreeIPA > >>> project, but that he won't have as much time for contributions as > >>> previously. > >>> > >>> One of Tomas' responsibilities was taking care of FreeIPA translations > >>> (Translation Maintainer role). As far as I know, there 2 main tasks > >>> associated > >>> with the Translation Maintainer role: > >>> > >>> 1) Periodically uploading new upstream strings to the FreeIPA > translation > >>> platform of choice, which is the Fedora Zanata instance: > >>> https://fedora.zanata.org/project/view/freeipa > >>> The upload should happen periodically, on the right occasions, so that > the > >>> translators (especially the French and Ukrainian translations which > have > >>> 100% > >>> translated) have sufficient time to translate strings for the next > version > >>> and > >>> do not have to translate it all in couple days before release. (This > was > >>> one of > >>> the feedback I heard recently). > >>> > >>> 2) Downloading translated strings, Tomas added a short HowTo to our > >>> Release page: > >>> http://www.freeipa.org/page/Release#Translations > >>> > >>> We will need a new volunteer who would help doing 1) and 2) for the > planned > >>> releases and making sure this process runs. The first task would be > >>> uploading > >>> current strings in master as the next release is FreeIPA 4.4 planned > for > >>> June, > >>> so it may be nice to already upload new strings we have in FreeIPA > already > >>> to > >>> Zanata, so that they can be translated in sufficient time. > >>> > >>> Volunteer(s)? > >>> > >>> As part of the learning process, I think it would be useful to do more > >>> documentation of the steps taken in every translation life-cycle, > current > >>> HowTo > >>> in Release page is rather vague. I for example did not find information > >>> how to > >>> work with translation versions that I saw defined in Zanata (branching > may > >>> work > >>> similarly as in current FreeIPA git). > >> > >> > >> ?Thanks to the two volunteers?! > >> > >> Looking forward to see this happen! > >> > >> To reiterate on Martin K. message on uploads, I'd really like to see > >> regular strings uploads to the master branch in Zanata, say once a week > or > >> every two weeks, so that translators can work on smaller strings > batches. > >> "Release early, release oftem" :) > >> > >> And strings that would be translated twice in a short time span > wouldn't be > >> entirely lost because they may stay in the Zanata translation memory and > >> could help translators finalizing dot releases if the specific branches > in > >> Zanata. > >> > >> ?And if ?we can see the upload to master soon, translators can start > >> working now before the branch for the 4.4 June release. > >> > >> ?Regards, > >> > >> J. > > > > Hi, > > > > Similar thoughts here. > > Thanks for feedback! > > > Just a note on branches, I think that it is worth to keep the > translation just > > for the current release because keeping several branches on Zanata (or > any > > other translation platform) is proved to be not effective from both > sides, > > developers and translators. > > I see. My expectation would be that these branches would be only used if > there > is a bug in the translation, not for active translation. The thing is, > strings > in master may change or may be deleted, so they may no longer be applied > to the > branched FreeIPA x.y.z releases. So practically, we would not be able to > update > the translations for branched release once we branch. > > Do you see that expected and acceptable? > ?Fine by me.? ?Maybe we could add a note to the wiki that older branches present in Zanata shouldn't be actively translated, and present only for bugfixing.? > > It is a matter of just two commands (one for extraction and "zanata > push" for > > pushing the catalog to Zanata). So, personally, I'd like to see the > updates as > > soon as possible (something close to continuous integration). This > allows us, > > translators, to react on any glitches in the initial strings and make the > > releases perfect. > > I think this can be done, there is just the risk that some strings would be > added during master development and changed later when the code is > revisited, > but I assume this is expected by you - correct? > ?It is indeed.? And desirable. The closer we can be from development, the better it is for quality as Yuri explained it: translators do read the English source strings ;). > > It would be good if each release preparation process is close to the > > libguestfs's one: > > > > http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release > > > > Just my 2 cents. > > Thanks for the tip! ?Regards, J. -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurchor at ukr.net Sun May 15 19:34:01 2016 From: yurchor at ukr.net (Yuri Chornoivan) Date: Sun, 15 May 2016 22:34:01 +0300 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> Message-ID: ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek : > On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal >> : >> >>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>> >>>> Hello, >>>> >>>> As you may or may not know, Tomas Babej left the FreeIPA team as a >>>> Red Hat >>>> employee, which of course does not mean he cannot contribute to the >>>> FreeIPA >>>> project, but that he won't have as much time for contributions as >>>> previously. >>>> >>>> One of Tomas' responsibilities was taking care of FreeIPA translations >>>> (Translation Maintainer role). As far as I know, there 2 main tasks >>>> associated >>>> with the Translation Maintainer role: >>>> >>>> 1) Periodically uploading new upstream strings to the FreeIPA >>>> translation >>>> platform of choice, which is the Fedora Zanata instance: >>>> https://fedora.zanata.org/project/view/freeipa >>>> The upload should happen periodically, on the right occasions, so >>>> that the >>>> translators (especially the French and Ukrainian translations which >>>> have >>>> 100% >>>> translated) have sufficient time to translate strings for the next >>>> version >>>> and >>>> do not have to translate it all in couple days before release. (This >>>> was >>>> one of >>>> the feedback I heard recently). >>>> >>>> 2) Downloading translated strings, Tomas added a short HowTo to our >>>> Release page: >>>> http://www.freeipa.org/page/Release#Translations >>>> >>>> We will need a new volunteer who would help doing 1) and 2) for the >>>> planned >>>> releases and making sure this process runs. The first task would be >>>> uploading >>>> current strings in master as the next release is FreeIPA 4.4 planned >>>> for >>>> June, >>>> so it may be nice to already upload new strings we have in FreeIPA >>>> already >>>> to >>>> Zanata, so that they can be translated in sufficient time. >>>> >>>> Volunteer(s)? >>>> >>>> As part of the learning process, I think it would be useful to do more >>>> documentation of the steps taken in every translation life-cycle, >>>> current >>>> HowTo >>>> in Release page is rather vague. I for example did not find >>>> information >>>> how to >>>> work with translation versions that I saw defined in Zanata >>>> (branching may >>>> work >>>> similarly as in current FreeIPA git). >>> >>> >>> ?Thanks to the two volunteers?! >>> >>> Looking forward to see this happen! >>> >>> To reiterate on Martin K. message on uploads, I'd really like to see >>> regular strings uploads to the master branch in Zanata, say once a >>> week or >>> every two weeks, so that translators can work on smaller strings >>> batches. >>> "Release early, release oftem" :) >>> >>> And strings that would be translated twice in a short time span >>> wouldn't be >>> entirely lost because they may stay in the Zanata translation memory >>> and >>> could help translators finalizing dot releases if the specific >>> branches in >>> Zanata. >>> >>> ?And if ?we can see the upload to master soon, translators can start >>> working now before the branch for the 4.4 June release. >>> >>> ?Regards, >>> >>> J. >> >> Hi, >> >> Similar thoughts here. > > Thanks for feedback! > >> Just a note on branches, I think that it is worth to keep the >> translation just >> for the current release because keeping several branches on Zanata (or >> any >> other translation platform) is proved to be not effective from both >> sides, >> developers and translators. > > I see. My expectation would be that these branches would be only used if > there > is a bug in the translation, not for active translation. The thing is, > strings > in master may change or may be deleted, so they may no longer be applied > to the > branched FreeIPA x.y.z releases. So practically, we would not be able to > update > the translations for branched release once we branch. > > Do you see that expected and acceptable? Just two examples from the projects that I am involved (three polar examples). KDE (Desktop environment): 1. Developed translation infrastructure (dedicated server, specifically-tailored software (Lokalize)). 2. Four translation branches (stable and trunk for Qt4 and Qt5-based applications). 3. Automatic message extraction every 24 hours. 4. Inbuild translation integration for releases. All this needs attention and strict release rules to keep everything in sync. Inkscape (SVG editor): 1. No specific infrastructure. 2. Translation branches are not strict (translators should guess what and where they are translating). 3. Manual extraction from time to time. 4. No specific integration or QA. Medium attention paid from the Inkscape developers. GnuPG (encryption framework): 1. No specific infrastructure. 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be performed by translators manually). 3. Manual extraction. No strict release schedule. You are lucky if you send your translation in time. 4. Manual integration by Werner when he finds it necessary. ;) Minimum attention paid from the developer. I think that FreeIPA in the sense of translation handling should be something in between. For not wasting efforts of the developers (it is sensible, because of too few more or less complete translations), I propose to have just one branch (no switching, no problem of choice), but use it strictly when releasing. It is better to have a translation with several untranslated new messages in a branch, than have no update at all because of the release flaws (like it is in libvirt now). So it would be a good trade off for me if FreeIPA developers promise to integrate translations into each release, but do not promise to waste their time for having translation branches. ;) > It is a matter of just two commands (one for extraction and "zanata >> push" for >> pushing the catalog to Zanata). So, personally, I'd like to see the >> updates as >> soon as possible (something close to continuous integration). This >> allows us, >> translators, to react on any glitches in the initial strings and make >> the >> releases perfect. > > I think this can be done, there is just the risk that some strings would > be > added during master development and changed later when the code is > revisited, > but I assume this is expected by you - correct? Yes, that's the common translators risk. But we have an automated translation memory for this. ;) > >> It would be good if each release preparation process is close to the >> libguestfs's one: >> >> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >> >> Just my 2 cents. > > Thanks for the tip! > > Martin Best regards, Yuri From mkosek at redhat.com Mon May 16 06:37:27 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 May 2016 08:37:27 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> Message-ID: On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: > ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek : > >> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal : >>> >>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>>> >>>>> Hello, >>>>> >>>>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat >>>>> employee, which of course does not mean he cannot contribute to the FreeIPA >>>>> project, but that he won't have as much time for contributions as >>>>> previously. >>>>> >>>>> One of Tomas' responsibilities was taking care of FreeIPA translations >>>>> (Translation Maintainer role). As far as I know, there 2 main tasks >>>>> associated >>>>> with the Translation Maintainer role: >>>>> >>>>> 1) Periodically uploading new upstream strings to the FreeIPA translation >>>>> platform of choice, which is the Fedora Zanata instance: >>>>> https://fedora.zanata.org/project/view/freeipa >>>>> The upload should happen periodically, on the right occasions, so that the >>>>> translators (especially the French and Ukrainian translations which have >>>>> 100% >>>>> translated) have sufficient time to translate strings for the next version >>>>> and >>>>> do not have to translate it all in couple days before release. (This was >>>>> one of >>>>> the feedback I heard recently). >>>>> >>>>> 2) Downloading translated strings, Tomas added a short HowTo to our >>>>> Release page: >>>>> http://www.freeipa.org/page/Release#Translations >>>>> >>>>> We will need a new volunteer who would help doing 1) and 2) for the planned >>>>> releases and making sure this process runs. The first task would be >>>>> uploading >>>>> current strings in master as the next release is FreeIPA 4.4 planned for >>>>> June, >>>>> so it may be nice to already upload new strings we have in FreeIPA already >>>>> to >>>>> Zanata, so that they can be translated in sufficient time. >>>>> >>>>> Volunteer(s)? >>>>> >>>>> As part of the learning process, I think it would be useful to do more >>>>> documentation of the steps taken in every translation life-cycle, current >>>>> HowTo >>>>> in Release page is rather vague. I for example did not find information >>>>> how to >>>>> work with translation versions that I saw defined in Zanata (branching may >>>>> work >>>>> similarly as in current FreeIPA git). >>>> >>>> >>>> ?Thanks to the two volunteers?! >>>> >>>> Looking forward to see this happen! >>>> >>>> To reiterate on Martin K. message on uploads, I'd really like to see >>>> regular strings uploads to the master branch in Zanata, say once a week or >>>> every two weeks, so that translators can work on smaller strings batches. >>>> "Release early, release oftem" :) >>>> >>>> And strings that would be translated twice in a short time span wouldn't be >>>> entirely lost because they may stay in the Zanata translation memory and >>>> could help translators finalizing dot releases if the specific branches in >>>> Zanata. >>>> >>>> ?And if ?we can see the upload to master soon, translators can start >>>> working now before the branch for the 4.4 June release. >>>> >>>> ?Regards, >>>> >>>> J. >>> >>> Hi, >>> >>> Similar thoughts here. >> >> Thanks for feedback! >> >>> Just a note on branches, I think that it is worth to keep the translation just >>> for the current release because keeping several branches on Zanata (or any >>> other translation platform) is proved to be not effective from both sides, >>> developers and translators. >> >> I see. My expectation would be that these branches would be only used if there >> is a bug in the translation, not for active translation. The thing is, strings >> in master may change or may be deleted, so they may no longer be applied to the >> branched FreeIPA x.y.z releases. So practically, we would not be able to update >> the translations for branched release once we branch. >> >> Do you see that expected and acceptable? > > Just two examples from the projects that I am involved (three polar examples). > > KDE (Desktop environment): > 1. Developed translation infrastructure (dedicated server, > specifically-tailored software (Lokalize)). > > 2. Four translation branches (stable and trunk for Qt4 and Qt5-based > applications). > > 3. Automatic message extraction every 24 hours. > > 4. Inbuild translation integration for releases. > > All this needs attention and strict release rules to keep everything in sync. > > Inkscape (SVG editor): > 1. No specific infrastructure. > > 2. Translation branches are not strict (translators should guess what and where > they are translating). > > 3. Manual extraction from time to time. > > 4. No specific integration or QA. > > Medium attention paid from the Inkscape developers. > > GnuPG (encryption framework): > 1. No specific infrastructure. > > 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be performed by > translators manually). > > 3. Manual extraction. No strict release schedule. You are lucky if you send > your translation in time. > > 4. Manual integration by Werner when he finds it necessary. ;) > > Minimum attention paid from the developer. > > I think that FreeIPA in the sense of translation handling should be something > in between. For not wasting efforts of the developers (it is sensible, because > of too few more or less complete translations), I propose to have just one > branch (no switching, no problem of choice), but use it strictly when releasing. Thanks for the overview! Based on what I see so far, it looks like there is not an interest for the branched translations. So I am fine with not doing the versions if we do not see a need for it. As for automated message upload, I guess it could be done, we would just need to think if it fits in current Jenkins infrastructure. But I suspect it could also be on any cron-powered PaaS, like OpenShift. > It is better to have a translation with several untranslated new messages in a > branch, than have no update at all because of the release flaws (like it is in > libvirt now). So it would be a good trade off for me if FreeIPA developers > promise to integrate translations into each release, but do not promise to > waste their time for having translation branches. ;) Translations should indeed be integrated in the release process. I would let the 2 volunteers to update the Release page with the proper process and instructions :-) >> It is a matter of just two commands (one for extraction and "zanata >>> push" for >>> pushing the catalog to Zanata). So, personally, I'd like to see the updates as >>> soon as possible (something close to continuous integration). This allows us, >>> translators, to react on any glitches in the initial strings and make the >>> releases perfect. >> >> I think this can be done, there is just the risk that some strings would be >> added during master development and changed later when the code is revisited, >> but I assume this is expected by you - correct? > > Yes, that's the common translators risk. But we have an automated translation > memory for this. ;) Ok. >>> It would be good if each release preparation process is close to the >>> libguestfs's one: >>> >>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >>> >>> Just my 2 cents. >> >> Thanks for the tip! >> >> Martin > > Best regards, > Yuri Thanks! Martin From dkupka at redhat.com Mon May 16 11:58:51 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 16 May 2016 13:58:51 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> Message-ID: <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> On 26/04/16 10:09, David Kupka wrote: > On 14/03/16 14:01, Martin Basti wrote: >> >> >> On 14.03.2016 13:46, Martin Babinsky wrote: >>> On 03/11/2016 09:16 AM, David Kupka wrote: >>>> Current version (0.5.0) of python-augeas is missing copy() method. Use >>>> dkupka/python-augeas copr repo before new version it's build and >>>> available in the official repos. >>>> >>>> >>>> >>> Hi David, >>> >>> TLDR: NACK :D. >>> >>> Here are high-level remarks to discuss: >>> >>> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >>> ipaplatform since it is dealing with (sorta) platform specific >>> behavior (ntp vs. chrony vs. whatever we will have for timesync in the >>> future). CC'ing Jan for thoughts. >>> >>> Also regarding patches 0096-0097, we could have platform specific >>> TimeDateService object that could wrap NTP/chrony management. for >>> example, the task namespace functions in Pathc 0096 could be >>> reimplemented as a methods of the service (RedhatTimeDateService, >>> FedoraTimeDateService etc.) and then called in a platform-agnostic >>> manner. >>> >>> Here are some comments regarding code: >>> >>> Patch 0095: >>> >>> 1.) >>> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >>> >>> Do not forget to add this directory to %install and %files spection of >>> the spec file so that it is correctly added to RPM build. >>> >>> 2.) >>> >>> please separate import of system-wide and IPA-specific modules by >>> blank line >>> >>> +import collections >>> +from augeas import Augeas >>> +from ipaplatform.paths import paths >>> +from ipapython.ipa_log_manager import root_logger >>> >>> 3.) the call to parent's __new__ should have signature 'super(aug_obj, >>> cls).__new__(*args, **kwargs)' >>> >>> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >>> **kwargs) >>> >>> 4.) >>> >>> + raise RuntimeError('Augeas lenses was loaded. Could not >>> add more' >>> + 'lenses.') >>> >>> Should be 'Augeas lenses _were_ loaded' >>> >>> 5.) >>> >>> + if lens in self.lenses: >>> + raise RuntimeError('Lens %s already added.' % lens) >>> + self.lenses.append(lens) >>> + load_path = '/augeas/load/{0}'.format(lens >>> >>> >>> Shouldn't the following code use os.path,join to construct the >>> load_path? >>> >>> 6.) I would prefer the following indentation style in the add_lens() >>> method >>> >>> @@ -65,9 +65,9 @@ class aug_obj(object): >>> for conf_file in conf_files: >>> self._aug.set(os.path.join(load_path, 'incl[0]'), >>> conf_file) >>> self.tree['old'] = self.tree.get(conf_file, None) >>> - self.tree[conf_file] = aug_node(self._aug, >>> - os.path.join('/files', >>> - conf_file[1:])) >>> + self.tree[conf_file] = aug_node( >>> + self._aug, os.path.join('/files', conf_file[1:]) >>> + ) >>> >>> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >>> 'files', and '//error' would be made into either module variables or >>> class members. >>> >>> 8.) >>> >>> + def load(self): >>> + if self._loaded: >>> + raise RuntimeError('Augeas lenses was loaded. Could not >>> add more' >>> + 'lenses.') >>> >>> Fix the excpetion text in the same way as in 4.) >>> >>> 9.) >>> >>> + errors = self._aug.match(os.path.join('//error')) >>> >>> is the os.path.join necessary here? >>> >>> 10.) I guess you can rewrite the error message in load() method using >>> list comprehension: >>> >>> @@ -76,9 +76,9 @@ class aug_obj(object): >>> self._aug.load() >>> errors = self._aug.match(os.path.join('//error')) >>> if errors: >>> - err_msg = "" >>> - for error in errors: >>> - err_msg += ("{}: {}".format(error, >>> self._aug.get(error))) >>> + err_msg = '\n'.join( >>> + ["{}: {}".format(e, self._aug.get(e)) for e in errors] >>> + ) >>> raise RuntimeError(err_msg) >>> self._loaded = True >>> >>> 11.) >>> >>> +class aug_node(collections.MutableMapping): >>> + """ Single augeas node. >>> + Can be handled as python dict(). >>> + """ >>> + def __init__(self, aug, path): >>> + self._aug = aug >>> + if path and os.path.isabs(path): >>> + self._path = path >>> + else: >>> + self._tmp = _tmp_path(aug, path) >>> + self._path = self._tmp.path >>> >>> Isn't it better to change signature of __init__ to: >>> >>> def __init__(self, aug, path=None): >>> >>> and then test whether path is None? >>> >>> 12.) >>> >>> def __setitem__(self, key, node): >>> + target = os.path.join(self._path, key) >>> + end = '{0}[0]'.format(os.path.join(self._path, key)) >>> + if self._aug.match(target): >>> + self._aug.remove(target) >>> + target_list = aug_list(self._aug, target) >>> + for src_node in aug_list(node._aug, node._path): >>> + target_list.append(src_node) >>> >>> The 'end' variable is declared but not used. >>> >>> 13.) >>> >>> + >>> + def __len__(self): >>> + return len(self._aug.match('{0}/*'.format(self._path))) >>> + >>> + def __iter__(self): >>> + for key in self._aug.match('{0}/*'.format(self._path)): >>> + yield self._aug.label(key) >>> + raise StopIteration() >>> + >>> >>> Shouldn't we construct paths using os.path.join for the sake of >>> consistency? >>> >>> 14.) >>> >>> + def __bool__(self): >>> + return (bool(len(self)) or bool(self.value)) >>> >>> The parentheses around the boolean expression are not needed >>> >>> 15.) >>> >>> +class aug_list(collections.MutableSequence): >>> + """Augeas NODESET. >>> + Can be handled as a list(). >>> + """ >>> + def __init__(self, aug, path): >>> + self._aug = aug >>> + if path and os.path.isabs(path): >>> + self._path = path >>> + else: >>> + self._tmp = _tmp_path(aug, path) >>> + self._path = self._tmp.path >>> >>> I would use 'path=None' int he signature and then test whether 'path >>> is not None'. >>> >>> 16.) >>> >>> + if not self._aug.match(target): >>> + raise IndexError() >>> >>> It would be nice if you could put some basic error message into the >>> raised exceptions, like "node index out of range" or something like that >>> >>> 17.) >>> >>> + elif isinstance(index, slice): >>> + label = self._path.split('/')[-1] >>> >>> you could use os.path.basename() to get the leaf node. >>> >>> >>> 18.) >>> >>> + replace = range_target[:len(node)] >>> + delete = create = [] >>> >>> Be careful here as you create two references to the same empty list >>> object, which is probably not what you wanted. >>> >>> 19.) >>> + try: >>> + create_start = range_target[-1]+1 >>> + except IndexError: >>> + create_start = self._idx_pos(index.start) >>> + create_stop = create_start+len(node)-len(replace) >>> + create = list(range(create_start, create_stop)) >>> >>> Please respect PEP8 and put spaces around arithmetic operators in >>> assignments. >>> >>> Also it would be nice to have at least a minimal test suite for this >>> module, but that may be a separate ticket. >>> >>> patch 0096: >>> >>> 1.) please fix the commit message >>> 2.) please use new-style license header in ipapython/ntp.py >>> 3.) >>> >>> + return ("Conflicting Time&Date synchroniztion service '%s' is " >>> + "currently enabled and/or running on the system." >>> + % self.conflicting_service) >>> >>> Please fix the typo in the error message. >>> >>> 4.) >>> + service = services.service(self.service_name) >>> + if sstore: >>> + if sstore.get_state('ntp', 'enabled') is None: >>> + sstore.backup_state('ntp', 'enabled', >>> service.is_enabled()) >>> + >>> + if fstore: >>> + if not fstore.has_file(self.conf_file): >>> + fstore.backup_file(self.conf_file) >>> >>> the conditions in the 'if' statement can be merged into single AND >>> expression >>> >>> 5.) >>> + self._store_service_state(sstore, fstore) >>> + if sstore: >>> + sstore.backup_state('ntp', "enabled", service.is_enabled()) >>> + >>> + if fstore: >>> + fstore.backup_file(self.conf_file) >>> >>> I think these checks are redundant here. >>> >>> 6.) >>> + # In such case it is OK to fail >>> + try: >>> + restored = fstore.restore_file(self.conf_file) >>> + except Exception: >>> + pass >>> >>> Instead of 'pass' it would be better to set restored to False so that >>> you don't hit NameError later. >>> >>> 7.) >>> + >>> + def configure_client(self, ntp_servers=[], sstore=None, >>> fstore=None): >>> + self.server_options['burst'] = None >>> + self.server_options['iburst'] = None >>> >>> I would rather set these instance variables in __init__() than here. >>> >>> 8.) >>> >>> + def configure_client(self, ntp_servers=[], sstore=None, >>> fstore=None): >>> + self.conf_file = paths.CHRONY_CONF >>> self.conf_file is already defined in constructor. >>> >>> 9.) >>> >>> + self.server_options['iburst'] = None >>> this should be moved to __init__() >>> >>> 10.) >>> + with ipaaugeas.aug_obj() as aug: >>> + try: >>> + aug.add_lens(self.lens, [self.conf_file]) >>> + aug.load() >>> + except RuntimeError as e: >>> + raise NTPConfigurationError(e) >>> >>> This code is repeated quite a few times, maybe it would be a good idea >>> to factor it out to a method of NTPService object. >>> >>> >>> Patch 0097: >>> >>> 1.) please fix a typo here: >>> >>> + description="Disble any other Time synchronization services." >>> >>> 2.) >>> >>> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >>> you have 2 spaces before 'ntpinstance' >>> >> >> I'm adding my nitpicks too :) >> >> 1) >> +#!/usr/bin/python >> >> This should not be in modules, only in executable files >> >> 2) >> Missing license in ipaaugeas.py >> >> Martin^2 > > Hello, > after offline discussion with Honza I've rewritten the augeas wrapper > and modified ipautil/ntp.py accordingly. The rest should be pretty much > the same. > Patches attached. > Rebased and added minimal test suite. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-dkupka-0095.2-augeas-add-wrapper-around-python-binding.patch Type: text/x-patch Size: 4812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-dkupka-0096.2-ntp-Add-module-for-NTP-configuration.patch Type: text/x-patch Size: 15414 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-dkupka-0097.2-ntp-Add-platform-specific-tasks.patch Type: text/x-patch Size: 4182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-dkupka-0098.2-ntp-install-Use-tasks-to-configure-NTP-daemon.patch Type: text/x-patch Size: 30596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-dkupka-0101.0-test-Basic-tests-for-configfile-module.patch Type: text/x-patch Size: 3627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0095.2-augeas-add-wrapper-around-python-binding.patch Type: text/x-patch Size: 4812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0096.2-ntp-Add-module-for-NTP-configuration.patch Type: text/x-patch Size: 15304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0097.2-ntp-Add-platform-specific-tasks.patch Type: text/x-patch Size: 3667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0098.2-ntp-install-Use-tasks-to-configure-NTP-daemon.patch Type: text/x-patch Size: 33082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0101.0-test-Basic-tests-for-configfile-module.patch Type: text/x-patch Size: 3627 bytes Desc: not available URL: From ofayans at redhat.com Mon May 16 13:48:32 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 16 May 2016 15:48:32 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 Message-ID: <5739CFB0.6000607@redhat.com> Hi, The design is OK, the onlz thing that is missing is a HowToTest section in track tickets [1] and [2] about clean-dangling-ruvs and abort-clean-ruv respectively. It would really help if these tickets had detailed steps to test (in case of dangling RUV's - steps to generate them) -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Mon May 16 14:35:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 May 2016 16:35:36 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> Message-ID: <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> On 09.05.2016 14:07, Jan Cholasta wrote: > On 6.5.2016 14:32, Martin Basti wrote: >> >> >> On 28.04.2016 14:45, Jan Cholasta wrote: >>> Hi, >>> >>> I have pushed my thin client WIP branch to GitHub: >>> . >>> >>> All commits up to "ipalib: use relative imports for cross-plugin >>> imports" should be good for review. The rest is subject to change >>> (WARNING: I will force push into this branch). >>> >>> Honza >>> >> I did not test it yet, I just checked the code >> >> * automount: do not inherit automountlocation_tofiles from LDAPQuery * >> LGTM >> >> * dns: move all dnsrecord code called on client to a single class * >> LGTM >> >> * dns: do not rely on server data structures in code called on client * >> 1) >> you forgot to increment VERSION > > This was deliberate, as it will no longer be necessary to bump VERSION > for backward compatible changes after this whole patchset is merged. > But we're not there yet, so fixed. > How we should handle VERSION after your patches? >> >> Otherwise LGTM >> >> * otptoken: fix import of DN * >> ACK >> >> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >> 1) >> you forgot to increment VERSION > > Fixed. > >> >> 2) >> Did you find out why this was issue? >> - del answer['value'] # Why does this cause an error if >> omitted? >> - del answer['summary'] # Why does this cause an error if >> omitted? > > The command definition was not complete, it was missing has_output. > >> >> Otherwise LGTM >> >> * vault: move client-side code to the module level * >> LGTM >> >> * vault: copy arguments of client commands from server counterparts * >> 1) >> you forgot to increment Version > > Fixed. > >> >> * ipalib: use relative imports for cross-plugin imports * >> 1) Missing explanation for future generations why this change is needed >> in commit message > > Fixed. > >> >> The other commits I will check later. >> Martin^2 >> > > Okay. Thanks. > * frontend: remove the unused Command.soft_validate method LGTM * frontend: perform argument value validation only on server LGTM * frontend: do not forward argument defaults to server I'm not a fan of returning None in promt_param function, but I havent found anything better to use. LGTM * ipalib: optimize API.txt this contains a lot of black magic, but because this is mainly copy of current to proper places, LGTM * makeaci: load additional plugins using API.add_module Looks good, but I miss explanation why is this change needed * plugable: replace API.import_plugins with new API.add_package LGTM * ipalib, ipaserver: migrate all plugins to Registry-based registration ACK * ipalib, ipaserver: fix incorrect API.register calls in docstrings LGTM * plugable: remove the unused deprecated API.register method LGTM * plugable: switch API to Registry-based plugin discovery LGTM * frontend: merge baseldap.CallbackRegistry into Command LGTM *frontend: move the interactive_prompt callback type to Command LGTM Martin^2 From mbasti at redhat.com Mon May 16 16:32:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 May 2016 18:32:49 +0200 Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <1877307538.52247950.1463144714968.JavaMail.zimbra@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> <1877307538.52247950.1463144714968.JavaMail.zimbra@redhat.com> Message-ID: <43757ad0-fbc6-cbf7-6c00-179d1ba7b3d3@redhat.com> On 13.05.2016 15:05, Peter Lacko wrote: > Desciption added back, header changed to original. > > Peter > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" > Cc: freeipa-devel at redhat.com > Sent: Friday, May 13, 2016 2:02:00 PM > Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way > > > > On 13.05.2016 13:59, Peter Lacko wrote: >> Hi, >> >> Thanks again, will remember that. I also changed header to short one. >> >> Peter > Whyyy? > > >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Peter Lacko" , freeipa-devel at redhat.com >> Sent: Tuesday, May 10, 2016 12:23:13 PM >> Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way >> >> >> >> On 28.04.2016 16:09, Martin Basti wrote: >>> On 08.04.2016 10:32, Peter Lacko wrote: >>> Hello, >>> >>> I have a few comments: >>> >>> 1) >>> Please set up your git name and email correctly (consistently for all >>> patches) >>> this is not right From: root >>> >>> 2) >>> -# Copyright (C) 2012 Red Hat >>> +# Copyright (C) 2016 Red Hat >>> >>> leave there both years please >>> +# Copyright (C) 2012, 2016 Red Hat >>> >>> 3) >>> Please put the patch number to the email subject, it is easier to find correct patch for us >>> >>> Otherwise LGTM and works for me. >>> >>> Martin^2 >>> >>> >> Sorry I didn't noticed earlier, but your patch doesn't work under python3 >> >> from xmlrpc_test import XMLRPC_test, raises_exact >> E ImportError: No module named 'xmlrpc_test' >> >> You must use absolute import, not relative in py3 >> >> Martin^2 Sorry, NACK ************* Module ipatests.test_xmlrpc.test_ping_plugin ipatests/test_xmlrpc/test_ping_plugin.py:29: [E0611(no-name-in-module), ] No name 'test_xmplrpc' in module 'ipatests') did you mean 'test_xmlrpc'? Martin^2 From patduc38 at gmail.com Tue May 17 08:54:41 2016 From: patduc38 at gmail.com (Patrice Duc-Jacquet) Date: Tue, 17 May 2016 10:54:41 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Incorrect message when KRA already installed Message-ID: Hi everyone Please see attached candidate patch for ticket https://fedorahosted.org/freeipa/ticket/5315 Thanks and regards Pat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pducjac-0002-Incorrect-message-when-KRA-already-installed.patch Type: text/x-patch Size: 1828 bytes Desc: not available URL: From tbordaz at redhat.com Tue May 17 09:48:01 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 17 May 2016 11:48:01 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <57358DC7.9030905@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> Message-ID: <573AE8D1.9090303@redhat.com> On 05/13/2016 10:18 AM, Ludwig Krispenz wrote: > > On 05/13/2016 09:42 AM, Petr Spacek wrote: >> On 13.5.2016 09:26, Martin Kosek wrote: >>> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >>>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I have been doing some tests/measures using >>>>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>>>> >>>>>>>>> >>>>>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>>>>> import with a >>>>>>>>> ldapadd. >>>>>>>>> >>>>>>>>> I wrote down some finding in >>>>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I still have to do some cleanup around the performance >>>>>>>>> but the >>>>>>>>> basic of a >>>>>>>>> possible improvement is to do provisioning in several >>>>>>>>> steps >>>>>>>>> (disabling >>>>>>>>> plugins, provisioning, enabling plugin, running fixup >>>>>>>>> tasks). >>>>>>>>> >>>>>>>>> Before going further in the design I wanted to share >>>>>>>>> those ideas >>>>>>>>> and know if >>>>>>>>> it raise any concern. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>>> >>>>>>>> Hi Thierry, >>>>>>>> >>>>>>>> Thanks for the analysis. Very nice. >>>>>>>> >>>>>>>> Knowing this will help us suggesting workarounds also for old >>>>>>>> releases. >>>>>>>> >>>>>>>> Couple questions: >>>>>>>> >>>>>>>> Have you tested retrCL disabled with memberOf enabled. It seems >>>>>>>> that it >>>>>>>> would eliminate 550K adds and 0.8M searches. What would be the >>>>>>>> time >>>>>>>> improvement? >>>>>>>> >>>>>>>> Do you know what is the time when memberof is enabled but >>>>>>>> slapi-nis and >>>>>>>> retroCL are disabled? >>>>>>> The culprit of the performance issue is very likely related to SRCH >>>>>>> (internal) triggered by memberof. >>>>>>> >>>>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled >>>>>>> #SRCH is >>>>>>> 14.8 >>>>>>> When all of them are enabled the #SRCH is 15M. >>>>>>> >>>>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>>>> significant effect on the duration. >>>>>> ok, thanks for the analysis >>>>>> >>>>>>> Regarding the duration of the provisioning, values are not >>>>>>> really stable >>>>>>> as performance of VM fluctuates. But as soon as memberof is >>>>>>> enabled the >>>>>>> provisioning lasts > 4hours where the same provisioning lasts >>>>>>> 6mins as >>>>>>> soon as memberof is disabled. >>>>>>> >>>>>>> I need to confirm the average time for internal searches but >>>>>>> assuming >>>>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>>>> >>>>>>> >>>>>>>> From the text it was not clear to me, if you find or >>>>>>>> investigate >>>>>>>> possible improvements in memberof plugin which would improve the >>>>>>>> performance without stopping and starting DS. >>>>>> As was discussed at mtg, have you tried if the DS restart is really >>>>>> necessary? >>>>> memberof plugin can be enabled and disabled while the server is >>>>> running, BUT >>>>> to achieve this the "enable-dynamic-plugins" feature has to be >>>>> turned on. And >>>>> then any enable/disable of a plugin would try to do it dynamically >>>>> an dnot >>>>> wait for the restart. >>>>> And I think not all plugins are able to handle this, TomasB was >>>>> once working >>>>> on it for IPA plugins, but it was not completed as far as I know >>>> but enabling dynamic plugins can be done without restart, so what >>>> can be done is. >>>> - enable dynamic plugins >>>> - disable memberof >>>> - do some work >>>> - enable memberof >>>> - disable dynamic plugins >>> Please see >>> https://fedorahosted.org/freeipa/ticket/4203#comment:9 >>> I do not think this will be that easy. We would first need to invest >>> into >>> updating FreeIPA plugins to work with dynamic plugins setting and >>> then we could >>> do things alike above. >>> >>> It looks like that for FreeIPA 4.4, we will need to live with DS >>> restart unless >>> there is some workaround... > couldn't the scenario I outline above with enabling dynamic plugins > only temporary work, are there any attempts to enable/disable plugins > during provisioning ? If that would be the case that would also > require a restart >> One more thing: >> >> How does it affect topologies with replicas? >> >> I might be wrong, but if memberOf is always computed locally then we >> have to >> disable it on *all* replicas. >> >> If we disabled it only on one replica and not others, the chosen >> replica would >> be way faster than rest of the topology and I'm not sure what would >> happen >> later on. > good point. we exclude memberof from replication as it is regenerated > on every server, so each replica would suffer from the performance > problem Right, that is a very good point. Provisioning will be slow (through direct update or replicated update) as soon as memberof is enabled. An option is to disable memberof only on the server receiving direct upates, provisioning will be fast, then let the topology converge with slow replication of the provisioned entries (fixup updates will not be replicated). An other option is to disable memberof on all replica, do the provisioning. Then run fixup on all the replicas. That means we have a mechanism to detect that all provisioned entries have been replicated before running fixup. >> >> Thierry, Ludwig, can you comment on this? >> > From pspacek at redhat.com Tue May 17 10:40:46 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 May 2016 12:40:46 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> Message-ID: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> On 13.5.2016 13:50, Stanislav Laznicka wrote: > Hello list, > > We had a discussion today over integrating the Time Rules into the CLI and > WebUI and a problem came up with with the current solution. It seems that > while having templating handled by CoSTemplates might be nice in terms of easy > dereferencing on SSSD side (it's handled by the DS itself), it's not really > much possible to pick one string from the multi-valued accesstime attribute of > HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek > We were thinking of a solution discussed way earlier - having our own time > rule objects that could be referenced from each HBAC rule. That way, any time > rule could be modified easily. As the HBAC rules are cached on the SSSD side > periodically using the deref plugin, there should be no problem of > inconsistency with the server database. > > The original reasoning pro and against the proposed solution could be found on > the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would > be really nice to hear your opinions and ideas that could help us overcome > this problem. > > Thank you, > Standa From ofayans at redhat.com Tue May 17 11:17:48 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 17 May 2016 13:17:48 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: <5739CFB0.6000607@redhat.com> References: <5739CFB0.6000607@redhat.com> Message-ID: <573AFDDC.2040207@redhat.com> Sorry, I forgot to list the tickets themselves On 05/16/2016 03:48 PM, Oleg Fayans wrote: > Hi, > > The design is OK, the onlz thing that is missing is a HowToTest section > in track tickets [1] and [2] about clean-dangling-ruvs and > abort-clean-ruv respectively. It would really help if these tickets had > detailed steps to test (in case of dangling RUV's - steps to generate them) > [1] https://fedorahosted.org/freeipa/ticket/5411 [2] https://fedorahosted.org/freeipa/ticket/5396 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jcholast at redhat.com Tue May 17 11:28:15 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 May 2016 13:28:15 +0200 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> References: <57161E1F.6020001@redhat.com> <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> Message-ID: <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> On 10.5.2016 12:36, Fraser Tweedale wrote: > Honza, thanks for the review. Comments inline. > > Copy Nalin, re certmonger discussion at the very bottom. > > On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote: >> Hi, >> ----8<------ >> 2) >> >> It should be mentioned here that the primary CA is also handled by this >> plugin. >> >> I would like to propose two additional fields: >> >> * subject (required) - subject name of the CA, to be able to look up >> sub-CA that issued a certificate from its issuer name. >> >> * issuer_ca (optional) - name of the sub-CA which issued certificate for >> this CA, to have information about the sub-CA hierarchy. If there is no >> sub-CA entry for the issuer, it would be unset. >> > These data exist in the Dogtag database. Adding them to IPA might > be useful for avoiding round trips so it is probably worth doing, > but are you aware of use cases that would absolutely require them? As for subject, we are adding the ability to look up information about arbitrary certificates to cert-{show,find} as part of . Part of this information should be whether the certificate was issued by our CA and what CA it was, so that the web UI can present an appropriate "revoke certificate" button for the certificate. As for issuer CA, I believe we need it to fix automatic CA certificate renewal. The current renewal code uses virtual "profiles" to handle CA certificate renewal, but that turned out to be an issue, especially with externally signed CA certificates: . Instead it could use the issuer CA information from LDAP to figure out what needs to be done. (Note that during the renewal, Dogtag is offline.) Also, both the attributes should be included for compatibility with external CAs. At this point, I think it's only a matter of time when support for them will be added (there were already several requests for such a feature), and I would very much prefer to have to maintain only a single code path for the generic stuff (which includes both of the attributes), instead of one for Dogtag and one for external CAs. > >> ----8<------ >> 4) >> >> """ >> For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which >> implements the KeyRetriever interface. It invokes a Python script that >> performs the retrieval, reusing existing FreeIPA Custodia client code. >> """ >> >> Will this be distributed with Dogtag or with IPA? >> > It's shipped in Dogtag. > >> The Python script bit sounds like an implementation detail rather than an >> actual design. Ideally the whole thing would be done in Java, right? >> > I removed the script from the design page (it had changed, though > not dramatically). It is written in Python so that we can reuse the > CustodiaClient. I figured as much. My point is that whether you are executing an external binary or using native code is an implementation detail, so it should not be in the "Design" section, but rather the "Implementation" section. > >> """ >> The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key >> and shall be executed as pkiuser. >> """ >> >> Could you please use a subdirectory? Like /usr/libexec/pki (if the script is >> going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is >> going to be distributed with IPA). >> > What is the rationale - is it a packaging guideline or just common > sense? I'm not sure if it's an actual guideline, but IMHO it's definitely common sense - I don't think littering the global namespace (i.e. /usr/libexec) is ever preferable to keeping your stuff in your own namespace. > >> """ >> pkiuser does not have read access to either of these locations, so a new >> service principal shall be created for each Dogtag CA instance for the >> purpose of authenticating to Custodia and retrieving lightweight CA private >> keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its >> keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and >> mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and >> /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively. >> """ >> >> Don't forget to update this paragraph with the new principal name. >> > Thanks, I updated it. > >> >> 5) >> >> """ >> A CA object for the top-level CA will initially be created, with DN >> cn=.,ou=cas,cn=ca,$SUFFIX. >> """ >> >> I would rather not use punctuation for the short name, as it can be easily >> overlooked (think logs). (Also it should be '/' if anything, not '.', which >> usually means "current".) >> >> Above you stated that the subject name will be derived from the short name >> of the sub-CA. The top-level CA has subject name of the form "CN=Certificate >> Authority,$SUBJECT_BASE", so its short name should be "Certificate >> Authority". >> > > This section was also part of the old design. The entry for the > host authority has ``ipaUniqueId=...`` as rightmost RDN, like other > CAs. The cn is ``host-authority``. Subject DN is no longer derived > from cn. Please don't use ipaUniqueId as the RDN unless absolutely necessary. Not only it makes debugging harder (because you can't tell which object is which just by looking at the DN), it also requires the framework to do an extra LDAP search every time the DN needs to be translated to primary key. "host-authority" does not strike me as something familiar, and the "host" bit is kind of confusing, since it is not at all related to IPA hosts. Could we use something more obvious ("default", "root", ...)? In the current schema, there are 3 different key attributes (cn, ipaUniqueId, ipaCaId). Can we reduce the number? I don't see anything that would mandate more than 2 (cn, ipaCaId). Would it be possible to have only 1 (cn)? Why does a Dogtag lightweight CA need to be created before the LDAP entry? I assume it's because deleting an LDAP entry is easier than deleting a Dogtag lightweight CA in case something goes wrong, in which case I think ipaCaId should be required and use a placeholder value in the initial LDAP entry. > >> >> 6) >> >> """ >> ipa ca-del >> >> Delete the given certificate authority. This will remove knowledge of the CA >> from the FreeIPA directory but will not delete the sub-CA from Dogtag. >> Dogtag will still know about the CA and the certificates it issued, be able >> to act at a CRL / OCSP authority for it, etc. >> """ >> >> What is the use case for this? Will the certificates issued by the sub-CA >> still be valid after delete or not? Will the sub-CA certificate be >> explicitly distrusted on delete or not? >> >> IMO it should be possible to delete only a leaf sub-CA, i.e. anything but >> the top-level CA in the current design. Judging from the updated design, it seems to me that the only thing ca-del does is that it prevents further certificate requests to the CA. If that's really the case, I think it should be replaced with a "ca-disable" command, since every other -del command makes the deleted object invalid for all uses. >> >> """ >> ipa cert-find [shortname] >> >> shortname >> Optional positional parameter to specify a sub-CA to use (omit to >> specify the top-level CA). The special shortname * is used to search in all >> CAs. >> """ >> >> This should be "ipa cert-find [--ca=]". At some point, cert-find >> should be fixed to be consistent with every other -find command and have an >> optional 'criteria' positional argument, and there can't be two optional >> positional arguments, as it creates an ambiguity. >> >> I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather >> than a magic value for an all-CA search. Magic value might work for >> cert-find alone, but you are creating a precedent for the whole framework >> here. >> > Design updated. No position arg anymore. No special arg for "all > CAs" - it is implied unless one of ``--issuer=DN`` or ``--ca=NAME`` > is given. > >> >> """ >> ipa cert-show [shortname] >> >> shortname >> Optional positional parameter to specify a sub-CA (omit to specify the >> top-level CA). >> --chain >> Request the certificate chain (when saving via --out , PEM format >> is used; this is the format uesd for the end-entity certificate). >> """ >> >> This should be "ipa cert-show [--ca=]", for consistency with >> cert-find, see above. >> > Actually, we do not (at the moment) need a CA argument, because > serial numbers are unique in the whole Dogtag instance. I have > removed the argument but if it makes a comeback in future, it will > be in the form you recommend. This is not right, for a number of reasons. First of all, it violates our object model. It may not be very apparent, as the cert plugin is currently implemented as a bunch of loosely related ad-hoc commands rather than an object with methods, but nonetheless, all of the commands which implement CRUD operations on certificates (cert-{request,status,show,revoke,remove-hold}) should have the same CA argument with the same default value, or no CA argument at all. Second, the design should not revolve around Dogtag implementation details, because implementation details, as well as the circumstances in which the feature is used, may change. In particular, this design would not work well with the aforementioned external CA support, because instead of using issuer+serial as unique identifier of certificates, it uses just serial and assumes it is unique among all issuers, which is generally not true. Last, -show commands are supposed to implement a retrieve operation, but what you are proposing is effectively a search for all certificates with a given serial number, which actually belongs to cert-find. > >> IMO it would make sense to add --chain to cert-request as well, it should be >> useful for certmonger. >> >> >> 7) >> >> How is a certificate going to be requested from a specific sub-CA using the >> getcert command? >> > I added a preliminary design; add a new certmonger property and > corresponding getcert-request(1) option for specifying the target > CA. > > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA LGTM. > > Alternative approaches involve overloading an existing property > (e.g. profile) to optionally carry both profile and CA. The > overloading could be handled in Certmonger or in FreeIPA. Either > way is feasible - both are nasty hacks! - but it is worth mentioning > the alternatives. I don't think the solution proposed in the design page is a hack. Overloading an existing property definitely is, so thanks for mentioning it, but please don't do it :-) > > Cheers, > Fraser > -- Jan Cholasta From redhatrises at gmail.com Tue May 17 12:29:38 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 17 May 2016 06:29:38 -0600 Subject: [Freeipa-devel] [PATCH] 0001 (update 2) provide more information for "ipa cert-revoke -h" In-Reply-To: References: <0ffbca59-c6ad-3f82-a4c6-127f0b8365e6@gmail.com> Message-ID: Patrice, Can you please send rebased version of this patch? Thanks, Gabe On Fri, May 6, 2016 at 6:45 AM, Martin Basti wrote: > > > On 04.05.2016 14:30, Gabe Alford wrote: > > On Wed, May 4, 2016 at 1:35 AM, Patrice Duc-Jacquet < > patduc38 at gmail.com> wrote: > >> Hi everyone >> >> this is a second update that take into account review feedback. >> >> In case the proposal fix is K what are the next step to commit this >> change. I'm not sure to really understand the process. Thanks and regards >> > > If the fix is good, you receive an ack and a core member of the FreeIPA > team will take your ack'ed patch and push it to the official git repository. > > ACK from me > > Gabe > > Pat >> >> >> -- >> 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 >> > > > > Hello, I agree with ACk, but I cannot apply the patch using git am -3, can > you please send rebased version? > > Martin^2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue May 17 12:50:29 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 17 May 2016 22:50:29 +1000 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> References: <57161E1F.6020001@redhat.com> <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> Message-ID: <20160517125029.GJ1323@dhcp-40-8.bne.redhat.com> On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote: > On 10.5.2016 12:36, Fraser Tweedale wrote: > > Honza, thanks for the review. Comments inline. > > > > Copy Nalin, re certmonger discussion at the very bottom. > > > > On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote: > > > Hi, > > > > > ----8<------ > > > > 2) > > > > > > It should be mentioned here that the primary CA is also handled by this > > > plugin. > > > > > > I would like to propose two additional fields: > > > > > > * subject (required) - subject name of the CA, to be able to look up > > > sub-CA that issued a certificate from its issuer name. > > > > > > * issuer_ca (optional) - name of the sub-CA which issued certificate for > > > this CA, to have information about the sub-CA hierarchy. If there is no > > > sub-CA entry for the issuer, it would be unset. > > > > > These data exist in the Dogtag database. Adding them to IPA might > > be useful for avoiding round trips so it is probably worth doing, > > but are you aware of use cases that would absolutely require them? > > As for subject, we are adding the ability to look up information about > arbitrary certificates to cert-{show,find} as part of > . Part of this information > should be whether the certificate was issued by our CA and what CA it was, > so that the web UI can present an appropriate "revoke certificate" button > for the certificate. > > As for issuer CA, I believe we need it to fix automatic CA certificate > renewal. The current renewal code uses virtual "profiles" to handle CA > certificate renewal, but that turned out to be an issue, especially with > externally signed CA certificates: > . Instead it could use > the issuer CA information from LDAP to figure out what needs to be done. > (Note that during the renewal, Dogtag is offline.) > > Also, both the attributes should be included for compatibility with external > CAs. At this point, I think it's only a matter of time when support for them > will be added (there were already several requests for such a feature), and > I would very much prefer to have to maintain only a single code path for the > generic stuff (which includes both of the attributes), instead of one for > Dogtag and one for external CAs. > OK, I'll add issuer DN and subject DN attributes to the ipaCa objectClass. > > > > > > > ----8<------ > > > > 4) > > > > > > """ > > > For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which > > > implements the KeyRetriever interface. It invokes a Python script that > > > performs the retrieval, reusing existing FreeIPA Custodia client code. > > > """ > > > > > > Will this be distributed with Dogtag or with IPA? > > > > > It's shipped in Dogtag. > > > > > The Python script bit sounds like an implementation detail rather than an > > > actual design. Ideally the whole thing would be done in Java, right? > > > > > I removed the script from the design page (it had changed, though > > not dramatically). It is written in Python so that we can reuse the > > CustodiaClient. > > I figured as much. My point is that whether you are executing an external > binary or using native code is an implementation detail, so it should not be > in the "Design" section, but rather the "Implementation" section. > Fair point; I'll move what remains the Implementation section. > > > > > """ > > > The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key > > > and shall be executed as pkiuser. > > > """ > > > > > > Could you please use a subdirectory? Like /usr/libexec/pki (if the script is > > > going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is > > > going to be distributed with IPA). > > > > > What is the rationale - is it a packaging guideline or just common > > sense? > > I'm not sure if it's an actual guideline, but IMHO it's definitely common > sense - I don't think littering the global namespace (i.e. /usr/libexec) is > ever preferable to keeping your stuff in your own namespace. > I'll drop the script in a subdir. While I'm at it, I think I will move it to the IPA codebase, to improve locality of the Python code. e.g. if CustodiaClient API or any other IPA Python API changes, the code in pki repo will be too easily missed. > > > > > """ > > > pkiuser does not have read access to either of these locations, so a new > > > service principal shall be created for each Dogtag CA instance for the > > > purpose of authenticating to Custodia and retrieving lightweight CA private > > > keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its > > > keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and > > > mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and > > > /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively. > > > """ > > > > > > Don't forget to update this paragraph with the new principal name. > > > > > Thanks, I updated it. > > > > > > > > 5) > > > > > > """ > > > A CA object for the top-level CA will initially be created, with DN > > > cn=.,ou=cas,cn=ca,$SUFFIX. > > > """ > > > > > > I would rather not use punctuation for the short name, as it can be easily > > > overlooked (think logs). (Also it should be '/' if anything, not '.', which > > > usually means "current".) > > > > > > Above you stated that the subject name will be derived from the short name > > > of the sub-CA. The top-level CA has subject name of the form "CN=Certificate > > > Authority,$SUBJECT_BASE", so its short name should be "Certificate > > > Authority". > > > > > > > This section was also part of the old design. The entry for the > > host authority has ``ipaUniqueId=...`` as rightmost RDN, like other > > CAs. The cn is ``host-authority``. Subject DN is no longer derived > > from cn. > > Please don't use ipaUniqueId as the RDN unless absolutely necessary. Not > only it makes debugging harder (because you can't tell which object is which > just by looking at the DN), it also requires the framework to do an extra > LDAP search every time the DN needs to be translated to primary key. > If cn is used in RDN, will changing cn (which then will be a modrdn operation) correctly update the references from CA ACLs? > "host-authority" does not strike me as something familiar, and the "host" > bit is kind of confusing, since it is not at all related to IPA hosts. Could > we use something more obvious ("default", "root", ...)? > We shouldn't use "root" because it might not be a root CA. We probably shouldn't use "default" because we might later want to allow different default CAs for different profiles or principal types. Perhaps simply "IPA CA", "ipa", or some variation on that theme? > In the current schema, there are 3 different key attributes (cn, > ipaUniqueId, ipaCaId). Can we reduce the number? I don't see anything that > would mandate more than 2 (cn, ipaCaId). Would it be possible to have only 1 > (cn)? > If we go with cn in RDN then ipaUniqueId can go away. ipaCaId is needed (stores Dogtag authority ID, which is a UUID and not user-controlled). As discussed above, there will now also be attributes for issuer DN and subject DN. > Why does a Dogtag lightweight CA need to be created before the LDAP entry? I > assume it's because deleting an LDAP entry is easier than deleting a Dogtag > lightweight CA in case something goes wrong, in which case I think ipaCaId > should be required and use a placeholder value in the initial LDAP entry. > The IPA object is created first to ensure that the user has the permissions to do so. Apart from that it is not important which happens first. I can check permissions with can_add() but defer IPA object creation until after the Dogtag LWCA has been created. In fact this is a cleaner approach. > > > > > > > > 6) > > > > > > """ > > > ipa ca-del > > > > > > Delete the given certificate authority. This will remove knowledge of the CA > > > from the FreeIPA directory but will not delete the sub-CA from Dogtag. > > > Dogtag will still know about the CA and the certificates it issued, be able > > > to act at a CRL / OCSP authority for it, etc. > > > """ > > > > > > What is the use case for this? Will the certificates issued by the sub-CA > > > still be valid after delete or not? Will the sub-CA certificate be > > > explicitly distrusted on delete or not? > > > > > > IMO it should be possible to delete only a leaf sub-CA, i.e. anything but > > > the top-level CA in the current design. > > Judging from the updated design, it seems to me that the only thing ca-del > does is that it prevents further certificate requests to the CA. If that's > really the case, I think it should be replaced with a "ca-disable" command, > since every other -del command makes the deleted object invalid for all > uses. > ca-del results in deletion of the signing key from Dogtag's NSSDB, and deletion of the Dogtag lightweight authority object. On IPA side it removes the ipaCa object, removes references from CA ACLs, etc. ca-del should be a command. We can add ca-disable and ca-enable - these behaviours are implemented in Dogtag already. I prefer the more fine-grained control that CA ACLs give you, but I suppose people will want wholesale enable/disable as well? Or is it premature to assume so? > > > > > > """ > > > ipa cert-find [shortname] > > > > > > shortname > > > Optional positional parameter to specify a sub-CA to use (omit to > > > specify the top-level CA). The special shortname * is used to search in all > > > CAs. > > > """ > > > > > > This should be "ipa cert-find [--ca=]". At some point, cert-find > > > should be fixed to be consistent with every other -find command and have an > > > optional 'criteria' positional argument, and there can't be two optional > > > positional arguments, as it creates an ambiguity. > > > > > > I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather > > > than a magic value for an all-CA search. Magic value might work for > > > cert-find alone, but you are creating a precedent for the whole framework > > > here. > > > > > Design updated. No position arg anymore. No special arg for "all > > CAs" - it is implied unless one of ``--issuer=DN`` or ``--ca=NAME`` > > is given. > > > > > > > > """ > > > ipa cert-show [shortname] > > > > > > shortname > > > Optional positional parameter to specify a sub-CA (omit to specify the > > > top-level CA). > > > --chain > > > Request the certificate chain (when saving via --out , PEM format > > > is used; this is the format uesd for the end-entity certificate). > > > """ > > > > > > This should be "ipa cert-show [--ca=]", for consistency with > > > cert-find, see above. > > > > > Actually, we do not (at the moment) need a CA argument, because > > serial numbers are unique in the whole Dogtag instance. I have > > removed the argument but if it makes a comeback in future, it will > > be in the form you recommend. > > This is not right, for a number of reasons. > > First of all, it violates our object model. It may not be very apparent, as > the cert plugin is currently implemented as a bunch of loosely related > ad-hoc commands rather than an object with methods, but nonetheless, all of > the commands which implement CRUD operations on certificates > (cert-{request,status,show,revoke,remove-hold}) should have the same CA > argument with the same default value, or no CA argument at all. > > Second, the design should not revolve around Dogtag implementation details, > because implementation details, as well as the circumstances in which the > feature is used, may change. In particular, this design would not work well > with the aforementioned external CA support, because instead of using > issuer+serial as unique identifier of certificates, it uses just serial and > assumes it is unique among all issuers, which is generally not true. > Your reasoning is irrefutable :) There shall be a CA argument, defaulting to the top-level CA. > Last, -show commands are supposed to implement a retrieve operation, but > what you are proposing is effectively a search for all certificates with a > given serial number, which actually belongs to cert-find. > > > > > > IMO it would make sense to add --chain to cert-request as well, it should be > > > useful for certmonger. > > > > > > > > > 7) > > > > > > How is a certificate going to be requested from a specific sub-CA using the > > > getcert command? > > > > > I added a preliminary design; add a new certmonger property and > > corresponding getcert-request(1) option for specifying the target > > CA. > > > > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA > > LGTM. > Cool, thanks! > > > > Alternative approaches involve overloading an existing property > > (e.g. profile) to optionally carry both profile and CA. The > > overloading could be handled in Certmonger or in FreeIPA. Either > > way is feasible - both are nasty hacks! - but it is worth mentioning > > the alternatives. > > I don't think the solution proposed in the design page is a hack. > Overloading an existing property definitely is, so thanks for mentioning it, > but please don't do it :-) > Ah, "both" meant the two overloading options - overloading in Certmonger or in IPA. I am encouraged that you do not consider the actual proposal a hack. But the implementation is yet to come ;) Honza, thank you for your ongoing input. I will update the design page tomorrow. Cheers, Fraser From dkupka at redhat.com Tue May 17 13:25:22 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 17 May 2016 15:25:22 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> Message-ID: On 28/04/16 14:45, Jan Cholasta wrote: > Hi, > > I have pushed my thin client WIP branch to GitHub: > . > > All commits up to "ipalib: use relative imports for cross-plugin > imports" should be good for review. The rest is subject to change > (WARNING: I will force push into this branch). > > Honza > Hi, I have fought my way through the patch set up to "frontend: allow commands to have an argument named `name`" (including). The code looks good to me but I haven't dive into parts that was pure Cut&Paste. I assume that when it worked before it will still work. Some problems pop out in tests: user_plugin: http://paste.fedoraproject.org/367502/34888591/ This can be fixed with simple patch: http://paste.fedoraproject.org/367503/14634889/ With patch applied there are still some errors: http://paste.fedoraproject.org/367519/49007414/ -- David Kupka From pvoborni at redhat.com Tue May 17 14:41:16 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 17 May 2016 16:41:16 +0200 Subject: [Freeipa-devel] feature template: "How to test" section renamed to "How to use" Message-ID: <99ed3e0b-ed71-e771-3b97-4b84fb2dfd91@redhat.com> New text: """ == How to Use == Easy to follow instructions how to use the new feature according to the [[#Use_Cases|use cases]] described above. FreeIPA user needs to be able to follow the steps and demonstrate the new features. The chapter may be divided in sub-sections per [[#Use_Cases|Use Case]]. """ Why this change? The section was not filled in 46% of design pages in 4.4 release. The section was always indented to help contributors, other than developers with deep knowledge of FreeIPA internals, to understand how the new feature is intended to be used when it is developed. The name implied content similar to a test plan. My assumption is that it is one of the reasons why it was not filled. I also intend to add a comment with target audience to each section. Comments welcome! http://www.freeipa.org/page/Feature_template#How_to_Test -- Petr Vobornik From nalin at redhat.com Tue May 17 14:43:18 2016 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 17 May 2016 10:43:18 -0400 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> References: <57161E1F.6020001@redhat.com> <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> Message-ID: <20160517144318.GA16978@redhat.com> On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote: > > > 7) > > > > > > How is a certificate going to be requested from a specific sub-CA using the > > > getcert command? > > > > > I added a preliminary design; add a new certmonger property and > > corresponding getcert-request(1) option for specifying the target > > CA. > > > > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA > > LGTM. Ditto. I prefer handling it as a separate property over turning the profile name into a tuple. Cheers, Nalin From mharmsen at redhat.com Wed May 18 00:45:20 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 17 May 2016 18:45:20 -0600 Subject: [Freeipa-devel] Updated External EPEL CentOS 7 COPR builds are now available . . . Message-ID: <573BBB20.5010609@redhat.com> An updated external EPEL CentOS 7 COPR repo is available now available which contains Dogtag 10.3.1 builds: * https://copr.fedorainfracloud.org/coprs/g/pki/10.3.1/repo/epel-7/group_pki-10.3.1-epel-7.repo [group_pki-10.3.1] name=Copr repo for 10.3.1 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.1/epel-7-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.1/pubkey.gpg enabled=1 enabled_metadata=1 -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed May 18 06:01:11 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 May 2016 08:01:11 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> Message-ID: On 16.5.2016 16:35, Martin Basti wrote: > > > On 09.05.2016 14:07, Jan Cholasta wrote: >> On 6.5.2016 14:32, Martin Basti wrote: >>> >>> >>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>> Hi, >>>> >>>> I have pushed my thin client WIP branch to GitHub: >>>> . >>>> >>>> All commits up to "ipalib: use relative imports for cross-plugin >>>> imports" should be good for review. The rest is subject to change >>>> (WARNING: I will force push into this branch). >>>> >>>> Honza >>>> >>> I did not test it yet, I just checked the code >>> >>> * automount: do not inherit automountlocation_tofiles from LDAPQuery * >>> LGTM >>> >>> * dns: move all dnsrecord code called on client to a single class * >>> LGTM >>> >>> * dns: do not rely on server data structures in code called on client * >>> 1) >>> you forgot to increment VERSION >> >> This was deliberate, as it will no longer be necessary to bump VERSION >> for backward compatible changes after this whole patchset is merged. >> But we're not there yet, so fixed. >> > How we should handle VERSION after your patches? >>> >>> Otherwise LGTM >>> >>> * otptoken: fix import of DN * >>> ACK >>> >>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>> 1) >>> you forgot to increment VERSION >> >> Fixed. >> >>> >>> 2) >>> Did you find out why this was issue? >>> - del answer['value'] # Why does this cause an error if >>> omitted? >>> - del answer['summary'] # Why does this cause an error if >>> omitted? >> >> The command definition was not complete, it was missing has_output. >> >>> >>> Otherwise LGTM >>> >>> * vault: move client-side code to the module level * >>> LGTM >>> >>> * vault: copy arguments of client commands from server counterparts * >>> 1) >>> you forgot to increment Version >> >> Fixed. >> >>> >>> * ipalib: use relative imports for cross-plugin imports * >>> 1) Missing explanation for future generations why this change is needed >>> in commit message >> >> Fixed. >> >>> >>> The other commits I will check later. >>> Martin^2 >>> >> >> Okay. Thanks. >> > > * frontend: remove the unused Command.soft_validate method > LGTM > > * frontend: perform argument value validation only on server > LGTM > > * frontend: do not forward argument defaults to server > I'm not a fan of returning None in promt_param function, but I havent > found anything better to use. It always returned None for unset params. > LGTM > > * ipalib: optimize API.txt > this contains a lot of black magic, but because this is mainly copy of > current to proper places, LGTM It's actually mostly cut-n-paste. > > * makeaci: load additional plugins using API.add_module > Looks good, but I miss explanation why is this change needed The next change would be impossible without this. > > * plugable: replace API.import_plugins with new API.add_package > LGTM > > > * ipalib, ipaserver: migrate all plugins to Registry-based registration > ACK > > * ipalib, ipaserver: fix incorrect API.register calls in docstrings > LGTM > > > * plugable: remove the unused deprecated API.register method > LGTM > > > * plugable: switch API to Registry-based plugin discovery > LGTM > > * frontend: merge baseldap.CallbackRegistry into Command > LGTM > > *frontend: move the interactive_prompt callback type to Command > LGTM > > Martin^2 > > -- Jan Cholasta From ftweedal at redhat.com Wed May 18 06:09:20 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 18 May 2016 16:09:20 +1000 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> Message-ID: <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> Rebased version of 0057 attached, along with new patch 0058 that detects when the Dogtag version of caIPAserviceCert has been erroneously imported and repairs the profile. Thanks, Fraser -------------- next part -------------- From 9994a98a0cd3bcf6b4af72708c7ac1cfdfdd5440 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 3ca4fa8d373ebc3375a9fc75b59969292f0198f0..7e68b832831c3487c7bda466ba04d1a3eb51e780 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1764,7 +1764,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1816,12 +1818,17 @@ def migrate_profiles_to_ldap(dogtag_constants): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1832,9 +1839,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 -------------- next part -------------- From 9524513a6e7c1e9da7d0a20dfec1d1566158cef0 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 10bc2afc416737e89ffa7255e50bec96eb86fcce..274694012d5afc8690c4d69356d5ae56ae0a44e1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1665,7 +1665,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1717,12 +1719,17 @@ def migrate_profiles_to_ldap(): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1733,9 +1740,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 -------------- next part -------------- From 67080ad78af7f701d3be266eaf9c42ee30e12a21 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 11 May 2016 16:13:51 +1000 Subject: [PATCH] Prevent replica install from overwriting cert profiles An earlier change that unconditionally triggers import of file-based profiles to LDAP during server or replica install results in replicas overwriting FreeIPA-managed profiles with profiles of the same name shipped with Dogtag. ('caIPAserviceCert' is the affected profile). Avoid this situation by never overwriting existing profiles during the LDAP import. Fixes: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a21f7d2671461dfb99797d39fc7ee5706317241f..7ba5a5ae72bea656c5818a9fd5909926eb4886d1 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1664,7 +1664,9 @@ def import_included_profiles(): conn.add_entry(entry) profile_data = ipautil.template_file( '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) - _create_dogtag_profile(profile_id, profile_data) + + # Create the profile, replacing any existing profile of same name + _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) api.Backend.ra_certprofile.override_port = None @@ -1716,12 +1718,17 @@ def migrate_profiles_to_ldap(): profile_data += '\n' profile_data += 'profileId={}\n'.format(profile_id) profile_data += 'classId={}\n'.format(class_id) - _create_dogtag_profile(profile_id, profile_data) + + # Import the profile, but do not replace it if it already exists. + # This prevents replicas from replacing IPA-managed profiles with + # Dogtag default profiles of same name. + # + _create_dogtag_profile(profile_id, profile_data, overwrite=False) api.Backend.ra_certprofile.override_port = None -def _create_dogtag_profile(profile_id, profile_data): +def _create_dogtag_profile(profile_id, profile_data, overwrite): with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1732,9 +1739,8 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug("Error migrating '{}': {}".format( profile_id, e)) - # conflicting profile; replace it if we are - # installing IPA, but keep it for upgrades - if api.env.context == 'installer': + # profile already exists + if overwrite: try: profile_api.disable_profile(profile_id) except errors.RemoteRetrieveError: -- 2.5.5 -------------- next part -------------- From c990ff5f8b376503a93ac661ced76fdda815243d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 18 May 2016 14:10:39 +1000 Subject: [PATCH] Detect and repair incorrect caIPAserviceCert config A regression caused replica installation to replace the FreeIPA version of caIPAserviceCert with the version shipped by Dogtag. During upgrade, detect and repair occurrences of this problem. Part of: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 49 ++++++++++++++++++++++++++++++++++--- ipaserver/install/server/upgrade.py | 3 +++ 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 274694012d5afc8690c4d69356d5ae56ae0a44e1..1413f4ddc56959db7c4ebc897fc0d191999e85e2 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1619,14 +1619,18 @@ def configure_profiles_acl(): conn.disconnect() return updated -def import_included_profiles(): + +def __get_profile_config(profile_id): sub_dict = dict( DOMAIN=ipautil.format_netloc(api.env.domain), IPA_CA_RECORD=IPA_CA_RECORD, CRL_ISSUER='CN=Certificate Authority,o=ipaca', SUBJECT_DN_O=dsinstance.DsInstance().find_subject_base(), ) + return ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) +def import_included_profiles(): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) @@ -1663,10 +1667,9 @@ def import_included_profiles(): ipacertprofilestoreissued=['TRUE' if store_issued else 'FALSE'], ) conn.add_entry(entry) - profile_data = ipautil.template_file( - '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) # Create the profile, replacing any existing profile of same name + profile_data = __get_profile_config(profile_id) _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) @@ -1674,6 +1677,46 @@ def import_included_profiles(): conn.disconnect() +def repair_profile_caIPAserviceCert(): + """ + A regression caused replica installation to replace the FreeIPA + version of caIPAserviceCert with the version shipped by Dogtag. + + This function detects and repairs occurrences of this problem. + + """ + api.Backend.ra_certprofile._read_password() + api.Backend.ra_certprofile.override_port = 8443 + + profile_id = 'caIPAserviceCert' + + with api.Backend.ra_certprofile as profile_api: + try: + cur_config = profile_api.read_profile(profile_id).splitlines() + except errors.RemoteRetrieveError as e: + # no profile there to check/repair + api.Backend.ra_certprofile.override_port = None + return + + indicators = [ + "policyset.serverCertSet.1.default.params.name=" + "CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA ", + "policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=" + "https://ipa.example.com/ipa/crl/MasterCRL.bin", + ] + need_repair = all(l in cur_config for l in indicators) + + if need_repair: + root_logger.debug( + "Detected that profile '{}' has been replaced with " + "incorrect version; begin repair.".format(profile_id)) + _create_dogtag_profile( + profile_id, __get_profile_config(profile_id), overwrite=True) + root_logger.debug("Repair of profile '{}' complete.".format(profile_id)) + + api.Backend.ra_certprofile.override_port = None + + def migrate_profiles_to_ldap(): """Migrate profiles from filesystem to LDAP. diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index e6bce6694f2a4bed99a714c6907f040f73c19423..045a4f6dc10b49921b2a3f451083ea4aa133175c 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1658,6 +1658,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + cainstance.repair_profile_caIPAserviceCert() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 -------------- next part -------------- From 001151508bc8e3e40ec7cec077ec850fc3eccbf9 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 18 May 2016 14:10:39 +1000 Subject: [PATCH] Detect and repair incorrect caIPAserviceCert config A regression caused replica installation to replace the FreeIPA version of caIPAserviceCert with the version shipped by Dogtag. During upgrade, detect and repair occurrences of this problem. Part of: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 49 ++++++++++++++++++++++++++++++++++--- ipaserver/install/server/upgrade.py | 3 +++ 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 7e68b832831c3487c7bda466ba04d1a3eb51e780..adbe968a429a6de5ed5c7a147bb6fda76127f444 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1718,14 +1718,18 @@ def configure_profiles_acl(): conn.disconnect() return updated -def import_included_profiles(): + +def __get_profile_config(profile_id): sub_dict = dict( DOMAIN=ipautil.format_netloc(api.env.domain), IPA_CA_RECORD=IPA_CA_RECORD, CRL_ISSUER='CN=Certificate Authority,o=ipaca', SUBJECT_DN_O=dsinstance.DsInstance().find_subject_base(), ) + return ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) +def import_included_profiles(): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) @@ -1762,10 +1766,9 @@ def import_included_profiles(): ipacertprofilestoreissued=['TRUE' if store_issued else 'FALSE'], ) conn.add_entry(entry) - profile_data = ipautil.template_file( - '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) # Create the profile, replacing any existing profile of same name + profile_data = __get_profile_config(profile_id) _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) @@ -1773,6 +1776,46 @@ def import_included_profiles(): conn.disconnect() +def repair_profile_caIPAserviceCert(): + """ + A regression caused replica installation to replace the FreeIPA + version of caIPAserviceCert with the version shipped by Dogtag. + + This function detects and repairs occurrences of this problem. + + """ + api.Backend.ra_certprofile._read_password() + api.Backend.ra_certprofile.override_port = 8443 + + profile_id = 'caIPAserviceCert' + + with api.Backend.ra_certprofile as profile_api: + try: + cur_config = profile_api.read_profile(profile_id).splitlines() + except errors.RemoteRetrieveError as e: + # no profile there to check/repair + api.Backend.ra_certprofile.override_port = None + return + + indicators = [ + "policyset.serverCertSet.1.default.params.name=" + "CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA ", + "policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=" + "https://ipa.example.com/ipa/crl/MasterCRL.bin", + ] + need_repair = all(l in cur_config for l in indicators) + + if need_repair: + root_logger.debug( + "Detected that profile '{}' has been replaced with " + "incorrect version; begin repair.".format(profile_id)) + _create_dogtag_profile( + profile_id, __get_profile_config(profile_id), overwrite=True) + root_logger.debug("Repair of profile '{}' complete.".format(profile_id)) + + api.Backend.ra_certprofile.override_port = None + + def migrate_profiles_to_ldap(dogtag_constants): """Migrate profiles from filesystem to LDAP. diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index c53b19a937d559b25da256670a5205ab40e0cadb..b0cd789d58408f720774adb276843a1b6ab6007d 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1554,6 +1554,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + cainstance.repair_profile_caIPAserviceCert() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 -------------- next part -------------- From cf49fc421a4aa163cd213a362093ad595049a781 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 18 May 2016 14:10:39 +1000 Subject: [PATCH] Detect and repair incorrect caIPAserviceCert config A regression caused replica installation to replace the FreeIPA version of caIPAserviceCert with the version shipped by Dogtag. During upgrade, detect and repair occurrences of this problem. Part of: https://fedorahosted.org/freeipa/ticket/5881 --- ipaserver/install/cainstance.py | 49 ++++++++++++++++++++++++++++++++++--- ipaserver/install/server/upgrade.py | 3 +++ 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 7ba5a5ae72bea656c5818a9fd5909926eb4886d1..337a07797b26ff668f95d139ab35fbe491e6b470 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1618,14 +1618,18 @@ def configure_profiles_acl(): conn.disconnect() return updated -def import_included_profiles(): + +def __get_profile_config(profile_id): sub_dict = dict( DOMAIN=ipautil.format_netloc(api.env.domain), IPA_CA_RECORD=IPA_CA_RECORD, CRL_ISSUER='CN=Certificate Authority,o=ipaca', SUBJECT_DN_O=dsinstance.DsInstance().find_subject_base(), ) + return ipautil.template_file( + '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) +def import_included_profiles(): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) @@ -1662,10 +1666,9 @@ def import_included_profiles(): ipacertprofilestoreissued=['TRUE' if store_issued else 'FALSE'], ) conn.add_entry(entry) - profile_data = ipautil.template_file( - '/usr/share/ipa/profiles/{}.cfg'.format(profile_id), sub_dict) # Create the profile, replacing any existing profile of same name + profile_data = __get_profile_config(profile_id) _create_dogtag_profile(profile_id, profile_data, overwrite=True) root_logger.info("Imported profile '%s'", profile_id) @@ -1673,6 +1676,46 @@ def import_included_profiles(): conn.disconnect() +def repair_profile_caIPAserviceCert(): + """ + A regression caused replica installation to replace the FreeIPA + version of caIPAserviceCert with the version shipped by Dogtag. + + This function detects and repairs occurrences of this problem. + + """ + api.Backend.ra_certprofile._read_password() + api.Backend.ra_certprofile.override_port = 8443 + + profile_id = 'caIPAserviceCert' + + with api.Backend.ra_certprofile as profile_api: + try: + cur_config = profile_api.read_profile(profile_id).splitlines() + except errors.RemoteRetrieveError as e: + # no profile there to check/repair + api.Backend.ra_certprofile.override_port = None + return + + indicators = [ + "policyset.serverCertSet.1.default.params.name=" + "CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA ", + "policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=" + "https://ipa.example.com/ipa/crl/MasterCRL.bin", + ] + need_repair = all(l in cur_config for l in indicators) + + if need_repair: + root_logger.debug( + "Detected that profile '{}' has been replaced with " + "incorrect version; begin repair.".format(profile_id)) + _create_dogtag_profile( + profile_id, __get_profile_config(profile_id), overwrite=True) + root_logger.debug("Repair of profile '{}' complete.".format(profile_id)) + + api.Backend.ra_certprofile.override_port = None + + def migrate_profiles_to_ldap(): """Migrate profiles from filesystem to LDAP. diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 38fe2c3e89da55faa30c624983cb8f9c630357b3..375d18522e9cfcf6d85c7a65b7be259bdd364134 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1643,6 +1643,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + cainstance.repair_profile_caIPAserviceCert() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 From slaznick at redhat.com Wed May 18 06:25:40 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 08:25:40 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> Message-ID: <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> On 05/17/2016 12:40 PM, Petr Spacek wrote: > On 13.5.2016 13:50, Stanislav Laznicka wrote: >> Hello list, >> >> We had a discussion today over integrating the Time Rules into the CLI and >> WebUI and a problem came up with with the current solution. It seems that >> while having templating handled by CoSTemplates might be nice in terms of easy >> dereferencing on SSSD side (it's handled by the DS itself), it's not really >> much possible to pick one string from the multi-valued accesstime attribute of >> HBAC Rule object and modify it. > Could you be more specific? > > AFAIK LDAP protocol allows this. Where is the problem? > > Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? > >> We were thinking of a solution discussed way earlier - having our own time >> rule objects that could be referenced from each HBAC rule. That way, any time >> rule could be modified easily. As the HBAC rules are cached on the SSSD side >> periodically using the deref plugin, there should be no problem of >> inconsistency with the server database. >> >> The original reasoning pro and against the proposed solution could be found on >> the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would >> be really nice to hear your opinions and ideas that could help us overcome >> this problem. >> >> Thank you, >> Standa From pvoborni at redhat.com Wed May 18 07:43:12 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 May 2016 09:43:12 +0200 Subject: [Freeipa-devel] Karma Request for Dogtag 10.3.1 on Fedora 24 In-Reply-To: <573BA931.4010202@redhat.com> References: <573BA931.4010202@redhat.com> Message-ID: <9228ccf8-f0ef-b371-6360-1a8cb553efa0@redhat.com> raising awareness -------- Forwarded Message -------- Subject: Karma Request for Dogtag 10.3.1 on Fedora 24 Date: Tue, 17 May 2016 17:28:49 -0600 From: Matthew Harmsen The following candidate builds of Dogtag 10.3.1 for Fedora 24 (final) consist of the following: * dogtag-pki-theme-10.3.1-1.fc24 * dogtag-pki-10.3.1-1.fc24 * pki-core-10.3.1-1.fc24 * pki-console-10.3.1-1.fc24 Please provide Karma for these builds in Bodhi located at: * dogtag-pki-theme-10.3.1-1.fc24 * dogtag-pki-10.3.1-1.fc24 * pki-core-10.3.1-1.fc24 * pki-console-10.3.1-1.fc24 Additionally, the following builds have been provided for Fedora 25 (rawhide): * dogtag-pki-theme-10.3.1-1.fc25 * dogtag-pki-10.3.1-1.fc25 * pki-core-10.3.1-1.fc25 * pki-console-10.3.1-1.fc25 Thanks, -- Matt From ldoudova at redhat.com Wed May 18 08:37:05 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 18 May 2016 10:37:05 +0200 Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set In-Reply-To: <5735B5AD.9050803@redhat.com> References: <5735B5AD.9050803@redhat.com> Message-ID: <573C29B1.1010502@redhat.com> Bump for review (Ganna) Thanks, Lenka On 05/13/2016 01:08 PM, Lenka Doudova wrote: > Patch attached. > > Lenka > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From placko at redhat.com Wed May 18 09:07:19 2016 From: placko at redhat.com (Peter Lacko) Date: Wed, 18 May 2016 05:07:19 -0400 (EDT) Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <43757ad0-fbc6-cbf7-6c00-179d1ba7b3d3@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> <1877307538.52247950.1463144714968.JavaMail.zimbra@redhat.com> <43757ad0-fbc6-cbf7-6c00-179d1ba7b3d3@redhat.com> Message-ID: <1003473753.53492942.1463562439336.JavaMail.zimbra@redhat.com> So last one (hopefully). Peter ----- Original Message ----- From: "Martin Basti" To: "Peter Lacko" Cc: freeipa-devel at redhat.com Sent: Monday, May 16, 2016 6:32:49 PM Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way On 13.05.2016 15:05, Peter Lacko wrote: > Desciption added back, header changed to original. > > Peter > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" > Cc: freeipa-devel at redhat.com > Sent: Friday, May 13, 2016 2:02:00 PM > Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way > > > > On 13.05.2016 13:59, Peter Lacko wrote: >> Hi, >> >> Thanks again, will remember that. I also changed header to short one. >> >> Peter > Whyyy? > > >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Peter Lacko" , freeipa-devel at redhat.com >> Sent: Tuesday, May 10, 2016 12:23:13 PM >> Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way >> >> >> >> On 28.04.2016 16:09, Martin Basti wrote: >>> On 08.04.2016 10:32, Peter Lacko wrote: >>> Hello, >>> >>> I have a few comments: >>> >>> 1) >>> Please set up your git name and email correctly (consistently for all >>> patches) >>> this is not right From: root >>> >>> 2) >>> -# Copyright (C) 2012 Red Hat >>> +# Copyright (C) 2016 Red Hat >>> >>> leave there both years please >>> +# Copyright (C) 2012, 2016 Red Hat >>> >>> 3) >>> Please put the patch number to the email subject, it is easier to find correct patch for us >>> >>> Otherwise LGTM and works for me. >>> >>> Martin^2 >>> >>> >> Sorry I didn't noticed earlier, but your patch doesn't work under python3 >> >> from xmlrpc_test import XMLRPC_test, raises_exact >> E ImportError: No module named 'xmlrpc_test' >> >> You must use absolute import, not relative in py3 >> >> Martin^2 Sorry, NACK ************* Module ipatests.test_xmlrpc.test_ping_plugin ipatests/test_xmlrpc/test_ping_plugin.py:29: [E0611(no-name-in-module), ] No name 'test_xmplrpc' in module 'ipatests') did you mean 'test_xmlrpc'? Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0001-5-Ping-module-tests.patch Type: text/x-patch Size: 2988 bytes Desc: not available URL: From pspacek at redhat.com Wed May 18 10:23:46 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 May 2016 12:23:46 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> Message-ID: <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> On 18.5.2016 08:25, Stanislav Laznicka wrote: > On 05/17/2016 12:40 PM, Petr Spacek wrote: >> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>> Hello list, >>> >>> We had a discussion today over integrating the Time Rules into the CLI and >>> WebUI and a problem came up with with the current solution. It seems that >>> while having templating handled by CoSTemplates might be nice in terms of easy >>> dereferencing on SSSD side (it's handled by the DS itself), it's not really >>> much possible to pick one string from the multi-valued accesstime attribute of >>> HBAC Rule object and modify it. >> Could you be more specific? >> >> AFAIK LDAP protocol allows this. Where is the problem? >> >> Petr^2 Spacek > I should have added we're talking CLI and WebUI here. > > Imagine you have 5 values of the accesstime attribute, each one is about 10 > lines of iCal string, and want to change one: > > ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? Petr^2 Spacek >>> We were thinking of a solution discussed way earlier - having our own time >>> rule objects that could be referenced from each HBAC rule. That way, any time >>> rule could be modified easily. As the HBAC rules are cached on the SSSD side >>> periodically using the deref plugin, there should be no problem of >>> inconsistency with the server database. >>> >>> The original reasoning pro and against the proposed solution could be found on >>> the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would >>> be really nice to hear your opinions and ideas that could help us overcome >>> this problem. >>> >>> Thank you, >>> Standa From jcholast at redhat.com Wed May 18 10:38:35 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 May 2016 12:38:35 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> Message-ID: <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> On 18.5.2016 12:23, Petr Spacek wrote: > On 18.5.2016 08:25, Stanislav Laznicka wrote: >> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>> Hello list, >>>> >>>> We had a discussion today over integrating the Time Rules into the CLI and >>>> WebUI and a problem came up with with the current solution. It seems that >>>> while having templating handled by CoSTemplates might be nice in terms of easy >>>> dereferencing on SSSD side (it's handled by the DS itself), it's not really >>>> much possible to pick one string from the multi-valued accesstime attribute of >>>> HBAC Rule object and modify it. >>> Could you be more specific? >>> >>> AFAIK LDAP protocol allows this. Where is the problem? >>> >>> Petr^2 Spacek >> I should have added we're talking CLI and WebUI here. >> >> Imagine you have 5 values of the accesstime attribute, each one is about 10 >> lines of iCal string, and want to change one: >> >> ipa hbacrule-mod-accesstime rule_name --time=??? > > I see. In DNS plugin we do it this way: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli > > $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 > > I would argue that naming of the options is weird so something easier to > understand could be made. E.g. > $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". > > Petr^2 Spacek > >>>> We were thinking of a solution discussed way earlier - having our own time >>>> rule objects that could be referenced from each HBAC rule. That way, any time >>>> rule could be modified easily. As the HBAC rules are cached on the SSSD side >>>> periodically using the deref plugin, there should be no problem of >>>> inconsistency with the server database. >>>> >>>> The original reasoning pro and against the proposed solution could be found on >>>> the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would >>>> be really nice to hear your opinions and ideas that could help us overcome >>>> this problem. >>>> >>>> Thank you, >>>> Standa > -- Jan Cholasta From slaznick at redhat.com Wed May 18 10:43:54 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 12:43:54 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> Message-ID: <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> On 05/18/2016 12:38 PM, Jan Cholasta wrote: > On 18.5.2016 12:23, Petr Spacek wrote: >> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>> Hello list, >>>>> >>>>> We had a discussion today over integrating the Time Rules into the >>>>> CLI and >>>>> WebUI and a problem came up with with the current solution. It >>>>> seems that >>>>> while having templating handled by CoSTemplates might be nice in >>>>> terms of easy >>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>> not really >>>>> much possible to pick one string from the multi-valued accesstime >>>>> attribute of >>>>> HBAC Rule object and modify it. >>>> Could you be more specific? >>>> >>>> AFAIK LDAP protocol allows this. Where is the problem? >>>> >>>> Petr^2 Spacek >>> I should have added we're talking CLI and WebUI here. >>> >>> Imagine you have 5 values of the accesstime attribute, each one is >>> about 10 >>> lines of iCal string, and want to change one: >>> >>> ipa hbacrule-mod-accesstime rule_name --time=??? >> >> I see. In DNS plugin we do it this way: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >> >> >> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >> --a-ip-address 192.0.2.1 >> >> I would argue that naming of the options is weird so something easier to >> understand could be made. E.g. >> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? > > NACK, the dns plugin should not be used as an example for anything, as > it breaks almost every convention in the framework. Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. > > Removing and adding of particular accesstime values should be done by > a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and > "hbacrule-remove-accesstime rule_name accesstime". > What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). >> >>>>> We were thinking of a solution discussed way earlier - having our >>>>> own time >>>>> rule objects that could be referenced from each HBAC rule. That >>>>> way, any time >>>>> rule could be modified easily. As the HBAC rules are cached on the >>>>> SSSD side >>>>> periodically using the deref plugin, there should be no problem of >>>>> inconsistency with the server database. >>>>> >>>>> The original reasoning pro and against the proposed solution could >>>>> be found on >>>>> the pad >>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>> would >>>>> be really nice to hear your opinions and ideas that could help us >>>>> overcome >>>>> this problem. >>>>> >>>>> Thank you, >>>>> Standa >> > > From mbasti at redhat.com Wed May 18 10:43:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 May 2016 12:43:43 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> Message-ID: <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> On 12.05.2016 16:16, Martin Basti wrote: > > > > On 12.05.2016 11:01, Martin Basti wrote: >> >> >> On 11.05.2016 09:41, Martin Basti wrote: >>> >>> >>> On 10.05.2016 18:56, Petr Spacek wrote: >>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>> >>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>> >>>>>>>>>> Patches attached. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>>> 00:00:00 2001 >>>>>>>>>> From: Martin Basti >>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>>>> privileges >>>>>>>>>> >>>>>>>>>> DNS privileges are important for handling DNS locations which >>>>>>>>>> can be >>>>>>>>>> created without DNS servers in IPA topology. We will also >>>>>>>>>> need this >>>>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>>>> Seems reasonable, ACK. >>>>>>>>> >>>>>>>>> >>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>>> 00:00:00 2001 >>>>>>>>>> From: Martin Basti >>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>> objectclasses >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>> --- >>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>>> index >>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 100644 >>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>> booleanMatch >>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN >>>>>>>>>> 'IPA v4.1' ) >>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE >>>>>>>>>> SYNTAX >>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>>> 'ipaLocation' DESC >>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>>> SYNTAX >>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch >>>>>>>>>> SYNTAX >>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>>> 'idnsRecord' DESC 'dns >>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY >>>>>>>>>> ( cn $ >>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord >>>>>>>>>> $ a6Record $ >>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>>> mXRecord $ >>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ >>>>>>>>>> SigRecord $ KeyRecord >>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord >>>>>>>>>> $ dNameRecord >>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ >>>>>>>>>> DLVRecord $ >>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>>> IPSECKEYRecord $ >>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME >>>>>>>>>> 'idnsZone' DESC 'Zone >>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>> idnsSOAmName $ >>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>> idnsAllowQuery $ >>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>> idnsForwarders $ >>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>>> 'ipaDNSZone' SUP top >>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>> idnsZoneActive ) >>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>>> 'idnsSecKey' DESC 'DNSSEC >>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>>> idnsSecKeyCreated $ >>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ >>>>>>>>>> idnsSecKeyActivate $ >>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>>> idnsName ) MAY ( >>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>>> there will not be >>>>>>>>> any other object class on the location object (at least not in >>>>>>>>> the >>>>>>>>> beginning). >>>>>>>>> >>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>> >>>>>>>>> >>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>>> 00:00:00 2001 >>>>>>>>>> From: Martin Basti >>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>> >>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command are >>>>>>>>>> just >>>>>>>>>> prototypes and does not provide any information about server >>>>>>>>>> (will be >>>>>>>>>> done later) >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>> --- >>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>> API.txt | 59 ++++++++++++++ >>>>>>>>>> VERSION | 4 +- >>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>> index >>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 100644 >>>>>>>>>> --- a/VERSION >>>>>>>>>> +++ b/VERSION >>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>> # # >>>>>>>>>> ######################################################## >>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>> Needs rebase. >>>>>>>>> >>>>>>>>> >>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>> index >>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 100644 >>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>> objectClass: top >>>>>>>>>> cn: etc >>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>> +changetype: add >>>>>>>>>> +objectClass: nsContainer >>>>>>>>>> +objectClass: top >>>>>>>>>> +cn: locations >>>>>>>>>> + >>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>> changetype: add >>>>>>>>>> objectClass: nsContainer >>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>> index >>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 100644 >>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>> +default: objectClass: top >>>>>>>>>> +default: cn: locations >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>>> index >>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 100644 >>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>> [...] >>>>>>>>>> +__doc__ = _(""" >>>>>>>>>> +IPA locations >>>>>>>>>> +""") + _(""" >>>>>>>>>> +Manipulate with DNS locations >>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>> >>>>>>>>> >>>>>>>>>> + at register() >>>>>>>>>> +class location(LDAPObject): >>>>>>>>>> + """ >>>>>>>>>> + IPA locations >>>>>>>>>> + """ >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>> + managed_permissions = { >>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>> + }, >>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>> + }, >>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>> + }, >>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>> + }, >>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>> + 'description', >>>>>>>>>> + }, >>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>> + }, >>>>>>>>>> + } >>>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>>> IMHO this is >>>>>>>>> okay. >>>>>>>>> Less renames we support the better. >>>>>>>>> >>>>>>>>> >>>>>>>>>> + >>>>>>>>>> + takes_params = ( >>>>>>>>>> + DNSNameParam( >>>>>>>>>> + 'idnsname', >>>>>>>>>> + cli_name='name', >>>>>>>>>> + primary_key=True, >>>>>>>>>> + label=_('Location name'), >>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>> + # dns name must be relative, we will put it into >>>>>>>>>> middle of >>>>>>>>>> + # location domain name for location records >>>>>>>>>> + only_relative=True, >>>>>>>>>> + ), >>>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>>> labels work - >>>>>>>>> but >>>>>>>>> this should automagically work as long as we are handling DNS >>>>>>>>> names using >>>>>>>>> proper data types (not as strings). >>>>>>>>> >>>>>>>>> >>>>>>>>>> + Str( >>>>>>>>>> + 'description?', >>>>>>>>>> + label=_('Description'), >>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>> + ), >>>>>>>>> After discussion with Honza we will keep description as >>>>>>>>> single-value in the >>>>>>>>> IPA framework and ignore that description attribute is >>>>>>>>> multi-value in LDAP. >>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> + at register() >>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>>>> This should say 'Modify description' because nothing else can >>>>>>>>> be modified. >>>>>>>>> More specific text would hopefully stop some people from >>>>>>>>> looking for rename >>>>>>>>> options. >>>>>>>> I disagree, this is general description about the modify >>>>>>>> command, see >>>>>>>> privilege-add it is the same as I made. I can see in future >>>>>>>> that we will >>>>>>>> forgot to update description of command if we add something new >>>>>>>> there. >>>>>>> This is really an invalid argument. >>>>>>> >>>>>>> "We must not touch XYZ because its documentation might become >>>>>>> obsolete in >>>>>>> future if we forget to update it!" :-) >>>>>>> >>>>>> How about inconsistency with description of older commands? I >>>>>> don't think that >>>>>> command description should describe attributes that are allowed >>>>>> to change. >>>>>> Allowed attributes are shown in --help output >>>>> I do not agree but push whatever variant you like, it costed too >>>>> much already. >>>> NACK anyway. ipa-dns-install screams if you install a server >>>> without DNS and >>>> run ipa-dns-install later on: >>>> >>>> The log contains this: >>>> >>>> add objectClass: >>>> top >>>> groupofnames >>>> nestedgroup >>>> add cn: >>>> DNS Administrators >>>> add description: >>>> DNS Administrators >>>> adding new entry "cn=DNS >>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>> >>>> >>>> >>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>> >>>> ) >>>> SASL/EXTERNAL authentication started >>>> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>> SASL SSF: 0 >>>> ldap_add: Already exists (68) >>>> >>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>>> -Y >>>> EXTERNAL' returned non-zero exit status 68 >>>> >>> Well I cannot reproduce it, this should be resolved by patch 473 >>> >> >> Updated patches attached >> >> I found that IDNA did not work with previous version, fixed + IDNA >> tests added >> >> > Fixed here, I sent wrong patches before > > > > More patches added, all patches are available here: https://github.com/bastiak/freeipa/tree/DNS-locations Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed May 18 10:52:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 May 2016 12:52:57 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> Message-ID: On 18.5.2016 12:43, Stanislav Laznicka wrote: > On 05/18/2016 12:38 PM, Jan Cholasta wrote: >> On 18.5.2016 12:23, Petr Spacek wrote: >>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>> Hello list, >>>>>> >>>>>> We had a discussion today over integrating the Time Rules into the >>>>>> CLI and >>>>>> WebUI and a problem came up with with the current solution. It >>>>>> seems that >>>>>> while having templating handled by CoSTemplates might be nice in >>>>>> terms of easy >>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>> not really >>>>>> much possible to pick one string from the multi-valued accesstime >>>>>> attribute of >>>>>> HBAC Rule object and modify it. >>>>> Could you be more specific? >>>>> >>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>> >>>>> Petr^2 Spacek >>>> I should have added we're talking CLI and WebUI here. >>>> >>>> Imagine you have 5 values of the accesstime attribute, each one is >>>> about 10 >>>> lines of iCal string, and want to change one: >>>> >>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>> >>> I see. In DNS plugin we do it this way: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>> >>> >>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>> --a-ip-address 192.0.2.1 >>> >>> I would argue that naming of the options is weird so something easier to >>> understand could be made. E.g. >>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >> >> NACK, the dns plugin should not be used as an example for anything, as >> it breaks almost every convention in the framework. > Also, typical iCalendar string is not much suitable for this approach > (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your > proposal is a way, of course, but not much user-friendly here. >> >> Removing and adding of particular accesstime values should be done by >> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and >> "hbacrule-remove-accesstime rule_name accesstime". >> > What about modifications, thought? If not for CLI, you will still need a > way to modify a more complex time rule in the WebUI (you do not want to > remove a complex rule just to click through its creation all again for a > minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. >>> >>>>>> We were thinking of a solution discussed way earlier - having our >>>>>> own time >>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>> way, any time >>>>>> rule could be modified easily. As the HBAC rules are cached on the >>>>>> SSSD side >>>>>> periodically using the deref plugin, there should be no problem of >>>>>> inconsistency with the server database. >>>>>> >>>>>> The original reasoning pro and against the proposed solution could >>>>>> be found on >>>>>> the pad >>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>> would >>>>>> be really nice to hear your opinions and ideas that could help us >>>>>> overcome >>>>>> this problem. >>>>>> >>>>>> Thank you, >>>>>> Standa >>> >> >> > -- Jan Cholasta From pspacek at redhat.com Wed May 18 11:00:18 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 May 2016 13:00:18 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> Message-ID: <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> On 18.5.2016 12:52, Jan Cholasta wrote: > On 18.5.2016 12:43, Stanislav Laznicka wrote: >> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>> On 18.5.2016 12:23, Petr Spacek wrote: >>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>> Hello list, >>>>>>> >>>>>>> We had a discussion today over integrating the Time Rules into the >>>>>>> CLI and >>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>> seems that >>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>> terms of easy >>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>> not really >>>>>>> much possible to pick one string from the multi-valued accesstime >>>>>>> attribute of >>>>>>> HBAC Rule object and modify it. >>>>>> Could you be more specific? >>>>>> >>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>> >>>>>> Petr^2 Spacek >>>>> I should have added we're talking CLI and WebUI here. >>>>> >>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>> about 10 >>>>> lines of iCal string, and want to change one: >>>>> >>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>> >>>> I see. In DNS plugin we do it this way: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>> >>>> >>>> >>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>> --a-ip-address 192.0.2.1 >>>> >>>> I would argue that naming of the options is weird so something easier to >>>> understand could be made. E.g. >>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>> >>> NACK, the dns plugin should not be used as an example for anything, as >>> it breaks almost every convention in the framework. Good point :-) >> Also, typical iCalendar string is not much suitable for this approach >> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >> proposal is a way, of course, but not much user-friendly here. >>> >>> Removing and adding of particular accesstime values should be done by >>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and >>> "hbacrule-remove-accesstime rule_name accesstime". >>> >> What about modifications, thought? If not for CLI, you will still need a >> way to modify a more complex time rule in the WebUI (you do not want to >> remove a complex rule just to click through its creation all again for a >> minor change). > > Modification of an attribute value is exactly that - the old value gets > removed and the new value gets added. How it will look like in the web UI is a > completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Petr^2 Spacek > >>>> >>>>>>> We were thinking of a solution discussed way earlier - having our >>>>>>> own time >>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>> way, any time >>>>>>> rule could be modified easily. As the HBAC rules are cached on the >>>>>>> SSSD side >>>>>>> periodically using the deref plugin, there should be no problem of >>>>>>> inconsistency with the server database. >>>>>>> >>>>>>> The original reasoning pro and against the proposed solution could >>>>>>> be found on >>>>>>> the pad >>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>> would >>>>>>> be really nice to hear your opinions and ideas that could help us >>>>>>> overcome >>>>>>> this problem. >>>>>>> >>>>>>> Thank you, >>>>>>> Standa From jcholast at redhat.com Wed May 18 11:18:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 May 2016 13:18:16 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> Message-ID: <2cbb7582-0278-849c-c705-f60394e18144@redhat.com> On 18.5.2016 13:00, Petr Spacek wrote: > On 18.5.2016 12:52, Jan Cholasta wrote: >> On 18.5.2016 12:43, Stanislav Laznicka wrote: >>> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>>> On 18.5.2016 12:23, Petr Spacek wrote: >>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>>> Hello list, >>>>>>>> >>>>>>>> We had a discussion today over integrating the Time Rules into the >>>>>>>> CLI and >>>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>>> seems that >>>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>>> terms of easy >>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>>> not really >>>>>>>> much possible to pick one string from the multi-valued accesstime >>>>>>>> attribute of >>>>>>>> HBAC Rule object and modify it. >>>>>>> Could you be more specific? >>>>>>> >>>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>>> >>>>>>> Petr^2 Spacek >>>>>> I should have added we're talking CLI and WebUI here. >>>>>> >>>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>>> about 10 >>>>>> lines of iCal string, and want to change one: >>>>>> >>>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>>> >>>>> I see. In DNS plugin we do it this way: >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>>> >>>>> >>>>> >>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>>> --a-ip-address 192.0.2.1 >>>>> >>>>> I would argue that naming of the options is weird so something easier to >>>>> understand could be made. E.g. >>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>>> >>>> NACK, the dns plugin should not be used as an example for anything, as >>>> it breaks almost every convention in the framework. > > Good point :-) > >>> Also, typical iCalendar string is not much suitable for this approach >>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >>> proposal is a way, of course, but not much user-friendly here. >>>> >>>> Removing and adding of particular accesstime values should be done by >>>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and >>>> "hbacrule-remove-accesstime rule_name accesstime". >>>> >>> What about modifications, thought? If not for CLI, you will still need a >>> way to modify a more complex time rule in the WebUI (you do not want to >>> remove a complex rule just to click through its creation all again for a >>> minor change). >> >> Modification of an attribute value is exactly that - the old value gets >> removed and the new value gets added. How it will look like in the web UI is a >> completely different thing. > > The question here is if the intermediate state without defined time (remember, > no transactions!) is acceptable or not. > > Does it mean that the time restriction will removed OR that access will be > always denied because the rule is incomplete? I certainly hope that this will be implemented in such a way that it's the latter :-) > > Petr^2 Spacek > >> >>>>> >>>>>>>> We were thinking of a solution discussed way earlier - having our >>>>>>>> own time >>>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>>> way, any time >>>>>>>> rule could be modified easily. As the HBAC rules are cached on the >>>>>>>> SSSD side >>>>>>>> periodically using the deref plugin, there should be no problem of >>>>>>>> inconsistency with the server database. >>>>>>>> >>>>>>>> The original reasoning pro and against the proposed solution could >>>>>>>> be found on >>>>>>>> the pad >>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>>> would >>>>>>>> be really nice to hear your opinions and ideas that could help us >>>>>>>> overcome >>>>>>>> this problem. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Standa -- Jan Cholasta From slaznick at redhat.com Wed May 18 11:15:26 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 13:15:26 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> Message-ID: <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> On 05/18/2016 01:00 PM, Petr Spacek wrote: > On 18.5.2016 12:52, Jan Cholasta wrote: >> On 18.5.2016 12:43, Stanislav Laznicka wrote: >>> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>>> On 18.5.2016 12:23, Petr Spacek wrote: >>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>>> Hello list, >>>>>>>> >>>>>>>> We had a discussion today over integrating the Time Rules into the >>>>>>>> CLI and >>>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>>> seems that >>>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>>> terms of easy >>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>>> not really >>>>>>>> much possible to pick one string from the multi-valued accesstime >>>>>>>> attribute of >>>>>>>> HBAC Rule object and modify it. >>>>>>> Could you be more specific? >>>>>>> >>>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>>> >>>>>>> Petr^2 Spacek >>>>>> I should have added we're talking CLI and WebUI here. >>>>>> >>>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>>> about 10 >>>>>> lines of iCal string, and want to change one: >>>>>> >>>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>>> I see. In DNS plugin we do it this way: >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>>> >>>>> >>>>> >>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>>> --a-ip-address 192.0.2.1 >>>>> >>>>> I would argue that naming of the options is weird so something easier to >>>>> understand could be made. E.g. >>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>>> NACK, the dns plugin should not be used as an example for anything, as >>>> it breaks almost every convention in the framework. > Good point :-) > >>> Also, typical iCalendar string is not much suitable for this approach >>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >>> proposal is a way, of course, but not much user-friendly here. >>>> Removing and adding of particular accesstime values should be done by >>>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and >>>> "hbacrule-remove-accesstime rule_name accesstime". >>>> >>> What about modifications, thought? If not for CLI, you will still need a >>> way to modify a more complex time rule in the WebUI (you do not want to >>> remove a complex rule just to click through its creation all again for a >>> minor change). >> Modification of an attribute value is exactly that - the old value gets >> removed and the new value gets added. How it will look like in the web UI is a >> completely different thing. > The question here is if the intermediate state without defined time (remember, > no transactions!) is acceptable or not. > > Does it mean that the time restriction will removed OR that access will be > always denied because the rule is incomplete? Pretty good point I was about to raise myself. Also, what happens when removal succeeds but addition fails for some reason? The operation is not atomic anymore. Currently, if the time is not set it means users are allowed in. That was there because of the backward compatibility although that could now be bent to our wills as it should be solved differently (see latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). >>>>>>>> We were thinking of a solution discussed way earlier - having our >>>>>>>> own time >>>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>>> way, any time >>>>>>>> rule could be modified easily. As the HBAC rules are cached on the >>>>>>>> SSSD side >>>>>>>> periodically using the deref plugin, there should be no problem of >>>>>>>> inconsistency with the server database. >>>>>>>> >>>>>>>> The original reasoning pro and against the proposed solution could >>>>>>>> be found on >>>>>>>> the pad >>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>>> would >>>>>>>> be really nice to hear your opinions and ideas that could help us >>>>>>>> overcome >>>>>>>> this problem. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Standa From slaznick at redhat.com Wed May 18 11:47:19 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 13:47:19 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> Message-ID: <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: > On 05/18/2016 01:00 PM, Petr Spacek wrote: >> On 18.5.2016 12:52, Jan Cholasta wrote: >>> On 18.5.2016 12:43, Stanislav Laznicka wrote: >>>> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>>>> On 18.5.2016 12:23, Petr Spacek wrote: >>>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>>>> Hello list, >>>>>>>>> >>>>>>>>> We had a discussion today over integrating the Time Rules into >>>>>>>>> the >>>>>>>>> CLI and >>>>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>>>> seems that >>>>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>>>> terms of easy >>>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>>>> not really >>>>>>>>> much possible to pick one string from the multi-valued accesstime >>>>>>>>> attribute of >>>>>>>>> HBAC Rule object and modify it. >>>>>>>> Could you be more specific? >>>>>>>> >>>>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>> I should have added we're talking CLI and WebUI here. >>>>>>> >>>>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>>>> about 10 >>>>>>> lines of iCal string, and want to change one: >>>>>>> >>>>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>>>> I see. In DNS plugin we do it this way: >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>>>> --a-ip-address 192.0.2.1 >>>>>> >>>>>> I would argue that naming of the options is weird so something >>>>>> easier to >>>>>> understand could be made. E.g. >>>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>>>> NACK, the dns plugin should not be used as an example for >>>>> anything, as >>>>> it breaks almost every convention in the framework. >> Good point :-) >> >>>> Also, typical iCalendar string is not much suitable for this approach >>>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >>>> proposal is a way, of course, but not much user-friendly here. >>>>> Removing and adding of particular accesstime values should be done by >>>>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" >>>>> and >>>>> "hbacrule-remove-accesstime rule_name accesstime". >>>>> >>>> What about modifications, thought? If not for CLI, you will still >>>> need a >>>> way to modify a more complex time rule in the WebUI (you do not >>>> want to >>>> remove a complex rule just to click through its creation all again >>>> for a >>>> minor change). >>> Modification of an attribute value is exactly that - the old value gets >>> removed and the new value gets added. How it will look like in the >>> web UI is a >>> completely different thing. >> The question here is if the intermediate state without defined time >> (remember, >> no transactions!) is acceptable or not. >> >> Does it mean that the time restriction will removed OR that access >> will be >> always denied because the rule is incomplete? > Pretty good point I was about to raise myself. Also, what happens when > removal succeeds but addition fails for some reason? The operation is > not atomic anymore. > We offline-discussed this with Honza. There should be a new command `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 --new-time=icalstr2`. As it would be derived from LDAPQuery, the atomicity is kept. This may not be very nice for CLI but should work well for WebUI. Both icalstr1 and icalstr2 need to be encoded as newlines that appear so often in iCalendar strings would only make a mess here. > Currently, if the time is not set it means users are allowed in. That > was there because of the backward compatibility although that could > now be bent to our wills as it should be solved differently (see > latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). Allow on empty accesstime behaviour should be kept. >>>>>>>>> We were thinking of a solution discussed way earlier - having our >>>>>>>>> own time >>>>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>>>> way, any time >>>>>>>>> rule could be modified easily. As the HBAC rules are cached on >>>>>>>>> the >>>>>>>>> SSSD side >>>>>>>>> periodically using the deref plugin, there should be no >>>>>>>>> problem of >>>>>>>>> inconsistency with the server database. >>>>>>>>> >>>>>>>>> The original reasoning pro and against the proposed solution >>>>>>>>> could >>>>>>>>> be found on >>>>>>>>> the pad >>>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>>>> would >>>>>>>>> be really nice to hear your opinions and ideas that could help us >>>>>>>>> overcome >>>>>>>>> this problem. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Standa > From gkaihoro at redhat.com Wed May 18 11:51:20 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Wed, 18 May 2016 07:51:20 -0400 (EDT) Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set In-Reply-To: <573C29DD.6070103@redhat.com> References: <5735B5AD.9050803@redhat.com> <573C29DD.6070103@redhat.com> Message-ID: <394813195.35159567.1463572280337.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "Lenka Doudova" To: "Ganna Kaihorodova" Sent: Wednesday, May 18, 2016 10:37:49 AM Subject: Fwd: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set -------- Forwarded Message -------- Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set Date: Fri, 13 May 2016 13:08:29 +0200 From: Lenka Doudova To: freeipa-devel Patch attached. Lenka Hello, sorry, nack, because: 1. Tests doesn't clean up after performing. Max user name isn't returned original value. 2. pep8 errors: ./ipatests/test_xmlrpc/test_config_plugin.py:167:21: E126 continuation line over-indented for hanging indent ./ipatests/test_xmlrpc/test_config_plugin.py:170:17: E121 continuation line under-indented for hanging indent Best regards, Ganna Kaihorodova Associate Software Quality Engineer From mbasti at redhat.com Wed May 18 11:58:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 May 2016 13:58:56 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> Message-ID: <69dcd6f4-78ad-d8cd-6a9c-6cf19fd4d91a@redhat.com> On 18.05.2016 13:47, Stanislav Laznicka wrote: > On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: >> On 05/18/2016 01:00 PM, Petr Spacek wrote: >>> On 18.5.2016 12:52, Jan Cholasta wrote: >>>> On 18.5.2016 12:43, Stanislav Laznicka wrote: >>>>> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>>>>> On 18.5.2016 12:23, Petr Spacek wrote: >>>>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>>>>> Hello list, >>>>>>>>>> >>>>>>>>>> We had a discussion today over integrating the Time Rules >>>>>>>>>> into the >>>>>>>>>> CLI and >>>>>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>>>>> seems that >>>>>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>>>>> terms of easy >>>>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>>>>> not really >>>>>>>>>> much possible to pick one string from the multi-valued >>>>>>>>>> accesstime >>>>>>>>>> attribute of >>>>>>>>>> HBAC Rule object and modify it. >>>>>>>>> Could you be more specific? >>>>>>>>> >>>>>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>> I should have added we're talking CLI and WebUI here. >>>>>>>> >>>>>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>>>>> about 10 >>>>>>>> lines of iCal string, and want to change one: >>>>>>>> >>>>>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>>>>> I see. In DNS plugin we do it this way: >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>>>>> --a-ip-address 192.0.2.1 >>>>>>> >>>>>>> I would argue that naming of the options is weird so something >>>>>>> easier to >>>>>>> understand could be made. E.g. >>>>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>>>>> NACK, the dns plugin should not be used as an example for >>>>>> anything, as >>>>>> it breaks almost every convention in the framework. >>> Good point :-) >>> >>>>> Also, typical iCalendar string is not much suitable for this approach >>>>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >>>>> proposal is a way, of course, but not much user-friendly here. >>>>>> Removing and adding of particular accesstime values should be >>>>>> done by >>>>>> a pair of commands, "hbacrule-add-accesstime rule_name >>>>>> accesstime" and >>>>>> "hbacrule-remove-accesstime rule_name accesstime". >>>>>> >>>>> What about modifications, thought? If not for CLI, you will still >>>>> need a >>>>> way to modify a more complex time rule in the WebUI (you do not >>>>> want to >>>>> remove a complex rule just to click through its creation all again >>>>> for a >>>>> minor change). >>>> Modification of an attribute value is exactly that - the old value >>>> gets >>>> removed and the new value gets added. How it will look like in the >>>> web UI is a >>>> completely different thing. >>> The question here is if the intermediate state without defined time >>> (remember, >>> no transactions!) is acceptable or not. >>> >>> Does it mean that the time restriction will removed OR that access >>> will be >>> always denied because the rule is incomplete? >> Pretty good point I was about to raise myself. Also, what happens >> when removal succeeds but addition fails for some reason? The >> operation is not atomic anymore. >> > > We offline-discussed this with Honza. There should be a new command > `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 > --new-time=icalstr2`. As it would be derived from LDAPQuery, the > atomicity is kept. This may not be very nice for CLI but should work > well for WebUI. Both icalstr1 and icalstr2 need to be encoded as > newlines that appear so often in iCalendar strings would only make a > mess here. > But in this case, what is the benefit for user? putting ical there that looks like magic runes of mighty spell is not the best UX for me, in this case you will limit the usage of this feature only for webUI, nobody from mortals will be able to set time rule in nice way. In case you have just one time event in one timerule, you can use options like --start, --end, --in-days, etc for the particular time-rule name and you don't need to specify which part of ICAL string you are modifying because there is only one, and this one rule will be updated. Martin^2 >> Currently, if the time is not set it means users are allowed in. That >> was there because of the backward compatibility although that could >> now be bent to our wills as it should be solved differently (see >> latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). > Allow on empty accesstime behaviour should be kept. >>>>>>>>>> We were thinking of a solution discussed way earlier - having >>>>>>>>>> our >>>>>>>>>> own time >>>>>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>>>>> way, any time >>>>>>>>>> rule could be modified easily. As the HBAC rules are cached >>>>>>>>>> on the >>>>>>>>>> SSSD side >>>>>>>>>> periodically using the deref plugin, there should be no >>>>>>>>>> problem of >>>>>>>>>> inconsistency with the server database. >>>>>>>>>> >>>>>>>>>> The original reasoning pro and against the proposed solution >>>>>>>>>> could >>>>>>>>>> be found on >>>>>>>>>> the pad >>>>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>>>>> would >>>>>>>>>> be really nice to hear your opinions and ideas that could >>>>>>>>>> help us >>>>>>>>>> overcome >>>>>>>>>> this problem. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Standa >> > From slaznick at redhat.com Wed May 18 12:02:41 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 14:02:41 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> References: <3b94bab9-53a8-0be8-80b5-5d47ff937e77@redhat.com> <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> Message-ID: On 05/18/2016 01:47 PM, Stanislav Laznicka wrote: > On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: >> On 05/18/2016 01:00 PM, Petr Spacek wrote: >>> On 18.5.2016 12:52, Jan Cholasta wrote: >>>> On 18.5.2016 12:43, Stanislav Laznicka wrote: >>>>> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>>>>> On 18.5.2016 12:23, Petr Spacek wrote: >>>>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote: >>>>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote: >>>>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>>>>>>>>> Hello list, >>>>>>>>>> >>>>>>>>>> We had a discussion today over integrating the Time Rules >>>>>>>>>> into the >>>>>>>>>> CLI and >>>>>>>>>> WebUI and a problem came up with with the current solution. It >>>>>>>>>> seems that >>>>>>>>>> while having templating handled by CoSTemplates might be nice in >>>>>>>>>> terms of easy >>>>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's >>>>>>>>>> not really >>>>>>>>>> much possible to pick one string from the multi-valued >>>>>>>>>> accesstime >>>>>>>>>> attribute of >>>>>>>>>> HBAC Rule object and modify it. >>>>>>>>> Could you be more specific? >>>>>>>>> >>>>>>>>> AFAIK LDAP protocol allows this. Where is the problem? >>>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>> I should have added we're talking CLI and WebUI here. >>>>>>>> >>>>>>>> Imagine you have 5 values of the accesstime attribute, each one is >>>>>>>> about 10 >>>>>>>> lines of iCal string, and want to change one: >>>>>>>> >>>>>>>> ipa hbacrule-mod-accesstime rule_name --time=??? >>>>>>> I see. In DNS plugin we do it this way: >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 >>>>>>> --a-ip-address 192.0.2.1 >>>>>>> >>>>>>> I would argue that naming of the options is weird so something >>>>>>> easier to >>>>>>> understand could be made. E.g. >>>>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>>>>> NACK, the dns plugin should not be used as an example for >>>>>> anything, as >>>>>> it breaks almost every convention in the framework. >>> Good point :-) >>> >>>>> Also, typical iCalendar string is not much suitable for this approach >>>>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >>>>> proposal is a way, of course, but not much user-friendly here. >>>>>> Removing and adding of particular accesstime values should be >>>>>> done by >>>>>> a pair of commands, "hbacrule-add-accesstime rule_name >>>>>> accesstime" and >>>>>> "hbacrule-remove-accesstime rule_name accesstime". >>>>>> >>>>> What about modifications, thought? If not for CLI, you will still >>>>> need a >>>>> way to modify a more complex time rule in the WebUI (you do not >>>>> want to >>>>> remove a complex rule just to click through its creation all again >>>>> for a >>>>> minor change). >>>> Modification of an attribute value is exactly that - the old value >>>> gets >>>> removed and the new value gets added. How it will look like in the >>>> web UI is a >>>> completely different thing. >>> The question here is if the intermediate state without defined time >>> (remember, >>> no transactions!) is acceptable or not. >>> >>> Does it mean that the time restriction will removed OR that access >>> will be >>> always denied because the rule is incomplete? >> Pretty good point I was about to raise myself. Also, what happens >> when removal succeeds but addition fails for some reason? The >> operation is not atomic anymore. >> > We offline-discussed this with Honza. There should be a new command `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 --new-time=icalstr2`. As it would be derived from LDAPQuery, the atomicity is kept. This may not be very nice for CLI but should work well for WebUI. Both icalstr1 and icalstr2 need to be encoded as newlines that appear so often in iCalendar strings would only make a mess here. Example of use: ipa hbacrule-replace-accesstime rule_name --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" to add Tuesdays to the timespan defined by the rule. >> Currently, if the time is not set it means users are allowed in. That >> was there because of the backward compatibility although that could >> now be bent to our wills as it should be solved differently (see >> latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). Allow on empty accesstime behaviour should be kept. >>>>>>>>>> We were thinking of a solution discussed way earlier - having >>>>>>>>>> our >>>>>>>>>> own time >>>>>>>>>> rule objects that could be referenced from each HBAC rule. That >>>>>>>>>> way, any time >>>>>>>>>> rule could be modified easily. As the HBAC rules are cached >>>>>>>>>> on the >>>>>>>>>> SSSD side >>>>>>>>>> periodically using the deref plugin, there should be no >>>>>>>>>> problem of >>>>>>>>>> inconsistency with the server database. >>>>>>>>>> >>>>>>>>>> The original reasoning pro and against the proposed solution >>>>>>>>>> could >>>>>>>>>> be found on >>>>>>>>>> the pad >>>>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>>>>>>>>> would >>>>>>>>>> be really nice to hear your opinions and ideas that could >>>>>>>>>> help us >>>>>>>>>> overcome >>>>>>>>>> this problem. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Standa >> > From abokovoy at redhat.com Wed May 18 12:19:03 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 May 2016 15:19:03 +0300 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> Message-ID: <20160518121903.l7d5jl425tvin7sv@redhat.com> On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>when removal succeeds but addition fails for some reason? The >>>operation is not atomic anymore. >>> >> >We offline-discussed this with Honza. There should be a new command >`ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 >--new-time=icalstr2`. As it would be derived from LDAPQuery, the >atomicity is kept. This may not be very nice for CLI but should work >well for WebUI. Both icalstr1 and icalstr2 need to be encoded as >newlines that appear so often in iCalendar strings would only make a >mess here. > >Example of use: > >ipa hbacrule-replace-accesstime rule_name >--orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >--new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" > >to add Tuesdays to the timespan defined by the rule. I would really like to see a file input support here. It would be simpler to operate in CLI as you would anyway create vCal files -- no sane person is going to deal with these strings directly on the command line. -- / Alexander Bokovoy From jcholast at redhat.com Wed May 18 13:17:37 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 May 2016 15:17:37 +0200 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> Message-ID: <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> Hi, On 18.5.2016 08:09, Fraser Tweedale wrote: > Rebased version of 0057 attached, along with new patch 0058 that > detects when the Dogtag version of caIPAserviceCert has been > erroneously imported and repairs the profile. How to reproduce the issue? So far I had no luck with freeipa-server-4.2.4-1.fc23.x86_64. Honza -- Jan Cholasta From slaznick at redhat.com Wed May 18 13:28:40 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 15:28:40 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <20160518121903.l7d5jl425tvin7sv@redhat.com> References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> Message-ID: <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: > On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>> when removal succeeds but addition fails for some reason? The >>>> operation is not atomic anymore. >>>> >>> >> We offline-discussed this with Honza. There should be a new command >> `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 >> --new-time=icalstr2`. As it would be derived from LDAPQuery, the >> atomicity is kept. This may not be very nice for CLI but should work >> well for WebUI. Both icalstr1 and icalstr2 need to be encoded as >> newlines that appear so often in iCalendar strings would only make a >> mess here. >> >> Example of use: >> >> ipa hbacrule-replace-accesstime rule_name >> --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >> --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >> >> >> to add Tuesdays to the timespan defined by the rule. > I would really like to see a file input support here. It would be > simpler to operate in CLI as you would anyway create vCal files -- no > sane person is going to deal with these strings directly on the command > line. > That is correct and some basic file support is already in the patches I sent earlier, though replacing rules is not a part of it. However, it does not solve the problem as you would still need access to the files to work with the attributes and then change the files accordingly. However, we've had yet another brainstorm with Petr^2, Martin^2 and Honza. We really don't want the above so we came up with some ideas that I'm listing below. Note that we also do not want more than one VEVENT component in any of the time rules. So, the ideas: 1) Have the time rules as separate objects. This approach got most support here. Adding Simo and Jakub to CC should they have any input against this. 2) Have the time rules stored as strings in the multi-valued accesstime attribute at each rule. These would be referenced by their UID property of the VEVENT component of the iCalendar string (instead of that pure hell above). As each of the strings can only contain one VEVENT which has to define a UID, the only problem would be to keep the uniqueness of UIDs consistent. From my point of view, 1) seems rather better but your experience might be different. Don't hesitate to share your opinions, please. Standa From abokovoy at redhat.com Wed May 18 14:13:11 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 May 2016 17:13:11 +0300 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> References: <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> Message-ID: <20160518141311.vmolfg2gtgljmf3u@redhat.com> On Wed, 18 May 2016, Stanislav Laznicka wrote: >On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: >>On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>>>when removal succeeds but addition fails for some reason? The >>>>>operation is not atomic anymore. >>>>> >>>> >>>We offline-discussed this with Honza. There should be a new >>>command `ipa hbacrule-replace-accesstime rule_name >>>--orig-time=icalstr1 --new-time=icalstr2`. As it would be derived >>>from LDAPQuery, the atomicity is kept. This may not be very nice >>>for CLI but should work well for WebUI. Both icalstr1 and icalstr2 >>>need to be encoded as newlines that appear so often in iCalendar >>>strings would only make a mess here. >>> >>>Example of use: >>> >>>ipa hbacrule-replace-accesstime rule_name >>>--orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >>>--new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >>> >>> >>>to add Tuesdays to the timespan defined by the rule. >>I would really like to see a file input support here. It would be >>simpler to operate in CLI as you would anyway create vCal files -- no >>sane person is going to deal with these strings directly on the command >>line. >> >That is correct and some basic file support is already in the patches >I sent earlier, though replacing rules is not a part of it. However, >it does not solve the problem as you would still need access to the >files to work with the attributes and then change the files >accordingly. > >However, we've had yet another brainstorm with Petr^2, Martin^2 and >Honza. We really don't want the above so we came up with some ideas >that I'm listing below. Note that we also do not want more than one >VEVENT component in any of the time rules. So, the ideas: > 1) Have the time rules as separate objects. This approach got most >support here. Adding Simo and Jakub to CC should they have any input >against this. > 2) Have the time rules stored as strings in the multi-valued >accesstime attribute at each rule. These would be referenced by their >UID property of the VEVENT component of the iCalendar string (instead >of that pure hell above). As each of the strings can only contain one >VEVENT which has to define a UID, the only problem would be to keep >the uniqueness of UIDs consistent. > >From my point of view, 1) seems rather better but your experience >might be different. Don't hesitate to share your opinions, please. I'm for time rules as separate objects too. Multi-valued accesstime attributes would not work well because you cannot really address attributes by UID. -- / Alexander Bokovoy From slaznick at redhat.com Wed May 18 14:36:59 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 18 May 2016 16:36:59 +0200 Subject: [Freeipa-devel] [PATCH 0032] Remove dangling RUVs even if replicas are offline Message-ID: There's no ticket for this patch but as there was a fix to 389-ds mentioned in https://fedorahosted.org/freeipa/ticket/5396, the TODO section in clean_dangling_ruvs could be removed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0032-Remove-dangling-RUVs-even-if-replicas-are-offline.patch Type: text/x-patch Size: 3813 bytes Desc: not available URL: From mbasti at redhat.com Wed May 18 14:39:10 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 May 2016 16:39:10 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <20160518141311.vmolfg2gtgljmf3u@redhat.com> References: <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> <20160518141311.vmolfg2gtgljmf3u@redhat.com> Message-ID: <5ec53769-4885-9ffe-6e6a-828e8ae590db@redhat.com> On 18.05.2016 16:13, Alexander Bokovoy wrote: > On Wed, 18 May 2016, Stanislav Laznicka wrote: >> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: >>> On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>>>> when removal succeeds but addition fails for some reason? The >>>>>> operation is not atomic anymore. >>>>>> >>>>> >>>> We offline-discussed this with Honza. There should be a new command >>>> `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 >>>> --new-time=icalstr2`. As it would be derived from LDAPQuery, the >>>> atomicity is kept. This may not be very nice for CLI but should >>>> work well for WebUI. Both icalstr1 and icalstr2 need to be encoded >>>> as newlines that appear so often in iCalendar strings would only >>>> make a mess here. >>>> >>>> Example of use: >>>> >>>> ipa hbacrule-replace-accesstime rule_name >>>> --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >>>> --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" >>>> >>>> >>>> to add Tuesdays to the timespan defined by the rule. >>> I would really like to see a file input support here. It would be >>> simpler to operate in CLI as you would anyway create vCal files -- no >>> sane person is going to deal with these strings directly on the command >>> line. >>> For sure we should support import of iCals, but we should have simple interface for creating simple iCal, such as from 13:00, to 15:00, on Mo, Tu and Fri. For extra special rules the one may use iCal generator somewhere. Martin^2 >> That is correct and some basic file support is already in the patches >> I sent earlier, though replacing rules is not a part of it. However, >> it does not solve the problem as you would still need access to the >> files to work with the attributes and then change the files accordingly. >> >> However, we've had yet another brainstorm with Petr^2, Martin^2 and >> Honza. We really don't want the above so we came up with some ideas >> that I'm listing below. Note that we also do not want more than one >> VEVENT component in any of the time rules. So, the ideas: >> 1) Have the time rules as separate objects. This approach got most >> support here. Adding Simo and Jakub to CC should they have any input >> against this. >> 2) Have the time rules stored as strings in the multi-valued >> accesstime attribute at each rule. These would be referenced by their >> UID property of the VEVENT component of the iCalendar string (instead >> of that pure hell above). As each of the strings can only contain one >> VEVENT which has to define a UID, the only problem would be to keep >> the uniqueness of UIDs consistent. >> >> From my point of view, 1) seems rather better but your experience >> might be different. Don't hesitate to share your opinions, please. > I'm for time rules as separate objects too. Multi-valued accesstime > attributes would not work well because you cannot really address > attributes by UID. From pvoborni at redhat.com Wed May 18 14:44:56 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 May 2016 16:44:56 +0200 Subject: [Freeipa-devel] [PATCH 0032] Remove dangling RUVs even if replicas are offline In-Reply-To: References: Message-ID: <63420bab-1cb0-562c-bc93-1bb834210506@redhat.com> On 05/18/2016 04:36 PM, Stanislav Laznicka wrote: > There's no ticket for this patch but as there was a fix to 389-ds > mentioned in https://fedorahosted.org/freeipa/ticket/5396, the TODO > section in clean_dangling_ruvs could be removed. > What about using 'replica-force-cleaning':'yes', every time? Is there a drawback which we would like to avoid? -- Petr Vobornik From jhrozek at redhat.com Wed May 18 14:49:23 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 18 May 2016 16:49:23 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <20160518141311.vmolfg2gtgljmf3u@redhat.com> References: <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> <20160518141311.vmolfg2gtgljmf3u@redhat.com> Message-ID: <20160518144923.GE23970@hendrix> On Wed, May 18, 2016 at 05:13:11PM +0300, Alexander Bokovoy wrote: > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: > > > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > > > > > when removal succeeds but addition fails for some > > > > > > reason? The operation is not atomic anymore. > > > > > > > > > > > > > > > We offline-discussed this with Honza. There should be a new > > > > command `ipa hbacrule-replace-accesstime rule_name > > > > --orig-time=icalstr1 --new-time=icalstr2`. As it would be > > > > derived from LDAPQuery, the atomicity is kept. This may not be > > > > very nice for CLI but should work well for WebUI. Both icalstr1 > > > > and icalstr2 need to be encoded as newlines that appear so often > > > > in iCalendar strings would only make a mess here. > > > > > > > > Example of use: > > > > > > > > ipa hbacrule-replace-accesstime rule_name > > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" > > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" > > > > > > > > > > > > to add Tuesdays to the timespan defined by the rule. > > > I would really like to see a file input support here. It would be > > > simpler to operate in CLI as you would anyway create vCal files -- no > > > sane person is going to deal with these strings directly on the command > > > line. > > > > > That is correct and some basic file support is already in the patches I > > sent earlier, though replacing rules is not a part of it. However, it > > does not solve the problem as you would still need access to the files > > to work with the attributes and then change the files accordingly. > > > > However, we've had yet another brainstorm with Petr^2, Martin^2 and > > Honza. We really don't want the above so we came up with some ideas that > > I'm listing below. Note that we also do not want more than one VEVENT > > component in any of the time rules. So, the ideas: > > 1) Have the time rules as separate objects. This approach got most > > support here. Adding Simo and Jakub to CC should they have any input > > against this. > > 2) Have the time rules stored as strings in the multi-valued > > accesstime attribute at each rule. These would be referenced by their > > UID property of the VEVENT component of the iCalendar string (instead of > > that pure hell above). As each of the strings can only contain one > > VEVENT which has to define a UID, the only problem would be to keep the > > uniqueness of UIDs consistent. > > > > From my point of view, 1) seems rather better but your experience might > > be different. Don't hesitate to share your opinions, please. > I'm for time rules as separate objects too. Multi-valued accesstime > attributes would not work well because you cannot really address > attributes by UID. >From SSSD point of view, I'm fine. We download all the HBAC related objects (all that apply to that host) anyway. Just please plan on abstracting the IPA HBAC object from its representation in libipa_hbac. From ofayans at redhat.com Wed May 18 15:01:03 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 18 May 2016 17:01:03 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: <5739CFB0.6000607@redhat.com> References: <5739CFB0.6000607@redhat.com> Message-ID: <573C83AF.6060309@redhat.com> Hi guys, Did I understand correctly that in 4.4 release the function of both 'ipa-csreplica-manage del' and 'ipa-replica-manage del' will be transfered to the API calls executed during replica uninstallation with 'ipa-server-install --uninstall'? Which means that 'ipa-replica-manage del' will be deprecated? On 05/16/2016 03:48 PM, Oleg Fayans wrote: > Hi, > > The design is OK, the onlz thing that is missing is a HowToTest section > in track tickets [1] and [2] about clean-dangling-ruvs and > abort-clean-ruv respectively. It would really help if these tickets had > detailed steps to test (in case of dangling RUV's - steps to generate them) > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Wed May 18 15:18:51 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 18 May 2016 17:18:51 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: <573C83AF.6060309@redhat.com> References: <5739CFB0.6000607@redhat.com> <573C83AF.6060309@redhat.com> Message-ID: On 05/18/2016 05:01 PM, Oleg Fayans wrote: > Hi guys, > > Did I understand correctly that in 4.4 release the function of both > 'ipa-csreplica-manage del' and 'ipa-replica-manage del' will be > transfered to the API calls executed during replica uninstallation with > 'ipa-server-install --uninstall'? Which means that 'ipa-replica-manage > del' will be deprecated? > > `ipa-csreplica-manage del` is deprecated in domain level 1 topology and will raise an error, we even have a test case for this in replica promotion CI tests ;). So no `server_del` here. `ipa-replica-manage del` will not be explicitly deprecated, but it will call `server_del` behind the scenes. > On 05/16/2016 03:48 PM, Oleg Fayans wrote: >> Hi, >> >> The design is OK, the onlz thing that is missing is a HowToTest section >> in track tickets [1] and [2] about clean-dangling-ruvs and >> abort-clean-ruv respectively. It would really help if these tickets had >> detailed steps to test (in case of dangling RUV's - steps to generate them) >> > -- Martin^3 Babinsky From mbasti at redhat.com Wed May 18 15:19:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 May 2016 17:19:47 +0200 Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <1003473753.53492942.1463562439336.JavaMail.zimbra@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> <5722198D.2040305@redhat.com> <175618514.52234031.1463140785306.JavaMail.zimbra@redhat.com> <526e6505-b093-6eee-4141-dd838ab55817@redhat.com> <1877307538.52247950.1463144714968.JavaMail.zimbra@redhat.com> <43757ad0-fbc6-cbf7-6c00-179d1ba7b3d3@redhat.com> <1003473753.53492942.1463562439336.JavaMail.zimbra@redhat.com> Message-ID: <629bcd4a-ecc2-16fd-c7c2-8a75a8737f1c@redhat.com> On 18.05.2016 11:07, Peter Lacko wrote: > So last one (hopefully). > > Peter > > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" > Cc: freeipa-devel at redhat.com > Sent: Monday, May 16, 2016 6:32:49 PM > Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way > > > > On 13.05.2016 15:05, Peter Lacko wrote: >> Desciption added back, header changed to original. >> >> Peter >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Peter Lacko" >> Cc: freeipa-devel at redhat.com >> Sent: Friday, May 13, 2016 2:02:00 PM >> Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way >> >> >> >> On 13.05.2016 13:59, Peter Lacko wrote: >>> Hi, >>> >>> Thanks again, will remember that. I also changed header to short one. >>> >>> Peter >> Whyyy? >> >> >>> ----- Original Message ----- >>> From: "Martin Basti" >>> To: "Peter Lacko" , freeipa-devel at redhat.com >>> Sent: Tuesday, May 10, 2016 12:23:13 PM >>> Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way >>> >>> >>> >>> On 28.04.2016 16:09, Martin Basti wrote: >>>> On 08.04.2016 10:32, Peter Lacko wrote: >>>> Hello, >>>> >>>> I have a few comments: >>>> >>>> 1) >>>> Please set up your git name and email correctly (consistently for all >>>> patches) >>>> this is not right From: root >>>> >>>> 2) >>>> -# Copyright (C) 2012 Red Hat >>>> +# Copyright (C) 2016 Red Hat >>>> >>>> leave there both years please >>>> +# Copyright (C) 2012, 2016 Red Hat >>>> >>>> 3) >>>> Please put the patch number to the email subject, it is easier to find correct patch for us >>>> >>>> Otherwise LGTM and works for me. >>>> >>>> Martin^2 >>>> >>>> >>> Sorry I didn't noticed earlier, but your patch doesn't work under python3 >>> >>> from xmlrpc_test import XMLRPC_test, raises_exact >>> E ImportError: No module named 'xmlrpc_test' >>> >>> You must use absolute import, not relative in py3 >>> >>> Martin^2 > Sorry, NACK > > ************* Module ipatests.test_xmlrpc.test_ping_plugin > ipatests/test_xmlrpc/test_ping_plugin.py:29: [E0611(no-name-in-module), > ] No name 'test_xmplrpc' in module 'ipatests') > > did you mean 'test_xmlrpc'? > > Martin^2 ACK Pushed to master: 144a367d35d0d15a732e851adffd251d04711af9 From pspacek at redhat.com Wed May 18 15:34:37 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 May 2016 17:34:37 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> Message-ID: <0adc1549-1626-4c2c-f164-e714e9d32e50@redhat.com> On 16.5.2016 13:58, David Kupka wrote: >>> >>> >>> On 14.03.2016 13:46, Martin Babinsky wrote: >>>> On 03/11/2016 09:16 AM, David Kupka wrote: >>>>> Current version (0.5.0) of python-augeas is missing copy() method. Use >>>>> dkupka/python-augeas copr repo before new version it's build and >>>>> available in the official repos. >>>>> >>>>> >>>>> >>>> Hi David, >>>> >>>> TLDR: NACK :D. >>>> >>>> Here are high-level remarks to discuss: >>>> >>>> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >>>> ipaplatform since it is dealing with (sorta) platform specific >>>> behavior (ntp vs. chrony vs. whatever we will have for timesync in the >>>> future). CC'ing Jan for thoughts. >>>> >>>> Also regarding patches 0096-0097, we could have platform specific >>>> TimeDateService object that could wrap NTP/chrony management. for >>>> example, the task namespace functions in Pathc 0096 could be >>>> reimplemented as a methods of the service (RedhatTimeDateService, >>>> FedoraTimeDateService etc.) and then called in a platform-agnostic >>>> manner. >>>> >>>> Here are some comments regarding code: >>>> >>>> Patch 0095: >>>> >>>> 1.) >>>> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >>>> >>>> Do not forget to add this directory to %install and %files spection of >>>> the spec file so that it is correctly added to RPM build. >>>> >>>> 2.) >>>> >>>> please separate import of system-wide and IPA-specific modules by >>>> blank line >>>> >>>> +import collections >>>> +from augeas import Augeas >>>> +from ipaplatform.paths import paths >>>> +from ipapython.ipa_log_manager import root_logger >>>> >>>> 3.) the call to parent's __new__ should have signature 'super(aug_obj, >>>> cls).__new__(*args, **kwargs)' >>>> >>>> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >>>> **kwargs) >>>> >>>> 4.) >>>> >>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>> add more' >>>> + 'lenses.') >>>> >>>> Should be 'Augeas lenses _were_ loaded' >>>> >>>> 5.) >>>> >>>> + if lens in self.lenses: >>>> + raise RuntimeError('Lens %s already added.' % lens) >>>> + self.lenses.append(lens) >>>> + load_path = '/augeas/load/{0}'.format(lens >>>> >>>> >>>> Shouldn't the following code use os.path,join to construct the >>>> load_path? >>>> >>>> 6.) I would prefer the following indentation style in the add_lens() >>>> method >>>> >>>> @@ -65,9 +65,9 @@ class aug_obj(object): >>>> for conf_file in conf_files: >>>> self._aug.set(os.path.join(load_path, 'incl[0]'), >>>> conf_file) >>>> self.tree['old'] = self.tree.get(conf_file, None) >>>> - self.tree[conf_file] = aug_node(self._aug, >>>> - os.path.join('/files', >>>> - conf_file[1:])) >>>> + self.tree[conf_file] = aug_node( >>>> + self._aug, os.path.join('/files', conf_file[1:]) >>>> + ) >>>> >>>> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >>>> 'files', and '//error' would be made into either module variables or >>>> class members. >>>> >>>> 8.) >>>> >>>> + def load(self): >>>> + if self._loaded: >>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>> add more' >>>> + 'lenses.') >>>> >>>> Fix the excpetion text in the same way as in 4.) >>>> >>>> 9.) >>>> >>>> + errors = self._aug.match(os.path.join('//error')) >>>> >>>> is the os.path.join necessary here? >>>> >>>> 10.) I guess you can rewrite the error message in load() method using >>>> list comprehension: >>>> >>>> @@ -76,9 +76,9 @@ class aug_obj(object): >>>> self._aug.load() >>>> errors = self._aug.match(os.path.join('//error')) >>>> if errors: >>>> - err_msg = "" >>>> - for error in errors: >>>> - err_msg += ("{}: {}".format(error, >>>> self._aug.get(error))) >>>> + err_msg = '\n'.join( >>>> + ["{}: {}".format(e, self._aug.get(e)) for e in errors] >>>> + ) >>>> raise RuntimeError(err_msg) >>>> self._loaded = True >>>> >>>> 11.) >>>> >>>> +class aug_node(collections.MutableMapping): >>>> + """ Single augeas node. >>>> + Can be handled as python dict(). >>>> + """ >>>> + def __init__(self, aug, path): >>>> + self._aug = aug >>>> + if path and os.path.isabs(path): >>>> + self._path = path >>>> + else: >>>> + self._tmp = _tmp_path(aug, path) >>>> + self._path = self._tmp.path >>>> >>>> Isn't it better to change signature of __init__ to: >>>> >>>> def __init__(self, aug, path=None): >>>> >>>> and then test whether path is None? >>>> >>>> 12.) >>>> >>>> def __setitem__(self, key, node): >>>> + target = os.path.join(self._path, key) >>>> + end = '{0}[0]'.format(os.path.join(self._path, key)) >>>> + if self._aug.match(target): >>>> + self._aug.remove(target) >>>> + target_list = aug_list(self._aug, target) >>>> + for src_node in aug_list(node._aug, node._path): >>>> + target_list.append(src_node) >>>> >>>> The 'end' variable is declared but not used. >>>> >>>> 13.) >>>> >>>> + >>>> + def __len__(self): >>>> + return len(self._aug.match('{0}/*'.format(self._path))) >>>> + >>>> + def __iter__(self): >>>> + for key in self._aug.match('{0}/*'.format(self._path)): >>>> + yield self._aug.label(key) >>>> + raise StopIteration() >>>> + >>>> >>>> Shouldn't we construct paths using os.path.join for the sake of >>>> consistency? >>>> >>>> 14.) >>>> >>>> + def __bool__(self): >>>> + return (bool(len(self)) or bool(self.value)) >>>> >>>> The parentheses around the boolean expression are not needed >>>> >>>> 15.) >>>> >>>> +class aug_list(collections.MutableSequence): >>>> + """Augeas NODESET. >>>> + Can be handled as a list(). >>>> + """ >>>> + def __init__(self, aug, path): >>>> + self._aug = aug >>>> + if path and os.path.isabs(path): >>>> + self._path = path >>>> + else: >>>> + self._tmp = _tmp_path(aug, path) >>>> + self._path = self._tmp.path >>>> >>>> I would use 'path=None' int he signature and then test whether 'path >>>> is not None'. >>>> >>>> 16.) >>>> >>>> + if not self._aug.match(target): >>>> + raise IndexError() >>>> >>>> It would be nice if you could put some basic error message into the >>>> raised exceptions, like "node index out of range" or something like that >>>> >>>> 17.) >>>> >>>> + elif isinstance(index, slice): >>>> + label = self._path.split('/')[-1] >>>> >>>> you could use os.path.basename() to get the leaf node. >>>> >>>> >>>> 18.) >>>> >>>> + replace = range_target[:len(node)] >>>> + delete = create = [] >>>> >>>> Be careful here as you create two references to the same empty list >>>> object, which is probably not what you wanted. >>>> >>>> 19.) >>>> + try: >>>> + create_start = range_target[-1]+1 >>>> + except IndexError: >>>> + create_start = self._idx_pos(index.start) >>>> + create_stop = create_start+len(node)-len(replace) >>>> + create = list(range(create_start, create_stop)) >>>> >>>> Please respect PEP8 and put spaces around arithmetic operators in >>>> assignments. >>>> >>>> Also it would be nice to have at least a minimal test suite for this >>>> module, but that may be a separate ticket. >>>> >>>> patch 0096: >>>> >>>> 1.) please fix the commit message >>>> 2.) please use new-style license header in ipapython/ntp.py >>>> 3.) >>>> >>>> + return ("Conflicting Time&Date synchroniztion service '%s' is " >>>> + "currently enabled and/or running on the system." >>>> + % self.conflicting_service) >>>> >>>> Please fix the typo in the error message. >>>> >>>> 4.) >>>> + service = services.service(self.service_name) >>>> + if sstore: >>>> + if sstore.get_state('ntp', 'enabled') is None: >>>> + sstore.backup_state('ntp', 'enabled', >>>> service.is_enabled()) >>>> + >>>> + if fstore: >>>> + if not fstore.has_file(self.conf_file): >>>> + fstore.backup_file(self.conf_file) >>>> >>>> the conditions in the 'if' statement can be merged into single AND >>>> expression >>>> >>>> 5.) >>>> + self._store_service_state(sstore, fstore) >>>> + if sstore: >>>> + sstore.backup_state('ntp', "enabled", service.is_enabled()) >>>> + >>>> + if fstore: >>>> + fstore.backup_file(self.conf_file) >>>> >>>> I think these checks are redundant here. >>>> >>>> 6.) >>>> + # In such case it is OK to fail >>>> + try: >>>> + restored = fstore.restore_file(self.conf_file) >>>> + except Exception: >>>> + pass >>>> >>>> Instead of 'pass' it would be better to set restored to False so that >>>> you don't hit NameError later. >>>> >>>> 7.) >>>> + >>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>> fstore=None): >>>> + self.server_options['burst'] = None >>>> + self.server_options['iburst'] = None >>>> >>>> I would rather set these instance variables in __init__() than here. >>>> >>>> 8.) >>>> >>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>> fstore=None): >>>> + self.conf_file = paths.CHRONY_CONF >>>> self.conf_file is already defined in constructor. >>>> >>>> 9.) >>>> >>>> + self.server_options['iburst'] = None >>>> this should be moved to __init__() >>>> >>>> 10.) >>>> + with ipaaugeas.aug_obj() as aug: >>>> + try: >>>> + aug.add_lens(self.lens, [self.conf_file]) >>>> + aug.load() >>>> + except RuntimeError as e: >>>> + raise NTPConfigurationError(e) >>>> >>>> This code is repeated quite a few times, maybe it would be a good idea >>>> to factor it out to a method of NTPService object. >>>> >>>> >>>> Patch 0097: >>>> >>>> 1.) please fix a typo here: >>>> >>>> + description="Disble any other Time synchronization services." >>>> >>>> 2.) >>>> >>>> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >>>> you have 2 spaces before 'ntpinstance' >>>> >>> >>> I'm adding my nitpicks too :) >>> >>> 1) >>> +#!/usr/bin/python >>> >>> This should not be in modules, only in executable files >>> >>> 2) >>> Missing license in ipaaugeas.py >>> >>> Martin^2 >> >> Hello, >> after offline discussion with Honza I've rewritten the augeas wrapper >> and modified ipautil/ntp.py accordingly. The rest should be pretty much >> the same. >> Patches attached. >> > Rebased and added minimal test suite. I'm not able to apply this patch set to current master (89cdf6ee1e796e5ba4c302a19da4862e18b99c4a). Quick scan through comments tells me nothing about usage of the module. You really should write an how-to use the module, preferably in form of doc tests. Right now I have no idea how I'm supposed to use it. -- Petr^2 Spacek From mbasti at redhat.com Wed May 18 17:24:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 May 2016 19:24:30 +0200 Subject: [Freeipa-devel] [PATCH 0483] fix referenced before assignment error in baseldap Message-ID: <3f1231fb-b7f3-b867-c483-d7805b9ad323@redhat.com> Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0483-Fix-referenced-before-assigment-variables-in-except-.patch Type: text/x-patch Size: 1627 bytes Desc: not available URL: From ftweedal at redhat.com Wed May 18 23:31:19 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 19 May 2016 09:31:19 +1000 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> Message-ID: <20160518233119.GI19808@dhcp-40-8.bne.redhat.com> On Wed, May 18, 2016 at 03:17:37PM +0200, Jan Cholasta wrote: > Hi, > > On 18.5.2016 08:09, Fraser Tweedale wrote: > > Rebased version of 0057 attached, along with new patch 0058 that > > detects when the Dogtag version of caIPAserviceCert has been > > erroneously imported and repairs the profile. > > How to reproduce the issue? So far I had no luck with > freeipa-server-4.2.4-1.fc23.x86_64. > > Honza > `ipa-replica-install --setup-ca` with an affected version (including 4.2.4-1) will cause the issue. From slaznick at redhat.com Thu May 19 06:02:26 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 19 May 2016 08:02:26 +0200 Subject: [Freeipa-devel] [PATCH 0032] Remove dangling RUVs even if replicas are offline In-Reply-To: <63420bab-1cb0-562c-bc93-1bb834210506@redhat.com> References: <63420bab-1cb0-562c-bc93-1bb834210506@redhat.com> Message-ID: <2770a518-35f7-144d-bfbe-1baa9dd92f01@redhat.com> On 05/18/2016 04:44 PM, Petr Vobornik wrote: > On 05/18/2016 04:36 PM, Stanislav Laznicka wrote: >> There's no ticket for this patch but as there was a fix to 389-ds >> mentioned in https://fedorahosted.org/freeipa/ticket/5396, the TODO >> section in clean_dangling_ruvs could be removed. >> > What about using > 'replica-force-cleaning':'yes', > > every time? > > Is there a drawback which we would like to avoid? > The DS website mentions two possible risks - possible loss of changes on deleted replica should these have not been reflected to some other replicas - if some offline replica comes back online, it may re-pollute the RUVs back I'm not sure of the probability of the second scenario, in my rather simple environment the re-pollution did not happen. From ofayans at redhat.com Thu May 19 06:45:24 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 19 May 2016 08:45:24 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: References: <5739CFB0.6000607@redhat.com> <573C83AF.6060309@redhat.com> Message-ID: <573D6104.8000305@redhat.com> Hi Martin, I should probably rephrase my question: will the server_del API call be added to 'ipa-server-install --uninstall' within 4.4 or is it a more distant plan? On 05/18/2016 05:18 PM, Martin Babinsky wrote: > On 05/18/2016 05:01 PM, Oleg Fayans wrote: >> Hi guys, >> >> Did I understand correctly that in 4.4 release the function of both >> 'ipa-csreplica-manage del' and 'ipa-replica-manage del' will be >> transfered to the API calls executed during replica uninstallation with >> 'ipa-server-install --uninstall'? Which means that 'ipa-replica-manage >> del' will be deprecated? >> >> > > `ipa-csreplica-manage del` is deprecated in domain level 1 topology and > will raise an error, we even have a test case for this in replica > promotion CI tests ;). So no `server_del` here. > > `ipa-replica-manage del` will not be explicitly deprecated, but it will > call `server_del` behind the scenes. > >> On 05/16/2016 03:48 PM, Oleg Fayans wrote: >>> Hi, >>> >>> The design is OK, the onlz thing that is missing is a HowToTest section >>> in track tickets [1] and [2] about clean-dangling-ruvs and >>> abort-clean-ruv respectively. It would really help if these tickets had >>> detailed steps to test (in case of dangling RUV's - steps to generate >>> them) >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From lkrispen at redhat.com Thu May 19 06:52:11 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 19 May 2016 08:52:11 +0200 Subject: [Freeipa-devel] [PATCH 0032] Remove dangling RUVs even if replicas are offline In-Reply-To: <2770a518-35f7-144d-bfbe-1baa9dd92f01@redhat.com> References: <63420bab-1cb0-562c-bc93-1bb834210506@redhat.com> <2770a518-35f7-144d-bfbe-1baa9dd92f01@redhat.com> Message-ID: <573D629B.4070804@redhat.com> On 05/19/2016 08:02 AM, Stanislav Laznicka wrote: > On 05/18/2016 04:44 PM, Petr Vobornik wrote: >> On 05/18/2016 04:36 PM, Stanislav Laznicka wrote: >>> There's no ticket for this patch but as there was a fix to 389-ds >>> mentioned in https://fedorahosted.org/freeipa/ticket/5396, the TODO >>> section in clean_dangling_ruvs could be removed. >>> >> What about using >> 'replica-force-cleaning':'yes', >> >> every time? >> >> Is there a drawback which we would like to avoid? >> > The DS website mentions two possible risks > - possible loss of changes on deleted replica should these have not > been reflected to some other replicas this is a theoretical concern that there might be changes from the replica to be removed which are not yet on all servers, but to me the problem that cleaning ruvs hangs because replicas cannot be reached is the worse scenario. > - if some offline replica comes back online, it may re-pollute the > RUVs back > > I'm not sure of the probability of the second scenario, in my rather > simple environment the re-pollution did not happen. there have been fixes in 389-ds to prevent the repollution, so it should no longer happen. -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From slaznick at redhat.com Thu May 19 07:30:24 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 19 May 2016 09:30:24 +0200 Subject: [Freeipa-devel] [PATCH 0032] Remove dangling RUVs even if replicas are offline In-Reply-To: <573D629B.4070804@redhat.com> References: <63420bab-1cb0-562c-bc93-1bb834210506@redhat.com> <2770a518-35f7-144d-bfbe-1baa9dd92f01@redhat.com> <573D629B.4070804@redhat.com> Message-ID: On 05/19/2016 08:52 AM, Ludwig Krispenz wrote: > > On 05/19/2016 08:02 AM, Stanislav Laznicka wrote: >> On 05/18/2016 04:44 PM, Petr Vobornik wrote: >>> On 05/18/2016 04:36 PM, Stanislav Laznicka wrote: >>>> There's no ticket for this patch but as there was a fix to 389-ds >>>> mentioned in https://fedorahosted.org/freeipa/ticket/5396, the TODO >>>> section in clean_dangling_ruvs could be removed. >>>> >>> What about using >>> 'replica-force-cleaning':'yes', >>> >>> every time? >>> >>> Is there a drawback which we would like to avoid? >>> >> The DS website mentions two possible risks >> - possible loss of changes on deleted replica should these have not >> been reflected to some other replicas > this is a theoretical concern that there might be changes from the > replica to be removed which are not yet on all servers, but to me the > problem that cleaning ruvs hangs because replicas cannot be reached is > the worse scenario. >> - if some offline replica comes back online, it may re-pollute the >> RUVs back >> >> I'm not sure of the probability of the second scenario, in my rather >> simple environment the re-pollution did not happen. > there have been fixes in 389-ds to prevent the repollution, so it > should no longer happen. > Thank you, Ludwig. It seems reasonable to have the option set to 'yes' all the time, then. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0032-2-Remove-dangling-RUVs-even-if-replicas-are-offline.patch Type: text/x-patch Size: 3083 bytes Desc: not available URL: From jcholast at redhat.com Thu May 19 07:52:08 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 09:52:08 +0200 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <20160518233119.GI19808@dhcp-40-8.bne.redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> <20160518233119.GI19808@dhcp-40-8.bne.redhat.com> Message-ID: <36400a33-5b4f-435b-e2f6-066d3933ea55@redhat.com> On 19.5.2016 01:31, Fraser Tweedale wrote: > On Wed, May 18, 2016 at 03:17:37PM +0200, Jan Cholasta wrote: >> Hi, >> >> On 18.5.2016 08:09, Fraser Tweedale wrote: >>> Rebased version of 0057 attached, along with new patch 0058 that >>> detects when the Dogtag version of caIPAserviceCert has been >>> erroneously imported and repairs the profile. >> >> How to reproduce the issue? So far I had no luck with >> freeipa-server-4.2.4-1.fc23.x86_64. >> >> Honza >> > `ipa-replica-install --setup-ca` with an affected version (including > 4.2.4-1) will cause the issue. Thanks. The fix seems to work, although if you install an unfixed replica against a fixed server, it will still break the profile. I'm not sure how much of a problem this could be in the real world, though. For the record, this is a diff between the relevant parts of a test certificate issued before and after the fix: @@ -1,19 +1,19 @@ Validity Not Before: Not After : - Subject: O=IPA, OU=pki-ipa, CN=vm-244.abc.idm.lab.eng.brq.redhat.com + Subject: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM, CN=vm-244.abc.idm.lab.eng.brq.redhat.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) @@ -36,48 +36,60 @@ keyid:89:8C:12:22:E7:D4:C5:87:06:26:5E:AE:C7:73:B5:4B:82:93:CE:1E Authority Information Access: - OCSP - URI:http://vm-244.abc.idm.lab.eng.brq.redhat.com:80/ca/ocsp + OCSP - URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ca/ocsp X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication + X509v3 CRL Distribution Points: + + Full Name: + URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ipa/crl/MasterCRL.bin + CRL Issuer: + DirName: O = ipaca, CN = Certificate Authority + + X509v3 Subject Key Identifier: + 5E:A4:14:31:8E:71:00:4E:2A:71:D6:49:E4:1D:09:EC:10:DF:5D:B1 Signature Algorithm: sha256WithRSAEncryption The ticket and bugzilla mention only OCSP URI being wrong. It should be stated somewhere visible that the subject name and CRL distribution points are also affected. BTW the CRL issuer field is wrong. In my case, the issuer name of the CRL is "CN=Certificate Authority,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM", not "CN=Certificate Authority,O=ipaca". Also, according to RFC 5280, section 4.2.1.13, the CRL issuer field must be ommited if the CRL issuer is the same as the certificate issuer. -- Jan Cholasta From slaznick at redhat.com Thu May 19 08:09:31 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 19 May 2016 10:09:31 +0200 Subject: [Freeipa-devel] [PATCH 0483] fix referenced before assignment error in baseldap In-Reply-To: <3f1231fb-b7f3-b867-c483-d7805b9ad323@redhat.com> References: <3f1231fb-b7f3-b867-c483-d7805b9ad323@redhat.com> Message-ID: <420297df-5226-5658-b8fd-af6a733c4244@redhat.com> ACK On 05/18/2016 07:24 PM, Martin Basti wrote: > Patch attached > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu May 19 08:20:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 10:20:21 +0200 Subject: [Freeipa-devel] [PATCH 553] spec file: bump minimum required pki-core version Message-ID: <765811b3-605b-49e1-22a2-d4a651ae95ef@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-553-spec-file-bump-minimum-required-pki-core-version.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-553.0.4_2-spec-file-bump-minimum-required-pki-core-version.patch Type: text/x-patch Size: 1127 bytes Desc: not available URL: From jcholast at redhat.com Thu May 19 08:34:03 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 10:34:03 +0200 Subject: [Freeipa-devel] [PATCH 554] build: fix client-only build Message-ID: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-554-build-fix-client-only-build.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL: From mbabinsk at redhat.com Thu May 19 08:35:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 May 2016 10:35:03 +0200 Subject: [Freeipa-devel] [PATCH 553] spec file: bump minimum required pki-core version In-Reply-To: <765811b3-605b-49e1-22a2-d4a651ae95ef@redhat.com> References: <765811b3-605b-49e1-22a2-d4a651ae95ef@redhat.com> Message-ID: On 05/19/2016 10:20 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From mbabinsk at redhat.com Thu May 19 08:38:31 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 May 2016 10:38:31 +0200 Subject: [Freeipa-devel] [PATCH 554] build: fix client-only build In-Reply-To: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> References: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> Message-ID: <57fbe895-3dd9-2e14-9d15-eaa19fa985b8@redhat.com> On 05/19/2016 10:34 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From slaznick at redhat.com Thu May 19 09:10:51 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 19 May 2016 11:10:51 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA In-Reply-To: References: Message-ID: NACK, see my comments below + # following upgrade steps require running CA This is a nitpicky nitpick but could you please change this comment for # the following ... Took me a while to understand what you were trying to say here. + if ca_running and not ca.is_running(): + ca.stop('pki-tomcat') + elif not ca_running and ca.is_running(): + ca.start('pki-tomcat') + You should swap ca.stop and ca.start here, you're stopping the service when it's stopped and starting it when it's already running. On 05/12/2016 04:34 PM, Martin Basti wrote: > Patch attached. > > https://fedorahosted.org/freeipa/ticket/5868 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu May 19 10:38:54 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 19 May 2016 12:38:54 +0200 Subject: [Freeipa-devel] [Testplan Review] Message-ID: <573D97BE.8020202@redhat.com> Hi all, I've created the first versio of the testplan for Topology Management feature in 4.4 release: http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan Could someone please review it? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ldoudova at redhat.com Thu May 19 10:42:34 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 19 May 2016 12:42:34 +0200 Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set In-Reply-To: <394813195.35159567.1463572280337.JavaMail.zimbra@redhat.com> References: <5735B5AD.9050803@redhat.com> <573C29DD.6070103@redhat.com> <394813195.35159567.1463572280337.JavaMail.zimbra@redhat.com> Message-ID: <573D989A.7020709@redhat.com> On 05/18/2016 01:51 PM, Ganna Kaihorodova wrote: > > ----- Original Message ----- > From: "Lenka Doudova" > To: "Ganna Kaihorodova" > Sent: Wednesday, May 18, 2016 10:37:49 AM > Subject: Fwd: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set > > > > -------- Forwarded Message -------- > Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length > higher than 255 cannot be set > Date: Fri, 13 May 2016 13:08:29 +0200 > From: Lenka Doudova > To: freeipa-devel > > > > Patch attached. > > Lenka > > > Hello, > > sorry, nack, because: > 1. Tests doesn't clean up after performing. Max user name isn't returned original value. > > 2. pep8 errors: > ./ipatests/test_xmlrpc/test_config_plugin.py:167:21: E126 continuation line over-indented for hanging indent > ./ipatests/test_xmlrpc/test_config_plugin.py:170:17: E121 continuation line under-indented for hanging indent > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer Hi, thanks for review, fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0013-2-Test-Maximum-username-length-higher-than-255-cannot-.patch Type: text/x-patch Size: 2200 bytes Desc: not available URL: From pvoborni at redhat.com Thu May 19 10:44:34 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 19 May 2016 12:44:34 +0200 Subject: [Freeipa-devel] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4 In-Reply-To: <573D6104.8000305@redhat.com> References: <5739CFB0.6000607@redhat.com> <573C83AF.6060309@redhat.com> <573D6104.8000305@redhat.com> Message-ID: On 05/19/2016 08:45 AM, Oleg Fayans wrote: > Hi Martin, > > I should probably rephrase my question: will the server_del API call be > added to 'ipa-server-install --uninstall' within 4.4 or is it a more > distant plan? It will be added in 4.4. Martin 3 is working on it. http://www.freeipa.org/page/V4/Manage_replication_topology_4_4#uninstallation https://fedorahosted.org/freeipa/ticket/5588 > > On 05/18/2016 05:18 PM, Martin Babinsky wrote: >> On 05/18/2016 05:01 PM, Oleg Fayans wrote: >>> Hi guys, >>> >>> Did I understand correctly that in 4.4 release the function of both >>> 'ipa-csreplica-manage del' and 'ipa-replica-manage del' will be >>> transfered to the API calls executed during replica uninstallation with >>> 'ipa-server-install --uninstall'? Which means that 'ipa-replica-manage >>> del' will be deprecated? >>> >>> >> >> `ipa-csreplica-manage del` is deprecated in domain level 1 topology and >> will raise an error, we even have a test case for this in replica >> promotion CI tests ;). So no `server_del` here. >> >> `ipa-replica-manage del` will not be explicitly deprecated, but it will >> call `server_del` behind the scenes. >> >>> On 05/16/2016 03:48 PM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> The design is OK, the onlz thing that is missing is a HowToTest section >>>> in track tickets [1] and [2] about clean-dangling-ruvs and >>>> abort-clean-ruv respectively. It would really help if these tickets had >>>> detailed steps to test (in case of dangling RUV's - steps to generate >>>> them) >>>> >>> >> >> > -- Petr Vobornik From pvoborni at redhat.com Thu May 19 10:54:38 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 19 May 2016 12:54:38 +0200 Subject: [Freeipa-devel] [Testplan Review] In-Reply-To: <573D97BE.8020202@redhat.com> References: <573D97BE.8020202@redhat.com> Message-ID: <15def057-454b-8fe1-7e93-0e63d81c2a62@redhat.com> On 05/19/2016 12:38 PM, Oleg Fayans wrote: > Hi all, > > I've created the first versio of the testplan for Topology Management > feature in 4.4 release: > http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan > > Could someone please review it? > I'll mention what are the important parts. 1. In the 3 scenarios, the most important one is testing the `ipa-server-install --uninstall`. There it is more important to check whether it did the same as `ipa-csreplica-manage del`, `ipa-replica-manage del` and `ipa-server-install --uninstall` procedure. Which means removal of master entry, DNS records, Kerberos keys, revocation of certificates... Checking RUVs is not the critical part. 2. I miss test for move of `ipa-replica-manage set-renewal-master` to API 3. test of new `ipa server-del` method when these three are done then I'd focus on RUVs -- Petr Vobornik From ftweedal at redhat.com Thu May 19 11:03:04 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 19 May 2016 21:03:04 +1000 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <36400a33-5b4f-435b-e2f6-066d3933ea55@redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> <20160518233119.GI19808@dhcp-40-8.bne.redhat.com> <36400a33-5b4f-435b-e2f6-066d3933ea55@redhat.com> Message-ID: <20160519110304.GK19808@dhcp-40-8.bne.redhat.com> On Thu, May 19, 2016 at 09:52:08AM +0200, Jan Cholasta wrote: > On 19.5.2016 01:31, Fraser Tweedale wrote: > > On Wed, May 18, 2016 at 03:17:37PM +0200, Jan Cholasta wrote: > > > Hi, > > > > > > On 18.5.2016 08:09, Fraser Tweedale wrote: > > > > Rebased version of 0057 attached, along with new patch 0058 that > > > > detects when the Dogtag version of caIPAserviceCert has been > > > > erroneously imported and repairs the profile. > > > > > > How to reproduce the issue? So far I had no luck with > > > freeipa-server-4.2.4-1.fc23.x86_64. > > > > > > Honza > > > > > `ipa-replica-install --setup-ca` with an affected version (including > > 4.2.4-1) will cause the issue. > > Thanks. > > The fix seems to work, although if you install an unfixed replica against a > fixed server, it will still break the profile. I'm not sure how much of a > problem this could be in the real world, though. > Thank you for testing. If un-fixed replica re-breaks the profile, the next server upgrade on any fixed replica will re-fix the profile. So assume customer eventually upgrades all replicas beyond the broken versions, it will converge on a fixed profile. > For the record, this is a diff between the relevant parts of a test > certificate issued before and after the fix: > > @@ -1,19 +1,19 @@ > Validity > Not Before: > Not After : > - Subject: O=IPA, OU=pki-ipa, > CN=vm-244.abc.idm.lab.eng.brq.redhat.com > + Subject: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM, > CN=vm-244.abc.idm.lab.eng.brq.redhat.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > @@ -36,48 +36,60 @@ > > keyid:89:8C:12:22:E7:D4:C5:87:06:26:5E:AE:C7:73:B5:4B:82:93:CE:1E > > Authority Information Access: > - OCSP - > URI:http://vm-244.abc.idm.lab.eng.brq.redhat.com:80/ca/ocsp > + OCSP - > URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ca/ocsp > > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Key Encipherment, Data > Encipherment > X509v3 Extended Key Usage: > TLS Web Server Authentication, TLS Web Client > Authentication > + X509v3 CRL Distribution Points: > + > + Full Name: > + URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ipa/crl/MasterCRL.bin > + CRL Issuer: > + DirName: O = ipaca, CN = Certificate Authority > + > + X509v3 Subject Key Identifier: > + 5E:A4:14:31:8E:71:00:4E:2A:71:D6:49:E4:1D:09:EC:10:DF:5D:B1 > Signature Algorithm: sha256WithRSAEncryption > > Note that SAN, if requested, would also not appear with the broken profile. > The ticket and bugzilla mention only OCSP URI being wrong. It should be > stated somewhere visible that the subject name and CRL distribution points > are also affected. > > BTW the CRL issuer field is wrong. In my case, the issuer name of the CRL is > "CN=Certificate Authority,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM", not > "CN=Certificate Authority,O=ipaca". Also, according to RFC 5280, section > 4.2.1.13, the CRL issuer field must be ommited if the CRL issuer is the same > as the certificate issuer. > It's been like that (i.e. wrong) forever. A proper fix, in light of sub-CAs work, will require a fair bit of work in Dogtag, i.e. a new profile component that implements the following heuristic: - Determine whether issuer has CRL(s) configured; if not, omit CRLDP - Determine whether issuer issues CRLs itself, or delegates. Construct CRLDP extension accordingly. Not gonna happen for v4.4 ;) Cheers, Fraser From jcholast at redhat.com Thu May 19 11:30:39 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 13:30:39 +0200 Subject: [Freeipa-devel] [PATCH 554] build: fix client-only build In-Reply-To: <57fbe895-3dd9-2e14-9d15-eaa19fa985b8@redhat.com> References: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> <57fbe895-3dd9-2e14-9d15-eaa19fa985b8@redhat.com> Message-ID: <02a96f50-13d5-5fbb-31c9-393ba10feb90@redhat.com> On 19.5.2016 10:38, Martin Babinsky wrote: > On 05/19/2016 10:34 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK Self-NACK, I have just noticed that the client-only build fails without 389-ds-base-devel installed. -- Jan Cholasta From jcholast at redhat.com Thu May 19 11:36:46 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 13:36:46 +0200 Subject: [Freeipa-devel] [PATCH] 0057..0058 Fix caIPAserviceCert regression In-Reply-To: <20160519110304.GK19808@dhcp-40-8.bne.redhat.com> References: <20160511090159.GU1237@dhcp-40-8.bne.redhat.com> <20160518060920.GF19808@dhcp-40-8.bne.redhat.com> <207ae8a7-bd90-19a1-3d02-b1729c01fbd0@redhat.com> <20160518233119.GI19808@dhcp-40-8.bne.redhat.com> <36400a33-5b4f-435b-e2f6-066d3933ea55@redhat.com> <20160519110304.GK19808@dhcp-40-8.bne.redhat.com> Message-ID: On 19.5.2016 13:03, Fraser Tweedale wrote: > On Thu, May 19, 2016 at 09:52:08AM +0200, Jan Cholasta wrote: >> On 19.5.2016 01:31, Fraser Tweedale wrote: >>> On Wed, May 18, 2016 at 03:17:37PM +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 18.5.2016 08:09, Fraser Tweedale wrote: >>>>> Rebased version of 0057 attached, along with new patch 0058 that >>>>> detects when the Dogtag version of caIPAserviceCert has been >>>>> erroneously imported and repairs the profile. >>>> >>>> How to reproduce the issue? So far I had no luck with >>>> freeipa-server-4.2.4-1.fc23.x86_64. >>>> >>>> Honza >>>> >>> `ipa-replica-install --setup-ca` with an affected version (including >>> 4.2.4-1) will cause the issue. >> >> Thanks. >> >> The fix seems to work, although if you install an unfixed replica against a >> fixed server, it will still break the profile. I'm not sure how much of a >> problem this could be in the real world, though. >> > Thank you for testing. If un-fixed replica re-breaks the profile, > the next server upgrade on any fixed replica will re-fix the > profile. So assume customer eventually upgrades all replicas beyond > the broken versions, it will converge on a fixed profile. Right. > >> For the record, this is a diff between the relevant parts of a test >> certificate issued before and after the fix: >> >> @@ -1,19 +1,19 @@ >> Validity >> Not Before: >> Not After : >> - Subject: O=IPA, OU=pki-ipa, >> CN=vm-244.abc.idm.lab.eng.brq.redhat.com >> + Subject: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM, >> CN=vm-244.abc.idm.lab.eng.brq.redhat.com >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> @@ -36,48 +36,60 @@ >> >> keyid:89:8C:12:22:E7:D4:C5:87:06:26:5E:AE:C7:73:B5:4B:82:93:CE:1E >> >> Authority Information Access: >> - OCSP - >> URI:http://vm-244.abc.idm.lab.eng.brq.redhat.com:80/ca/ocsp >> + OCSP - >> URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ca/ocsp >> >> X509v3 Key Usage: critical >> Digital Signature, Non Repudiation, Key Encipherment, Data >> Encipherment >> X509v3 Extended Key Usage: >> TLS Web Server Authentication, TLS Web Client >> Authentication >> + X509v3 CRL Distribution Points: >> + >> + Full Name: >> + URI:http://ipa-ca.abc.idm.lab.eng.brq.redhat.com/ipa/crl/MasterCRL.bin >> + CRL Issuer: >> + DirName: O = ipaca, CN = Certificate Authority >> + >> + X509v3 Subject Key Identifier: >> + 5E:A4:14:31:8E:71:00:4E:2A:71:D6:49:E4:1D:09:EC:10:DF:5D:B1 >> Signature Algorithm: sha256WithRSAEncryption >> >> > Note that SAN, if requested, would also not appear with the broken > profile. > >> The ticket and bugzilla mention only OCSP URI being wrong. It should be >> stated somewhere visible that the subject name and CRL distribution points >> are also affected. >> >> BTW the CRL issuer field is wrong. In my case, the issuer name of the CRL is >> "CN=Certificate Authority,O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM", not >> "CN=Certificate Authority,O=ipaca". Also, according to RFC 5280, section >> 4.2.1.13, the CRL issuer field must be ommited if the CRL issuer is the same >> as the certificate issuer. >> > It's been like that (i.e. wrong) forever. A proper fix, in light of > sub-CAs work, will require a fair bit of work in Dogtag, i.e. a new > profile component that implements the following heuristic: > > - Determine whether issuer has CRL(s) configured; if not, omit CRLDP > - Determine whether issuer issues CRLs itself, or delegates. > Construct CRLDP extension accordingly. > > Not gonna happen for v4.4 ;) OK. ACK then. Pushed to: master: 356f262fb7320345fd5f787c383912b9a2d77314 ipa-4-2: f116e51ce3d495758ff71f685b78d4848ce6708c ipa-4-3: e9672b1a2b191a1622f18a57a2751e4db3e9e39d -- Jan Cholasta From slaznick at redhat.com Thu May 19 11:34:23 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 19 May 2016 13:34:23 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA In-Reply-To: References: Message-ID: Also, I tried to upgrade from 4.2.4 to 4.3.1 and it seems that it might be necessary to start the service even earlier in the upgrade logic. Attached is the trace that occurred during the upgrade. I sent the whole log earlier accidentally, hopefully it will not arrive here as well. On 05/19/2016 11:10 AM, Stanislav Laznicka wrote: > > NACK, see my comments below > > + # following upgrade steps require running CA > This is a nitpicky nitpick but could you please change this comment > for # the following ... > Took me a while to understand what you were trying to say here. > + if ca_running and not ca.is_running(): > + ca.stop('pki-tomcat') > + elif not ca_running and ca.is_running(): > + ca.start('pki-tomcat') > + > You should swap ca.stop and ca.start here, you're stopping the service > when it's stopped and starting it when it's already running. > > On 05/12/2016 04:34 PM, Martin Basti wrote: >> Patch attached. >> >> https://fedorahosted.org/freeipa/ticket/5868 >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaupgrade.log Type: text/x-log Size: 2150 bytes Desc: not available URL: From jcholast at redhat.com Thu May 19 11:39:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 13:39:17 +0200 Subject: [Freeipa-devel] [PATCH 553] spec file: bump minimum required pki-core version In-Reply-To: References: <765811b3-605b-49e1-22a2-d4a651ae95ef@redhat.com> Message-ID: <76c177da-fffe-34ae-4966-1634927715f5@redhat.com> On 19.5.2016 10:35, Martin Babinsky wrote: > On 05/19/2016 10:20 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK Thanks. Pushed to: master: 1276083d95b41c91796cae9f8635fa4c89635bbd ipa-4-2: bd5abb444cd5099f90471f9121b37ce19b364c07 ipa-4-3: c90d6cd5ca78dd3c6fa492624895090aea4f5fc9 -- Jan Cholasta From jcholast at redhat.com Thu May 19 12:14:27 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 14:14:27 +0200 Subject: [Freeipa-devel] [PATCH 554] build: fix client-only build In-Reply-To: <02a96f50-13d5-5fbb-31c9-393ba10feb90@redhat.com> References: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> <57fbe895-3dd9-2e14-9d15-eaa19fa985b8@redhat.com> <02a96f50-13d5-5fbb-31c9-393ba10feb90@redhat.com> Message-ID: <21188833-afde-dab5-0df8-4ace2c82e0af@redhat.com> On 19.5.2016 13:30, Jan Cholasta wrote: > On 19.5.2016 10:38, Martin Babinsky wrote: >> On 05/19/2016 10:34 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> >>> >> ACK > > Self-NACK, I have just noticed that the client-only build fails without > 389-ds-base-devel installed. > Updated patch (with corrected number) attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-555.1-build-fix-client-only-build.patch Type: text/x-patch Size: 2761 bytes Desc: not available URL: From pspacek at redhat.com Thu May 19 12:26:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 May 2016 14:26:12 +0200 Subject: [Freeipa-devel] [PATCH 0112] pylint: replace Refactor category with individual check name Message-ID: Hello, pylint: replace Refactor category with individual check names This eases enabling/disabling individual tests like cyclic-import. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0112-pylint-replace-Refactor-category-with-individual-che.patch Type: text/x-patch Size: 1034 bytes Desc: not available URL: From mbasti at redhat.com Thu May 19 12:47:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 May 2016 14:47:09 +0200 Subject: [Freeipa-devel] [PATCH 0112] pylint: replace Refactor category with individual check name In-Reply-To: References: Message-ID: On 19.05.2016 14:26, Petr Spacek wrote: > Hello, > > pylint: replace Refactor category with individual check names > > This eases enabling/disabling individual tests like cyclic-import. > I like this patch but, NACK ......... ************* Module ipalib.config ipalib/config.py:260: [R0204(redefined-variable-type), Env.__setitem__] Redefinition of value type from int to ipapython.dn.DN) ipalib/config.py:458: [R0102(simplifiable-if-statement), Env._bootstrap] The if statement can be replaced with 'var = bool(test)') ************* Module ipalib.messages ipalib/messages.py:90: [R0204(redefined-variable-type), process_message_arguments] Redefinition of obj.strerror type from unicode to str) ************* Module ipalib.plugable ipalib/plugable.py:569: [R0204(redefined-variable-type), API.import_plugins] Redefinition of modules type from generator to list) ************* Module ipalib.rpc ipalib/rpc.py:609: [R0101(too-many-nested-blocks), KerbTransport.single_request] Too many nested blocks (6/5)) ipalib/rpc.py:753: [R0204(redefined-variable-type), RPCClient.get_url_list] Redefinition of answers type from dns.resolver.Answer to list) ........ tested with pylint-1.5.5-1.fc24.noarch From mbasti at redhat.com Thu May 19 13:53:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 May 2016 15:53:11 +0200 Subject: [Freeipa-devel] [PATCH 554] build: fix client-only build In-Reply-To: <21188833-afde-dab5-0df8-4ace2c82e0af@redhat.com> References: <43a9eaaf-e88f-6b57-58b5-d24f03355b9e@redhat.com> <57fbe895-3dd9-2e14-9d15-eaa19fa985b8@redhat.com> <02a96f50-13d5-5fbb-31c9-393ba10feb90@redhat.com> <21188833-afde-dab5-0df8-4ace2c82e0af@redhat.com> Message-ID: On 19.05.2016 14:14, Jan Cholasta wrote: > On 19.5.2016 13:30, Jan Cholasta wrote: >> On 19.5.2016 10:38, Martin Babinsky wrote: >>> On 05/19/2016 10:34 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>>> >>>> >>> ACK >> >> Self-NACK, I have just noticed that the client-only build fails without >> 389-ds-base-devel installed. >> > > Updated patch (with corrected number) attached. > > > ACK Pushed to: master: 54520064989c8a9e45bcaea2e9463c7a62416c0a ipa-4-3: 6bf4f15be7a58642b671a817af7337b24edfcf16 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu May 19 14:43:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 May 2016 16:43:05 +0200 Subject: [Freeipa-devel] [PATCH 556] makeapi: use the same formatting for `int` and `long` values Message-ID: <9730e1a6-7634-ea94-bd34-e6b94c2a43dd@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-556-makeapi-use-the-same-formatting-for-int-and-long-val.patch Type: text/x-patch Size: 954 bytes Desc: not available URL: From mbasti at redhat.com Thu May 19 14:45:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 May 2016 16:45:18 +0200 Subject: [Freeipa-devel] [PATCH 556] makeapi: use the same formatting for `int` and `long` values In-Reply-To: <9730e1a6-7634-ea94-bd34-e6b94c2a43dd@redhat.com> References: <9730e1a6-7634-ea94-bd34-e6b94c2a43dd@redhat.com> Message-ID: On 19.05.2016 16:43, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK Pushed to: master: 83f6ddb473156c0eb1d85f98a7eb2997e7b70dc5 ipa-4-3: f8edf37e9544e319adfff75ba87df826bb1ca42e -------------- next part -------------- An HTML attachment was scrubbed... URL: From gkaihoro at redhat.com Thu May 19 14:46:58 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Thu, 19 May 2016 10:46:58 -0400 (EDT) Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set In-Reply-To: <573D989A.7020709@redhat.com> References: <5735B5AD.9050803@redhat.com> <573C29DD.6070103@redhat.com> <394813195.35159567.1463572280337.JavaMail.zimbra@redhat.com> <573D989A.7020709@redhat.com> Message-ID: <1326069377.36201827.1463669218575.JavaMail.zimbra@redhat.com> Hello! Everything is ok, so ack Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Lenka Doudova" To: "Ganna Kaihorodova" Cc: freeipa-devel at redhat.com Sent: Thursday, May 19, 2016 12:42:34 PM Subject: Re: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set On 05/18/2016 01:51 PM, Ganna Kaihorodova wrote: > > ----- Original Message ----- > From: "Lenka Doudova" > To: "Ganna Kaihorodova" > Sent: Wednesday, May 18, 2016 10:37:49 AM > Subject: Fwd: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set > > > > -------- Forwarded Message -------- > Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length > higher than 255 cannot be set > Date: Fri, 13 May 2016 13:08:29 +0200 > From: Lenka Doudova > To: freeipa-devel > > > > Patch attached. > > Lenka > > > Hello, > > sorry, nack, because: > 1. Tests doesn't clean up after performing. Max user name isn't returned original value. > > 2. pep8 errors: > ./ipatests/test_xmlrpc/test_config_plugin.py:167:21: E126 continuation line over-indented for hanging indent > ./ipatests/test_xmlrpc/test_config_plugin.py:170:17: E121 continuation line under-indented for hanging indent > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer Hi, thanks for review, fixed patch attached. Lenka From mbabinsk at redhat.com Thu May 19 14:59:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 May 2016 16:59:08 +0200 Subject: [Freeipa-devel] [PATCH 0146-0147] Server Roles: basic infrastructure Message-ID: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> Patch 0146 implements lower-lever infrastructure for querying server roles/attributes Patch 0147 are some basic tests slapped together for the `serverroles` backend to ensure that it works as expected. The new/modified CLI commands specified in the design page [1] will be coming soon. Also coming soon will be an interface to construct DNS records for each role requested by Petr^2 and Martin^2 which I will start implement when we agree on the backend implementation. https://fedorahosted.org/freeipa/ticket/5181 [1] https://www.freeipa.org/page/V4/Server_Roles#CLI -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0146-Server-Roles-infrastructure-for-role-attribute-defin.patch Type: text/x-patch Size: 28641 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0147-Test-suite-for-serverroles-backend.patch Type: text/x-patch Size: 26541 bytes Desc: not available URL: From abokovoy at redhat.com Thu May 19 20:39:32 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 May 2016 23:39:32 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain Message-ID: <20160519203932.tqyf5lpppyfde4na@redhat.com> Hi, A new design page is ready for review: http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain Below is the text for convenience. I did test both scenarios successfully. Single sign-on scenario: - Client has A/AAAA record in IDM DNS domain and CNAME record in AD DNS domain - SSO with Kerberos is possible from Windows machines Non-single sign-on scenario: - Client has A/AAAA record in AD DNS domain - No SSO with Kerberos is possible from Windows machines ---- {{Feature|version=4.4.0|ticket=5762|author=Ab}} == Overview == In the ideal world, FreeIPA clients should be deployed in DNS zones owned by FreeIPA. However, in many environments where FreeIPA is being deployed, Active Directory is the dominant identity management solution owning not only the identities, but also the DNS domains. Currently, the only solution how to migrate a Linux client in such AD owned DNS domain to FreeIPA was to move it to FreeIPA owned domain. While this procedure works well when migrating 10 client systems, it is less desirable when migrating 10k client systems. == Use Cases == === User Story === As an Administrator with a big number of Linux machines in a DNS domain controlled by Active Directory, I want to join them to the IdM Server so that they can benefit from it?s Linux focused features. === Details === Allow FreeIPA client to respond a host name in a DNS domain belonging to a domain from a trusted Active Directory forest. If Active Directory forest example.com uses DNS zone ''example.com'', and FreeIPA is deployed at ''ipa.example.com'', then it is desirable to have some FreeIPA machines accessible as machine-foo.example.com, not just ''machine-foo.ipa.example.com''. In many cases FreeIPA client machines are used as servers for hosting applications in the same DNS name space as existing Active Directory environment. While Active Directory enforces ownership of resources (DNS domain is owned by corresponding Active Directory domain) and FreeIPA cannot be part of the Active Directory forest by itself, it should be possible to have a DNS host name for FreeIPA client as a part of a DNS domain of existing Active Directory domain and still allow single sign-on operations. == Theory and practice of a forest trust interaction == There are several concepts needs to be understood for the setup when FreeIPA machine is a part of the DNS zone belonging to the domain of Active Directory forest: * Active Directory has a concept of relationship between the domain and DNS zones. An Active Directory domain ''owns'' DNS zone of the same name and no other Active Directory domain may claim the same DNS zone. * When forest trust is established between FreeIPA and an Active Directory forest, Active Directory Domain Controller enforces non-conflict check of the DNS name spaces claimed by FreeIPA. If there is any conflict between what FreeIPA claims to own and what the Active Directory Domain Controller knows to belong to any of the Active Directory domain in the same forest, a link between FreeIPA and AD would be disabled and no authentication would be possible across the trust link. * FreeIPA automatically adds DNS domains it manages to the list of DNS domains associated with FreeIPA realm. This list is then presented to Active Directory when trust is established to allow proper routing of authentication requests when talking to servers in these DNS domains. As a consequence, Active Directory will never refer authentication request to FreeIPA domain controller for a Kerberos service principal on a host within DNS zone owned by Active Directory. This means no Kerberos authentication is possible against such FreeIPA machines from Windows systems. When FreeIPA client ''ipa-client.ipa.domain'' is enrolled into FreeIPA realm, following is done: # Host object ''ipa-client.ipa.domain'' is created in FreeIPA to hold references to the new FreeIPA client # Kerberos principal is created based on the host object, ''host/ipa-client.ipa.domain at IPA.DOMAIN'' # Keys for this principal retrieved and stored in ''/etc/krb5.keytab'' on the FreeIPA client # Kerberos configuration is added to ''/etc/krb5.conf'' to refer ''IPA.DOMAIN'' Kerberos realm to FreeIPA KDC and map ''ipa.domain'' DNS zone to ''IPA.DOMAIN'' Kerberos realm # SSSD daemon on FreeIPA will attempt to update DNS record for ''ipa-client.ipa.domain'' using the host Kerberos principal created above. Host object in FreeIPA is decoupled from the corresponding DNS record. Creating the host object with host name from non-FreeIPA DNS zone does not cause adding that DNS zone to the list of DNS zones associated with FreeIPA realm. The way how Kerberos configuration for FreeIPA realm in ''/etc/krb5.conf'' is added depends on the way how ''ipa-client-install'' tool discovered the FreeIPA realm. When automated discovery via DNS SRV records was successful, no explicit configuration for the FreeIPA realm would be added. Instead, DNS-based realm and KDC discovery will be activated. If FreeIPA client is placed in a DNS domain of Active Directory, automated discovery would be run against Active Directory's DNS domain and FreeIPA would not be discovered. To aid the proper discovery, ''--domain'' option has to be passed to ''ipa-client-install'' tool. A mapping between DNS domain and Kerberos realm is created where the FreeIPA client's domain is explicitly mapped to point to the FreeIPA realm. To sum up, for FreeIPA realm IPA.EXAMPLE.COM and Active Directory EXAMPLE.COM, when FreeIPA client has host name ipa-client.example.com, following configuration would be written if ''ipa-client-install --domain ipa.example.com'' was used to configure the FreeIPA client (abbreviated): /etc/krb5.conf [libdefaults] dns_lookup_realm = true dns_lookup_kdc = true [realms] IPA.EXAMPLE.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .ipa.example.com = IPA.EXAMPLE.COM ipa.example.com = IPA.EXAMPLE.COM .example.com = IPA.EXAMPLE.COM example.com = IPA.EXAMPLE.COM As can be seen above, look up for any service principal on the hosts in DNS zone ''example.com'' will be forced to belong to realm ''IPA.EXAMPLE.COM''. This means the client will not be able correctly communicate with services enrolled into Active Directory because all Kerberos requests for ''EXAMPLE.COM'' realm would be instead sent to the KDC of ''IPA.EXAMPLE.COM''. It is, however, possible to change .example.com = IPA.EXAMPLE.COM example.com = IPA.EXAMPLE.COM to explicit configuration for the FreeIPA hostname: ipa-client.example.com = IPA.EXAMPLE.COM and leave out any other explicit mapping for ''.example.com'' to have it discovered via DNS SRV record lookups. Note that the setup above will not allow machines from realm ''EXAMPLE.COM'' to properly obtain a service ticket towards ''ipa-client.example.com'' because they will be thinking ''ipa-client.example.com'' belongs to realm ''EXAMPLE.COM''. On Linux machines it would be possible to extend ''[domain_realm]'' mapping the same way to force a single machine to map to the right realm but in Active Directory it is not possible to do so. For Kerberos-based authentication and access to services running on FreeIPA machines to work, two conditions must be satisfied: # Client A must be able to talk to the KDC of its own realm to request a service ticket to server B or a cross-realm TGT for realm of the server B and then request a service ticket to server B # Server B must be able to talk to the KDC of its own realm Condition (1) is needed so that client A could present the service ticket to the service running on the server B to mutually authenticate. Condition (2) is needed for SSSD on server B to be able to transform an incoming Kerberos principal identity to an identity understood by the underlying POSIX environment. As result, KDC of the client's realm must know either Kerberos principal for a service on the server B, or should be able to issue a cross-realm referral ticket to the KDC of the realm where the Kerberos principal is located. In practice, this means that either server B is enrolled to Active Directory domain, or it is enrolled to FreeIPA domain _and_ a cross-forest trust is established between the FreeIPA and the Active Directory forest root domain. However, if server B is enrolled to the FreeIPA domain, its DNS host name cannot be part of the ''example.com'' DNS zone because this is prohibited by MS-ADTS specification, [https://msdn.microsoft.com/en-us/library/cc223787.aspx section 6.1.6.9.3.2 "Building Well-Formed msDS-TrustForestTrustInfo Message"]. An abridged version of these rules is available in MS-LSAD, [https://msdn.microsoft.com/en-us/library/cc234372.aspx section 3.1.4.7.16.1 "Forest Trust Collision Generation"]: The rules for top-level name entries are as follows: * An enabled (that is, non-conflict) top-level name record must not be equal to an enabled top-level name for another trusted domain object or to any of the DNS tree names within the current forest. Equality is computed using case-insensitive string comparison. If the strings differ only by one trailing '.' character, the difference is ignored. * The top-level name must not be subordinate to an enabled top-level name for another trusted domain object, unless the other trusted domain object has a corresponding exclusion record. * A top-level name must not be superior to an enabled top-level name for another trusted domain object, unless the current trusted domain object has a corresponding exclusion record. If any of these rules are violated, a top-level name is considered in conflict. The solution for Kerberos-based authentication and access to resources in DNS zone owned by an Active Directory domain relies on the fact that Kerberos libraries use a specific logic to discover actual service principal for host- based services. MIT Kerberos as an implementation of Kerberos protocol follow [http://web.mit.edu/Kerberos/krb5-latest/doc/admin/princ_dns.html these rules]: MIT Kerberos clients currently always do forward resolution (looking up the IPv4 and possibly IPv6 addresses using getaddrinfo()) of the hostname part of a host-based service principal to canonicalize the hostname. They obtain the ?canonical? name of the host when doing so. In practice this also means any CNAME record will be resolved to the corresponding A/AAAA record and the result is then used to construct host- based Kerberos principal (e.g. ''nfs/ipa-client.example.com''). The same logic is used by Active Directory: * If FreeIPA client is enrolled as ''ipa-client.ipa.example.com'' (A/AAA records set using this hostname) and * there is CNAME record ''ipa-client.example.com'' pointing to ''ipa-client.ipa.example.com'', * then Windows client will attempt to request a Kerberos service ticket for a host-based service on the host ''ipa-client.ipa.example.com'' As result, no machine with A/AAAA DNS record ''ipa-client.example.com'' can operate properly with Kerberos in Active Directory while being part of a Kerberos realm different to ''EXAMPLE.COM'' but a CNAME record ''ipa-client.example.com'' can point to A/AAAA DNS record ''ipa-client.ipa.example.com'' to allow Kerberos authentication. == Possible solutions == Depending on what is required to achieve, there are two solutions possible. In both cases we assume proper enrollment of the client to FreeIPA by means of ''ipa-client-install'' tool which would set up SSSD with 'ipa' identity provider. === No single sign-on required === When no single sign-on (Kerberos authentication) required, we still should make sure Kerberos configuration is set up to allow SSSD to communicate with FreeIPA masters. FreeIPA client should be configured with ''ipa-client-install --domain=ipa.example.com'' so that auto-detection of Active Directory domain via SRV records in DNS domain ''example.com'' will not be done. Kerberos configuration in ''/etc/krb5.conf'' should be modified to add: [domain_realm] ipa-client.example.com = IPA.EXAMPLE.COM This configuration change will ensure that the host itself is associated with FreeIPA realm on this machine. Only password-based logon will work for accessing resources on this machine. Any Kerberos or GSSAPI based access will fail from both other FreeIPA machines or Active Directory clients as long as originating machines have no mapping in their Kerberos configuration for ''ipa-client.example.com'' to ''IPA.EXAMPLE.COM'' realm. As described in the previous sections, on Active Directory side it is not possible to add such configuration. If AD users logged in with password using SSH session or GNOME Desktop manager, they might get valid Kerberos credentials in their credentials cache. To use these credentials against any other Active Directory-enrolled Windows resources one needs to remove Kerberos domain-realm mapping that forces ''.example.com'' to be associated with ''IPA.EXAMPLE.COM'' realm: /etc/krb5.conf [domain_realm] .ipa.example.com = IPA.EXAMPLE.COM ipa.example.com = IPA.EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM Once ''.example.com'' is associated with ''EXAMPLE.COM'' realm, actual Kerberos credentials obtained on the FreeIPA client as part of the OpenSSH logon can be used to authenticate against other Active Directory resources. ==== Handling of SSL certificates ==== For SSL-based service protection (HTTPS, IMAPS, etc), a certificate with dNSName extension records covering all system hostnames is required due to the fact that both original (A/AAAA) and CNAME record names need to be in the certificate. Currently FreeIPA only issues certificates to host objects presenting in FreeIPA database. For the case when single sign-on is not required, it is assumed that the host ''ipa-client.example.com'' is enrolled into FreeIPA realm. This means there is already a host object for ''ipa-client.example.com'' in FreeIPA and Certmonger can already request for the certificate in its name: ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=`hostname --fqdn` \ -D `hostname --fqdn` \ -K host/ipa-client.example.com at IPA.EXAMPLE.COM \ -U id-kp-serverAuth This example allows to request an SSL certificate from FreeIPA CA to store it in ''server.crt'' (public key) and ''server.key'' (private key) files. Certmonger uses default host key stored in ''/etc/krb5.keytab'' to authenticate against FreeIPA CA. This means Kerberos authentication against ''IPA.EXAMPLE.COM'' realm should be properly working which is why ''ipa-client.example.com = IPA.EXAMPLE.COM'' was added to ''[domain_realm]'' mapping in ''/etc/krb5.conf'' above. === Single sign-on required === When single sign-on is required, moving FreeIPA client outside DNS zone ''example.com'' is the pre-requisite. A CNAME record ''ipa-client.example.com'' can then be created to point to the A/AAAA record of the FreeIPA client. E.g., ''ipa-client.ipa.example.com''. For Kerberos-based application servers MIT Kerberos supports a method to allow accept any host-based principal available in the application's keytab. When Kerberos client would connect to a Kerberos application server, such server typically does strict check on what Kerberos principal was used to target it (so-called, 'acceptor check'). This can be relaxed: [libdefaults] ignore_acceptor_hostname = true For OpenSSH server there is a specific option ''GSSAPIStrictAcceptorCheck no'' to achieve the same. ==== Handling of SSL certificates ==== For SSL-based service protection (HTTPS, IMAPS, etc), a certificate with dNSName extension records covering all system hostnames is required due to the fact that both original (A/AAAA) and CNAME record names need to be in the certificate. Currently FreeIPA only issues certificates to host objects presenting in FreeIPA database. This means one would need to create host object for ''ipa-client.example.com'' in FreeIPA and make sure the real FreeIPA machine's host object is able to manage this host: ipa host-add ipa-client.example.com --force ipa host-add-managedby ipa-client.example.com --hosts=ipa-client.ipa.example.com We have to use ''--force'' option here because ''ipa-client.example.com'' is a CNAME, not an A/AAAA DNS record as required by FreeIPA. With this setup ''ipa-client.ipa.example.com'' would be able to request an SSL certificate with dNSName extension record for ''ipa-client.example.com''. ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=`hostname --fqdn` \ -D `hostname --fqdn` \ -D ipa-client.example.com \ -K host/ipa-client.ipa.example.com at IPA.EXAMPLE.COM \ -U id-kp-serverAuth ---- -- / Alexander Bokovoy From pspacek at redhat.com Fri May 20 08:26:16 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 10:26:16 +0200 Subject: [Freeipa-devel] [PATCH 0112] pylint: replace Refactor category with individual check name In-Reply-To: References: Message-ID: On 19.5.2016 14:47, Martin Basti wrote: > On 19.05.2016 14:26, Petr Spacek wrote: >> Hello, >> >> pylint: replace Refactor category with individual check names >> >> This eases enabling/disabling individual tests like cyclic-import. >> > > I like this patch but, NACK > > ......... > ************* Module ipalib.config > ipalib/config.py:260: [R0204(redefined-variable-type), Env.__setitem__] > Redefinition of value type from int to ipapython.dn.DN) > ipalib/config.py:458: [R0102(simplifiable-if-statement), Env._bootstrap] The > if statement can be replaced with 'var = bool(test)') > ************* Module ipalib.messages > ipalib/messages.py:90: [R0204(redefined-variable-type), > process_message_arguments] Redefinition of obj.strerror type from unicode to str) > ************* Module ipalib.plugable > ipalib/plugable.py:569: [R0204(redefined-variable-type), API.import_plugins] > Redefinition of modules type from generator to list) > ************* Module ipalib.rpc > ipalib/rpc.py:609: [R0101(too-many-nested-blocks), > KerbTransport.single_request] Too many nested blocks (6/5)) > ipalib/rpc.py:753: [R0204(redefined-variable-type), RPCClient.get_url_list] > Redefinition of answers type from dns.resolver.Answer to list) > ........ > > > tested with pylint-1.5.5-1.fc24.noarch Here it is. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0112-2-pylint-replace-Refactor-category-with-individual-che.patch Type: text/x-patch Size: 1184 bytes Desc: not available URL: From cfu at redhat.com Thu May 19 21:38:58 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 19 May 2016 14:38:58 -0700 Subject: [Freeipa-devel] Karma Request for JSS 4.2.6-39 on Fedora 24 Message-ID: <573E3272.9090600@redhat.com> The following candidate builds of JSS 4.2.6-39 for Fedora 24 (final) consist of the following: jss-4.2.6-39.fc24 Please provide Karma for these builds in Bodhi located at: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d3c8f022c5 Additionally, the following builds have been provided for Fedora 25 (rawhide): jss-4.2.6-39.fc25 Thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri May 20 00:07:19 2016 From: cfu at redhat.com (Christina Fu) Date: Thu, 19 May 2016 17:07:19 -0700 Subject: [Freeipa-devel] Karma Request for JSS 4.2.6-39 on Fedora 24 In-Reply-To: <573E3272.9090600@redhat.com> References: <573E3272.9090600@redhat.com> Message-ID: <573E5537.3010801@redhat.com> Had to respin due to small piece of incompatible code that failed to compile on rhel7. The following candidate builds of JSS 4.2.6-39 for Fedora 24 (final) consist of the following: jss-4.2.6-40.fc24 Please provide Karma for these builds in Bodhi located at: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c036afbe30 Additionally, the following builds have been provided for Fedora 25(rawhide): jss-4.2.6-40.fc25 Thanks, Christina On 05/19/2016 02:38 PM, Christina Fu wrote: > The following candidate builds of JSS 4.2.6-39 for Fedora 24 (final) > consist of the following: > jss-4.2.6-39.fc24 > > > Please provide Karma for these builds in Bodhi located at: > https://bodhi.fedoraproject.org/updates/FEDORA-2016-d3c8f022c5 > > Additionally, the following builds have been provided for Fedora 25 > (rawhide): > jss-4.2.6-39.fc25 > > > Thanks, > Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri May 20 09:55:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 11:55:41 +0200 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160519203932.tqyf5lpppyfde4na@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> Message-ID: <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> On 19.5.2016 22:39, Alexander Bokovoy wrote: > Hi, > > A new design page is ready for review: > http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain > > Below is the text for convenience. I did test both scenarios > successfully. > > Single sign-on scenario: > - Client has A/AAAA record in IDM DNS domain and CNAME record in AD DNS > domain > - SSO with Kerberos is possible from Windows machines > > Non-single sign-on scenario: > - Client has A/AAAA record in AD DNS domain > - No SSO with Kerberos is possible from Windows machines > > ---- > {{Feature|version=4.4.0|ticket=5762|author=Ab}} > > == Overview == > In the ideal world, FreeIPA clients should be deployed in DNS zones > owned by FreeIPA. However, in many environments where FreeIPA is being > deployed, Active Directory is the dominant identity management solution > owning not only the identities, but also the DNS domains. Currently, the > only solution how to migrate a Linux client in such AD owned DNS domain > to FreeIPA was to move it to FreeIPA owned domain. While this procedure > works well when migrating 10 client systems, it is less desirable when > migrating 10k client systems. > > == Use Cases == > === User Story === > As an Administrator with a big number of Linux machines in a DNS domain > controlled by Active Directory, I want to join them to the IdM Server so > that they can benefit from it?s Linux focused features. > > === Details === > Allow FreeIPA client to respond a host name in a DNS domain belonging to > a domain from a trusted Active Directory forest. > > If Active Directory forest example.com uses DNS zone ''example.com'', > and FreeIPA is deployed at ''ipa.example.com'', then it is desirable to > have some FreeIPA machines accessible as machine-foo.example.com, not > just ''machine-foo.ipa.example.com''. > > In many cases FreeIPA client machines are used as servers for hosting > applications in the same DNS name space as existing Active Directory > environment. While Active Directory enforces ownership of resources (DNS > domain is owned by corresponding Active Directory domain) and FreeIPA > cannot be part of the Active Directory forest by itself, it should be > possible to have a DNS host name for FreeIPA client as a part of a DNS > domain of existing Active Directory domain and still allow single > sign-on operations. > > == Theory and practice of a forest trust interaction == > > There are several concepts needs to be understood for the setup when > FreeIPA machine is a part of the DNS zone belonging to the domain of > Active Directory forest: > > * Active Directory has a concept of relationship between the domain and > DNS zones. An Active Directory domain ''owns'' DNS zone of the same > name and no other Active Directory domain may claim the same DNS > zone. > > * When forest trust is established between FreeIPA and an Active > Directory forest, Active Directory Domain Controller enforces > non-conflict check of the DNS name spaces claimed by FreeIPA. If > there is any conflict between what FreeIPA claims to own and what the > Active Directory Domain Controller knows to belong to any of the > Active Directory domain in the same forest, a link between FreeIPA > and AD would be disabled and no authentication would be possible > across the trust link. > > * FreeIPA automatically adds DNS domains it manages to the list of DNS > domains associated with FreeIPA realm. This list is then presented to > Active Directory when trust is established to allow proper routing of > authentication requests when talking to servers in these DNS domains. > > As a consequence, Active Directory will never refer authentication request to > FreeIPA domain controller for a Kerberos service principal on a host within > DNS zone owned by Active Directory. This means no Kerberos authentication is > possible against such FreeIPA machines from Windows systems. > > When FreeIPA client ''ipa-client.ipa.domain'' is enrolled into FreeIPA > realm, following is done: > > # Host object ''ipa-client.ipa.domain'' is created in FreeIPA to hold > references to the new FreeIPA client > # Kerberos principal is created based on the host object, > ''host/ipa-client.ipa.domain at IPA.DOMAIN'' > # Keys for this principal retrieved and stored in ''/etc/krb5.keytab'' on the > FreeIPA client > # Kerberos configuration is added to ''/etc/krb5.conf'' to refer > ''IPA.DOMAIN'' Kerberos realm to FreeIPA KDC and map ''ipa.domain'' DNS zone > to ''IPA.DOMAIN'' Kerberos realm > # SSSD daemon on FreeIPA will attempt to update DNS record for > ''ipa-client.ipa.domain'' using the host Kerberos principal created above. > > Host object in FreeIPA is decoupled from the corresponding DNS record. > Creating the host object with host name from non-FreeIPA DNS zone does > not cause adding that DNS zone to the list of DNS zones associated with > FreeIPA realm. > > The way how Kerberos configuration for FreeIPA realm in ''/etc/krb5.conf'' is > added > depends on the way how ''ipa-client-install'' tool discovered the FreeIPA > realm. When automated discovery via DNS SRV records was successful, no > explicit configuration > for the FreeIPA realm would be added. Instead, DNS-based realm and KDC > discovery will > be activated. > > If FreeIPA client is placed in a DNS domain of Active Directory, automated > discovery would be run against Active Directory's DNS domain and FreeIPA would > not be discovered. To aid the proper discovery, ''--domain'' option has to > be passed to ''ipa-client-install'' tool. > > A mapping between DNS domain and Kerberos realm is created where the FreeIPA > client's domain is explicitly mapped to point to the FreeIPA realm. > > To sum up, for FreeIPA realm IPA.EXAMPLE.COM and Active Directory EXAMPLE.COM, > when FreeIPA client has host name ipa-client.example.com, following > configuration would be written if ''ipa-client-install --domain ipa.example.com'' > was used to configure the FreeIPA client (abbreviated): > > /etc/krb5.conf > [libdefaults] > dns_lookup_realm = true > dns_lookup_kdc = true > [realms] > IPA.EXAMPLE.COM = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > [domain_realm] > .ipa.example.com = IPA.EXAMPLE.COM > ipa.example.com = IPA.EXAMPLE.COM > .example.com = IPA.EXAMPLE.COM > example.com = IPA.EXAMPLE.COM > > As can be seen above, look up for any service principal on the hosts in DNS > zone ''example.com'' will be forced to belong to realm ''IPA.EXAMPLE.COM''. > This means the client will not be able correctly communicate with services > enrolled into Active Directory because all Kerberos requests for > ''EXAMPLE.COM'' realm would be instead sent to the KDC of ''IPA.EXAMPLE.COM''. > > It is, however, possible to change > > .example.com = IPA.EXAMPLE.COM > example.com = IPA.EXAMPLE.COM > > to explicit configuration for the FreeIPA hostname: > > ipa-client.example.com = IPA.EXAMPLE.COM > > and leave out any other explicit mapping for ''.example.com'' to have it > discovered via DNS SRV record lookups. > > Note that the setup above will not allow machines from realm ''EXAMPLE.COM'' > to properly obtain a service ticket towards ''ipa-client.example.com'' because > they will be thinking ''ipa-client.example.com'' belongs to realm > ''EXAMPLE.COM''. On Linux machines it would be possible to extend > ''[domain_realm]'' mapping the same way to force a single machine to map to > the right realm but in Active Directory it is not possible to do so. > > For Kerberos-based authentication and access to services running on FreeIPA > machines to work, two conditions must be satisfied: > > # Client A must be able to talk to the KDC of its own realm to request a > service ticket to server B or a cross-realm TGT for realm of the > server B and then request a service ticket to server B > > # Server B must be able to talk to the KDC of its own realm > > Condition (1) is needed so that client A could present the service ticket to > the service running on the server B to mutually authenticate. Condition (2) is > needed for SSSD on server B to be able to transform an incoming Kerberos > principal identity to an identity understood by the underlying POSIX > environment. > > As result, KDC of the client's realm must know either Kerberos principal for a > service on the server B, or should be able to issue a cross-realm referral > ticket to the KDC of the realm where the Kerberos principal is located. In > practice, this means that either server B is enrolled to Active Directory > domain, or it is enrolled to FreeIPA domain _and_ a cross-forest trust is > established between the FreeIPA and the Active Directory forest root domain. > > However, if server B is enrolled to the FreeIPA domain, its DNS host name > cannot be part of the ''example.com'' DNS zone because this is prohibited by > MS-ADTS specification, [https://msdn.microsoft.com/en-us/library/cc223787.aspx > section 6.1.6.9.3.2 "Building Well-Formed msDS-TrustForestTrustInfo Message"]. > An abridged version of these rules is available in MS-LSAD, > [https://msdn.microsoft.com/en-us/library/cc234372.aspx section 3.1.4.7.16.1 > "Forest Trust Collision Generation"]: > > The rules for top-level name entries are as follows: > > * An enabled (that is, non-conflict) top-level name record must not be equal > to an enabled top-level name for another trusted domain object or to any of > the DNS tree names within the current forest. Equality is computed using > case-insensitive string comparison. If the strings differ only by one trailing > '.' character, the difference is ignored. > * The top-level name must not be subordinate to an enabled top-level name for > another trusted domain object, unless the other trusted domain object has a > corresponding exclusion record. > * A top-level name must not be superior to an enabled top-level name for > another trusted domain object, unless the current trusted domain object has a > corresponding exclusion record. > > If any of these rules are violated, a top-level name is considered in conflict. > > The solution for Kerberos-based authentication and access to resources in DNS > zone owned by an Active Directory domain relies on the fact that Kerberos > libraries use a specific logic to discover actual service principal for host- > based services. > MIT Kerberos as an implementation of Kerberos protocol follow > [http://web.mit.edu/Kerberos/krb5-latest/doc/admin/princ_dns.html these rules]: > MIT Kerberos clients currently always do forward resolution (looking > up the IPv4 and possibly IPv6 addresses using getaddrinfo()) of the hostname > part of a host-based service principal to canonicalize the hostname. They > obtain the ?canonical? name of the host when doing so. > > In practice this also means any CNAME record will be resolved to the > corresponding A/AAAA record and the result is then used to construct host- > based Kerberos principal (e.g. ''nfs/ipa-client.example.com''). > > The same logic is used by Active Directory: > > * If FreeIPA client is enrolled as ''ipa-client.ipa.example.com'' (A/AAA > records set using this hostname) and > * there is CNAME record ''ipa-client.example.com'' pointing to > ''ipa-client.ipa.example.com'', > * then Windows client will attempt to request a Kerberos service ticket for a > host-based service on the host ''ipa-client.ipa.example.com'' > > As result, no machine with A/AAAA DNS record ''ipa-client.example.com'' can > operate properly with Kerberos in Active Directory while being part of a > Kerberos realm different to ''EXAMPLE.COM'' but a CNAME record > ''ipa-client.example.com'' can point to A/AAAA DNS record > ''ipa-client.ipa.example.com'' to allow Kerberos authentication. > > == Possible solutions == > > Depending on what is required to achieve, there are two solutions possible. In > both cases we assume proper enrollment of the client to FreeIPA by means of > ''ipa-client-install'' tool which would set up SSSD with 'ipa' identity > provider. > > === No single sign-on required === > > When no single sign-on (Kerberos authentication) required, we still should > make sure Kerberos configuration is set up to allow SSSD to communicate with > FreeIPA masters. > > FreeIPA client should be configured with ''ipa-client-install > --domain=ipa.example.com'' > so that auto-detection of Active Directory domain via SRV records > in DNS domain ''example.com'' will not be done. > > Kerberos configuration in ''/etc/krb5.conf'' should be modified to add: > > [domain_realm] > ipa-client.example.com = IPA.EXAMPLE.COM > > This configuration change will ensure that the host itself is associated with > FreeIPA realm on this machine. > > Only password-based logon will work for accessing resources on this machine. > Any Kerberos or GSSAPI based access will fail from both other FreeIPA machines or > Active Directory clients as long as originating machines have no mapping in > their Kerberos configuration for ''ipa-client.example.com'' to > ''IPA.EXAMPLE.COM'' realm. As described in the previous sections, on Active > Directory side it is not possible to add such configuration. > > If AD users logged in with password using SSH session or GNOME Desktop manager, > they might get valid Kerberos credentials in their credentials cache. To use > these credentials against any other Active Directory-enrolled Windows resources > one needs to remove Kerberos domain-realm mapping that forces ''.example.com'' to > be associated with ''IPA.EXAMPLE.COM'' realm: > > /etc/krb5.conf > [domain_realm] > .ipa.example.com = IPA.EXAMPLE.COM > ipa.example.com = IPA.EXAMPLE.COM > .example.com = EXAMPLE.COM > example.com = EXAMPLE.COM > > Once ''.example.com'' is associated with ''EXAMPLE.COM'' realm, actual Kerberos > credentials obtained on the FreeIPA client as part of the OpenSSH logon can be > used to authenticate against other Active Directory resources. > ==== Handling of SSL certificates ==== > > For SSL-based service protection (HTTPS, IMAPS, etc), a certificate with > dNSName extension records covering all system hostnames is required due to the > fact that both original (A/AAAA) and CNAME record names need to be in the > certificate. > > Currently FreeIPA only issues certificates to host objects presenting in > FreeIPA database. For the case when single sign-on is not required, it is > assumed that the host ''ipa-client.example.com'' is enrolled into FreeIPA realm. > > This means there is already a host object for ''ipa-client.example.com'' in > FreeIPA and Certmonger can already request for the certificate in its name: > > ipa-getcert request -r \ > -f /etc/httpd/alias/server.crt \ > -k /etc/httpd/alias/server.key \ > -N CN=`hostname --fqdn` \ > -D `hostname --fqdn` \ > -K host/ipa-client.example.com at IPA.EXAMPLE.COM \ > -U id-kp-serverAuth > This example allows to request an SSL certificate from FreeIPA CA to store it > in ''server.crt'' (public key) and ''server.key'' (private key) files. > > Certmonger uses default host key stored in ''/etc/krb5.keytab'' to authenticate > against FreeIPA CA. This means Kerberos authentication against > ''IPA.EXAMPLE.COM'' > realm should be properly working which is why ''ipa-client.example.com = > IPA.EXAMPLE.COM'' > was added to ''[domain_realm]'' mapping in ''/etc/krb5.conf'' above. > > === Single sign-on required === > > When single sign-on is required, moving FreeIPA client outside DNS zone > ''example.com'' is the pre-requisite. A CNAME record ''ipa-client.example.com'' > can then be created to point to the A/AAAA record of the FreeIPA client. E.g., > ''ipa-client.ipa.example.com''. > > For Kerberos-based application servers MIT Kerberos supports a method to allow > accept any host-based principal available in the application's keytab. When > Kerberos client would connect to a Kerberos application server, such server > typically does strict check on what Kerberos principal was used to target it > (so-called, 'acceptor check'). This can be relaxed: > > [libdefaults] > ignore_acceptor_hostname = true > > For OpenSSH server there is a specific option ''GSSAPIStrictAcceptorCheck no'' > to achieve the same. > > ==== Handling of SSL certificates ==== > > For SSL-based service protection (HTTPS, IMAPS, etc), a certificate with > dNSName extension records covering all system hostnames is required due to the > fact that both original (A/AAAA) and CNAME record names need to be in the > certificate. > > Currently FreeIPA only issues certificates to host objects presenting in > FreeIPA database. This means one would need to create host object for > ''ipa-client.example.com'' in FreeIPA and make sure the real FreeIPA machine's > host object is able to manage this host: > > ipa host-add ipa-client.example.com --force > ipa host-add-managedby ipa-client.example.com > --hosts=ipa-client.ipa.example.com > > We have to use ''--force'' option here because ''ipa-client.example.com'' is a > CNAME, not an A/AAAA DNS record as required by FreeIPA. > > With this setup ''ipa-client.ipa.example.com'' would be able to request an SSL > certificate with dNSName extension record for ''ipa-client.example.com''. > > ipa-getcert request -r \ > -f /etc/httpd/alias/server.crt \ > -k /etc/httpd/alias/server.key \ > -N CN=`hostname --fqdn` \ > -D `hostname --fqdn` \ > -D ipa-client.example.com \ > -K host/ipa-client.ipa.example.com at IPA.EXAMPLE.COM \ > -U id-kp-serverAuth Theory I have seen looks good to me but Security considerations section is missing. The design must spell out what are security implications of ignore_acceptor_hostname = true GSSAPIStrictAcceptorCheck no All of the implementation details are missing so this review cannot be considered complete. I'm very interested in implementation details & usability of it. Can we make this setup easier to achieve by changing ipa-client-install? Some ideas: - populate krb.conf only with [domain_realm] canonical hostname = IPA.EXAMPLE.COM and enable DNS auto-detection for everything else. I think that: a) For normal setups with disjoint domains this should just work as usual. b) For setup without CNAME for IPA client it should work because example.com will be detected as AD domain and scenario described in the section 'No single sign-on required' will work. c) For setup with CNAME the user will need to add ignore_acceptor_hostname but krb5.conf will be configured properly. BTW why is it needed to use ignore_acceptor_hostname if there is a CNAME? MIT Kerberos should see the correct name as it detects CNAMEs. Does AD ignore the CNAME when requesting a ticket? What else? If it is needed, can we detect the CNAME and turn on ignore_acceptor_hostname automatically? (This depends on security considerations section, of course.) Speaking of certs, should we introduce a aliases for host entries to avoid the need of fake hosts? -- Petr^2 Spacek From pspacek at redhat.com Fri May 20 10:12:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 12:12:20 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Incorrect message when KRA already installed In-Reply-To: References: Message-ID: <4f7aef64-e444-f81d-a22e-acbaa4a90b6e@redhat.com> On 17.5.2016 10:54, Patrice Duc-Jacquet wrote: > Hi everyone > > Please see attached candidate patch for ticket > > https://fedorahosted.org/freeipa/ticket/5315 ACK, please add link to the ticket to commit message before pushing. -- Petr^2 Spacek From pspacek at redhat.com Fri May 20 10:19:00 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 12:19:00 +0200 Subject: [Freeipa-devel] [PATCH 0104-0109] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> Message-ID: <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> On 11.5.2016 12:08, Martin Basti wrote: > > > On 03.05.2016 14:59, Petr Spacek wrote: >> Hello, >> >> DNS upgrade: change forwarding policy to "only" if private IPs are used. >> >> https://fedorahosted.org/freeipa/ticket/5710 >> >> This is the upgrade part. I will add one more patch to print a warning in >> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >> yet. >> >> >> > > 1) > Upgrade failed with 'BindInstance' object has no attribute > 'named_conf_get_directive' > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command > ipa-server-upgrade manually. > ('IPA upgrade failed.', 1) > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more > information > > 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no > attribute 'named_conf_get_directive' > 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line > 213, in __upgrade > self.modified = (ld.update(self.files) or self.modified) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 917, in update > self._run_updates(all_updates) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 889, in _run_updates > self._run_update_plugin(update['plugin']) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 862, in _run_update_plugin > restart_ds, updates = self.api.Updater[plugin_name]() > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1418, in > __call__ > return self.execute(**options) > File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", > line 547, in execute > self.update_global_named_conf_forwarder(bind) > File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", > line 508, in update_global_named_conf_forwarder > if bind.named_conf_get_directive( > AttributeError: 'BindInstance' object has no attribute 'named_conf_get_directive' > > 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 447, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 437, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line > 221, in __upgrade > raise RuntimeError(e) > RuntimeError: 'BindInstance' object has no attribute 'named_conf_get_directive' > > PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new attribute * > 2) > + Int('ipadnsversion?', > + label=_('IPA DNS version'), > + ), > > Shouldn't be this part of System: Read DNS Configuration permission? > > 3) > - def postprocess_result(self, result): > + def postprocess_result(self, result, show_version): > if not any(param in result['result'] for param in self.params): > result['summary'] = unicode(_('Global DNS configuration is empty')) > > show_version param was added but I don't see it used in this patch. > > 4) > + Int('ipadnsversion?', > + label=_('IPA DNS version'), > + ), > > Could we add comment here that this option is accessible only from installers > and upgrade? > > 5) > + for config_option in container_entry.get("ipaConfigString", []): > + matched = re.match("^DNSVersion\s+(?P\d+)$", > + config_option, flags=re.I) > + if matched: > + version = int(matched.group("version")) > > Shouldn't we print error if version cannot be parsed? > > PATCH * DNS upgrade: separate backup logic to make it reusable * > > LGTM > > PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * > > 7) > I'm curious why do you need to check superdomains? > > PATCH * DNS upgrade: change forwarding policy to = only for conflicting > forward zones* > > 8) > + self.log.debug('Zone %s was sucessfully modified to use ' > + 'forward policy "only"', zone['idnsname'][0]) > <---missing empty line----> > + def execute(self, **options): > > PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if > private IPs are used * > 9) > - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) > + dnsutil.related_to_auto_empty_zone( > + dnsutil.DNSName(zone.get('idnsname')[0])) > > Should be in previous commit > > 10) > - return > + return False, [] > This should be fixed in the previous commit > > PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" > if private IPs are used * > 11) > IMO this is an upgrade of configuration and this should be in > ipaserver/install/server/upgrade.py, upgrade plugins are used only for > updating of LDAP values > > Unless you really want to use this as precedence, but then it requires broader > discussion. > > 12) > > bind.named_conf_get_directive > should be > bindinstance.named_conf_get_directive > > see 1) This new patchset completely obsoletes the old one. I had to reshuffle few things to to make the split between server config & LDAP upgrade possible. Hopefully I addressed all your comment. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0113-Use-root_logger-for-verify_host_resolvable.patch Type: text/x-patch Size: 7354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0114-Move-IP-address-resolution-from-ipaserver.install.in.patch Type: text/x-patch Size: 7559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0115-Turn-verify_host_resolvable-into-a-wrapper-around-ip.patch Type: text/x-patch Size: 1936 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0116-Add-ipaDNSVersion-option-to-dnsconfig-commands-and-u.patch Type: text/x-patch Size: 16634 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0117-DNS-upgrade-separate-backup-logic-to-make-it-reusabl.patch Type: text/x-patch Size: 9393 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0118-Add-function-ipapython.dnsutil.related_to_auto_empty.patch Type: text/x-patch Size: 1859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0119-DNS-upgrade-change-forwarding-policy-to-only-for-con.patch Type: text/x-patch Size: 6202 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0120-DNS-upgrade-change-global-forwarding-policy-in-LDAP-.patch Type: text/x-patch Size: 3321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0121-DNS-upgrade-change-global-forwarding-policy-in-named.patch Type: text/x-patch Size: 5852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0122-DNS-Warn-if-forwarding-policy-conflicts-with-automat.patch Type: text/x-patch Size: 4964 bytes Desc: not available URL: From pspacek at redhat.com Fri May 20 10:30:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 12:30:50 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> Message-ID: <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> On 18.5.2016 12:43, Martin Basti wrote: > > > On 12.05.2016 16:16, Martin Basti wrote: >> >> >> >> On 12.05.2016 11:01, Martin Basti wrote: >>> >>> >>> On 11.05.2016 09:41, Martin Basti wrote: >>>> >>>> >>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>> >>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>> >>>>>>>>>>> Patches attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>> From: Martin Basti >>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>>>>> privileges >>>>>>>>>>> >>>>>>>>>>> DNS privileges are important for handling DNS locations which can be >>>>>>>>>>> created without DNS servers in IPA topology. We will also need this >>>>>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>> From: Martin Basti >>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>> objectclasses >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>> --- >>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>> >>>>>>>>>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>>>>>>>>> index >>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>> booleanMatch >>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' >>>>>>>>>>> DESC 'dns >>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ >>>>>>>>>>> a6Record $ >>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>>>> mXRecord $ >>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ >>>>>>>>>>> KeyRecord >>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ >>>>>>>>>>> dNameRecord >>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC >>>>>>>>>>> 'Zone >>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>> idnsForwarders $ >>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' >>>>>>>>>>> SUP top >>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' >>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName >>>>>>>>>>> ) MAY ( >>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there >>>>>>>>>> will not be >>>>>>>>>> any other object class on the location object (at least not in the >>>>>>>>>> beginning). >>>>>>>>>> >>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>> From: Martin Basti >>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>> >>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>>>>>>> prototypes and does not provide any information about server (will be >>>>>>>>>>> done later) >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>> --- >>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>> API.txt | 59 ++++++++++++++ >>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>> index >>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/VERSION >>>>>>>>>>> +++ b/VERSION >>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>> # # >>>>>>>>>>> ######################################################## >>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>> Needs rebase. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>> index >>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>> objectClass: top >>>>>>>>>>> cn: etc >>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>> +changetype: add >>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>> +objectClass: top >>>>>>>>>>> +cn: locations >>>>>>>>>>> + >>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>> changetype: add >>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>> index >>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>> +default: objectClass: top >>>>>>>>>>> +default: cn: locations >>>>>>>>>> Ok. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>>>>>>>>> index >>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>> [...] >>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>> +IPA locations >>>>>>>>>>> +""") + _(""" >>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> + at register() >>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>> + """ >>>>>>>>>>> + IPA locations >>>>>>>>>>> + """ >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>> + managed_permissions = { >>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>> + }, >>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>> + }, >>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>> + }, >>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>> + }, >>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>> + 'description', >>>>>>>>>>> + }, >>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>> + }, >>>>>>>>>>> + } >>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but IMHO >>>>>>>>>> this is >>>>>>>>>> okay. >>>>>>>>>> Less renames we support the better. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> + >>>>>>>>>>> + takes_params = ( >>>>>>>>>>> + DNSNameParam( >>>>>>>>>>> + 'idnsname', >>>>>>>>>>> + cli_name='name', >>>>>>>>>>> + primary_key=True, >>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>> + # dns name must be relative, we will put it into >>>>>>>>>>> middle of >>>>>>>>>>> + # location domain name for location records >>>>>>>>>>> + only_relative=True, >>>>>>>>>>> + ), >>>>>>>>>> Okay. We need to make sure that relative names with multiple labels >>>>>>>>>> work - >>>>>>>>>> but >>>>>>>>>> this should automagically work as long as we are handling DNS names >>>>>>>>>> using >>>>>>>>>> proper data types (not as strings). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> + Str( >>>>>>>>>>> + 'description?', >>>>>>>>>>> + label=_('Description'), >>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>> + ), >>>>>>>>>> After discussion with Honza we will keep description as single-value >>>>>>>>>> in the >>>>>>>>>> IPA framework and ignore that description attribute is multi-value >>>>>>>>>> in LDAP. >>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> + at register() >>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>>>>> This should say 'Modify description' because nothing else can be >>>>>>>>>> modified. >>>>>>>>>> More specific text would hopefully stop some people from looking for >>>>>>>>>> rename >>>>>>>>>> options. >>>>>>>>> I disagree, this is general description about the modify command, see >>>>>>>>> privilege-add it is the same as I made. I can see in future that we will >>>>>>>>> forgot to update description of command if we add something new there. >>>>>>>> This is really an invalid argument. >>>>>>>> >>>>>>>> "We must not touch XYZ because its documentation might become obsolete in >>>>>>>> future if we forget to update it!" :-) >>>>>>>> >>>>>>> How about inconsistency with description of older commands? I don't >>>>>>> think that >>>>>>> command description should describe attributes that are allowed to change. >>>>>>> Allowed attributes are shown in --help output >>>>>> I do not agree but push whatever variant you like, it costed too much >>>>>> already. >>>>> NACK anyway. ipa-dns-install screams if you install a server without DNS and >>>>> run ipa-dns-install later on: >>>>> >>>>> The log contains this: >>>>> >>>>> add objectClass: >>>>> top >>>>> groupofnames >>>>> nestedgroup >>>>> add cn: >>>>> DNS Administrators >>>>> add description: >>>>> DNS Administrators >>>>> adding new entry "cn=DNS >>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>> >>>>> >>>>> >>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>> >>>>> ) >>>>> SASL/EXTERNAL authentication started >>>>> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>> SASL SSF: 0 >>>>> ldap_add: Already exists (68) >>>>> >>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket -Y >>>>> >>>>> EXTERNAL' returned non-zero exit status 68 >>>>> >>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>> >>> >>> Updated patches attached >>> >>> I found that IDNA did not work with previous version, fixed + IDNA tests added >>> >>> >> Fixed here, I sent wrong patches before >> >> >> >> > > More patches added, all patches are available here: > https://github.com/bastiak/freeipa/tree/DNS-locations Functional NACK location-show returns incorrect location weight for servers # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all dn: cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com Server name: vm-046.abc.idm.lab.eng.brq.redhat.com Managed suffixes: domain Min domain level: 0 Max domain level: 1 Location: l2 Location weight: 200 objectclass: ipalocationmember, ipaReplTopoManagedServer, top, ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig # ipa location-show l2 Location name: l2 Description: Loc 2 Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) - Did you forget --all somewhere? Other than that I have only nitpick regarding error message: ipa: ERROR: l2 cannot be deleted because IPA Server(s) vm-046.abc.idm.lab.eng.brq.redhat.com requires it - Please unify singular/plural. I did not require the code because Honza will surely look into details. -- Petr^2 Spacek From pspacek at redhat.com Fri May 20 10:32:40 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 12:32:40 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <16cdb8b8-bb50-c633-2eef-326d7367f40c@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> <16cdb8b8-bb50-c633-2eef-326d7367f40c@redhat.com> Message-ID: <5fe327e1-7c8e-7132-2da0-7f78cb60d350@redhat.com> On 12.5.2016 16:17, Petr Spacek wrote: > On 28.4.2016 17:15, Petr Spacek wrote: >> On 28.4.2016 14:52, Abhijeet Kasurde wrote: >>> Hi Petr, >>> >>> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> ipa-nis-manage: add status option >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>>> >>>> >>>> >>> Can you reword the error message here as well ? >>> >>> if len(args) != 1: >>> sys.exit("You must specify one action, either enable or disable") >>> >>> Thanks, >>> Abhijeet Kasurde >> >> Good catch! > > Please review this, thanks. Ping, please review it. -- Petr^2 Spacek From abokovoy at redhat.com Fri May 20 10:43:34 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 May 2016 13:43:34 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> Message-ID: <20160520104334.cbzj2nc52lvm6sfn@redhat.com> On Fri, 20 May 2016, Petr Spacek wrote: >Theory I have seen looks good to me but Security considerations section is >missing. The design must spell out what are security implications of > ignore_acceptor_hostname = true > GSSAPIStrictAcceptorCheck no I'll add security considerations, thanks for noticing that. >All of the implementation details are missing so this review cannot be >considered complete. There is nothing to implement here on our side. We discussed it with Martin K. and he suggested that we might add a link to documentation when it would be written but that's as much as we can do. Thing is, a proper implementation means changes to be done way above ipa-client-install level, even way above FreeIPA deployment itself, especially for SSO case where a CNAME would need to be created in a separate DNS zone that is not under control of FreeIPA. So all we can do is to suggest something rather than implement. We do that already and Mark is going to turn the design into a section in the Windows Integration Guide. >I'm very interested in implementation details & usability of it. Can we make >this setup easier to achieve by changing ipa-client-install? > >Some ideas: >- populate krb.conf only with >[domain_realm] >canonical hostname = IPA.EXAMPLE.COM > >and enable DNS auto-detection for everything else. We already have auto-detection working. For non-SSO case 'ipa-client-install --domain=ipa.example.com' on ipa-client.example.com will automatically configure everything. The only change is indeed by setting 'ipa-client.example.com = IPA.EXAMPLE.COM'. For SSO case we simply discover that AD DC is not IPA LDAP server so we refuse to operate unless you provide manual options. However, it is impossible to do anything here automatically because the actual behavior would depend on external conditions which we cannot control. This is really something that has to be written in the planning guide. For example, if you have SSO case and want to put A/AAAA record and CNAME record, it is not a given fact that both of them have to be named in the same way. In fact, they most likely will be different as CNAME record is part of user-facing application namespace and A/AAAA records in IPA DNS zone are part of a backend naming. There is no standardization here. >I think that: >a) For normal setups with disjoint domains this should just work as usual. > >b) For setup without CNAME for IPA client it should work because example.com >will be detected as AD domain and scenario described in the section 'No single >sign-on required' will work. > >c) For setup with CNAME the user will need to add ignore_acceptor_hostname but >krb5.conf will be configured properly. > > > >BTW why is it needed to use ignore_acceptor_hostname if there is a CNAME? MIT >Kerberos should see the correct name as it detects CNAMEs. Does AD ignore the >CNAME when requesting a ticket? What else? No, it does not ignore, it resolves CNAME to A/AAAA name. However, there are cases when people want to have both principals from IPA and AD realms in /etc/krb5.keytab and want to support both ways to access it. >If it is needed, can we detect the CNAME and turn on ignore_acceptor_hostname >automatically? (This depends on security considerations section, of course.) Exactly because it is part of the behavior defined by application frontend considerations, we can only document it and not do automated handling. >Speaking of certs, should we introduce a aliases for host entries to avoid the >need of fake hosts? These 'fake hosts' are as good as aliases, even better, because they allow us to have full control over who can manage them. -- / Alexander Bokovoy From akasurde at redhat.com Fri May 20 10:45:20 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 20 May 2016 16:15:20 +0530 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <5fe327e1-7c8e-7132-2da0-7f78cb60d350@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> <16cdb8b8-bb50-c633-2eef-326d7367f40c@redhat.com> <5fe327e1-7c8e-7132-2da0-7f78cb60d350@redhat.com> Message-ID: <573EEAC0.7070306@redhat.com> On 05/20/2016 04:02 PM, Petr Spacek wrote: > On 12.5.2016 16:17, Petr Spacek wrote: >> On 28.4.2016 17:15, Petr Spacek wrote: >>> On 28.4.2016 14:52, Abhijeet Kasurde wrote: >>>> Hi Petr, >>>> >>>> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> ipa-nis-manage: add status option >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>>>> >>>>> >>>>> >>>> Can you reword the error message here as well ? >>>> >>>> if len(args) != 1: >>>> sys.exit("You must specify one action, either enable or disable") >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>> Good catch! >> Please review this, thanks. > Ping, please review it. > LGTM. But someone else should approve it. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io From frenaud at redhat.com Fri May 20 10:52:01 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Fri, 20 May 2016 12:52:01 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Add missing CA options to the manpage for ipa-replica-install Message-ID: Hi all, this one will be my first patch submission, so apologies in advance if I make mistakes... The man page for ipa-replica-install was missing some commands related to CA-less installation, as well as --allow-zone-overlap and --auto-reverse. I added them in the relevant sections (CERTIFICATE SYSTEM OPTIONS and DNS OPTIONS). I also fixed a wrong short option for --realm (-r). Fixes: https://fedorahosted.org/freeipa/ticket/5835 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0001-Add-missing-CA-options-to-the-manpage-for-ipa-replica-install.patch Type: text/x-patch Size: 2744 bytes Desc: not available URL: From pvomacka at redhat.com Fri May 20 11:17:30 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 20 May 2016 13:17:30 +0200 Subject: [Freeipa-devel] [PATCH] 0035: webui: change Restore cert to Remove cert hold Message-ID: Hi, please review attached patch. It change Restore certificate strings to Remove certificate hold to be consistent with CLI. https://fedorahosted.org/freeipa/ticket/5878 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0035-Change-Restore-to-Remove-Hold.patch Type: text/x-patch Size: 10368 bytes Desc: not available URL: From akasurde at redhat.com Fri May 20 11:21:37 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 20 May 2016 16:51:37 +0530 Subject: [Freeipa-devel] [PATCH 0013] Updated ipa-server-install man page for domain-level attribute In-Reply-To: <7f70763e-c89f-fe30-7cb7-ba1c155094cc@redhat.com> References: <572C2C9A.5030000@redhat.com> <7f70763e-c89f-fe30-7cb7-ba1c155094cc@redhat.com> Message-ID: <573EF341.8030201@redhat.com> Hi All, Please find the patch for review. On 05/09/2016 01:28 PM, Petr Spacek wrote: > On 6.5.2016 07:33, Abhijeet Kasurde wrote: >> Please review this patch. > Good catch! > > In general, I believe that man page should explain what domain level means > (probably with an example of levels 0 and 1) so the user can actually use the > man page to find out what value is needed for his purposes. > > Considering this, I have to NACK this patch. Please elaborate. > > Thank you! > -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0013-1-Updated-ipa-server-install-man-page-for-domain-level-ipa-4-3.patch Type: text/x-patch Size: 1944 bytes Desc: not available URL: From pspacek at redhat.com Fri May 20 11:56:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 May 2016 13:56:34 +0200 Subject: [Freeipa-devel] [PATCH 0013] Updated ipa-server-install man page for domain-level attribute In-Reply-To: <573EF341.8030201@redhat.com> References: <572C2C9A.5030000@redhat.com> <7f70763e-c89f-fe30-7cb7-ba1c155094cc@redhat.com> <573EF341.8030201@redhat.com> Message-ID: <3abc892d-35e5-0798-55f1-05b122ab7809@redhat.com> On 20.5.2016 13:21, Abhijeet Kasurde wrote: > Hi All, > > Please find the patch for review. > > On 05/09/2016 01:28 PM, Petr Spacek wrote: >> On 6.5.2016 07:33, Abhijeet Kasurde wrote: >>> Please review this patch. >> Good catch! >> >> In general, I believe that man page should explain what domain level means >> (probably with an example of levels 0 and 1) so the user can actually use the >> man page to find out what value is needed for his purposes. >> >> Considering this, I have to NACK this patch. Please elaborate. >> >> Thank you! >> > > -- > Thanks, > Abhijeet Kasurde > > IRC: akasurde > http://akasurde.github.io > > > freeipa-akasurde-0013-1-Updated-ipa-server-install-man-page-for-domain-level-ipa-4-3.patch > > > From e32e9a1b5b1d666d53c575a27beb8dadd09e26cc Mon Sep 17 00:00:00 2001 > From: Abhijeet Kasurde > Date: Fri, 20 May 2016 16:45:40 +0530 > Subject: [PATCH] Updated ipa-server-install man page for domain-level > attribute > > Fixes: https://fedorahosted.org/freeipa/ticket/5708 > > Signed-off-by: Abhijeet Kasurde > --- > install/tools/man/ipa-server-install.1 | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/install/tools/man/ipa-server-install.1 b/install/tools/man/ipa-server-install.1 > index 55b49449e3c44aebfeefe5cb71d73e9abf07c5b2..7638726c306ed64706c33564f1ca175197e7a7bf 100644 > --- a/install/tools/man/ipa-server-install.1 > +++ b/install/tools/man/ipa-server-install.1 > @@ -1,5 +1,5 @@ > .\" A man page for ipa-server-install > -.\" Copyright (C) 2008 Red Hat, Inc. > +.\" Copyright (C) 2008-2016 Red Hat, Inc. > .\" > .\" This program is free software; you can redistribute it and/or modify > .\" it under the terms of the GNU General Public License as published by > @@ -16,7 +16,7 @@ > .\" > .\" Author: Rob Crittenden > .\" > -.TH "ipa-server-install" "1" "Jun 28 2012" "FreeIPA" "FreeIPA Manual Pages" > +.TH "ipa-server-install" "1" "May 20 2016" "FreeIPA" "FreeIPA Manual Pages" > .SH "NAME" > ipa\-server\-install \- Configure an IPA server > .SH "SYNOPSIS" > @@ -84,6 +84,9 @@ An unattended installation that will never prompt for user input > .TP > \fB\-\-dirsrv\-config\-file\fR > The path to LDIF file that will be used to modify configuration of dse.ldif during installation of the directory server instance > +.TP > +\fB\-\-domain\-level\fR > +Specifies IPA domain level value. Domain level indicates that server is capable of doing certain operations. Domain level 1 means that it supports replica promotion and topology management. Old IPA servers and IPA servers upgraded to 4.3 in existing environments have domain level 0. > > .SS "CERTIFICATE SYSTEM OPTIONS" > .TP > -- 2.4.11 > Thanks but NACK. Domain level is not about one server. It defines that all servers in one IPA topology behave in some particular way. -- Petr^2 Spacek From mbabinsk at redhat.com Fri May 20 12:29:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 May 2016 14:29:53 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> Message-ID: <16f8ee5e-46ce-c2ef-8d1b-465cfab65869@redhat.com> On 05/16/2016 01:58 PM, David Kupka wrote: > On 26/04/16 10:09, David Kupka wrote: >> On 14/03/16 14:01, Martin Basti wrote: >>> >>> >>> On 14.03.2016 13:46, Martin Babinsky wrote: >>>> On 03/11/2016 09:16 AM, David Kupka wrote: >>>>> Current version (0.5.0) of python-augeas is missing copy() method. Use >>>>> dkupka/python-augeas copr repo before new version it's build and >>>>> available in the official repos. >>>>> >>>>> >>>>> >>>> Hi David, >>>> >>>> TLDR: NACK :D. >>>> >>>> Here are high-level remarks to discuss: >>>> >>>> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >>>> ipaplatform since it is dealing with (sorta) platform specific >>>> behavior (ntp vs. chrony vs. whatever we will have for timesync in the >>>> future). CC'ing Jan for thoughts. >>>> >>>> Also regarding patches 0096-0097, we could have platform specific >>>> TimeDateService object that could wrap NTP/chrony management. for >>>> example, the task namespace functions in Pathc 0096 could be >>>> reimplemented as a methods of the service (RedhatTimeDateService, >>>> FedoraTimeDateService etc.) and then called in a platform-agnostic >>>> manner. >>>> >>>> Here are some comments regarding code: >>>> >>>> Patch 0095: >>>> >>>> 1.) >>>> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >>>> >>>> Do not forget to add this directory to %install and %files spection of >>>> the spec file so that it is correctly added to RPM build. >>>> >>>> 2.) >>>> >>>> please separate import of system-wide and IPA-specific modules by >>>> blank line >>>> >>>> +import collections >>>> +from augeas import Augeas >>>> +from ipaplatform.paths import paths >>>> +from ipapython.ipa_log_manager import root_logger >>>> >>>> 3.) the call to parent's __new__ should have signature 'super(aug_obj, >>>> cls).__new__(*args, **kwargs)' >>>> >>>> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >>>> **kwargs) >>>> >>>> 4.) >>>> >>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>> add more' >>>> + 'lenses.') >>>> >>>> Should be 'Augeas lenses _were_ loaded' >>>> >>>> 5.) >>>> >>>> + if lens in self.lenses: >>>> + raise RuntimeError('Lens %s already added.' % lens) >>>> + self.lenses.append(lens) >>>> + load_path = '/augeas/load/{0}'.format(lens >>>> >>>> >>>> Shouldn't the following code use os.path,join to construct the >>>> load_path? >>>> >>>> 6.) I would prefer the following indentation style in the add_lens() >>>> method >>>> >>>> @@ -65,9 +65,9 @@ class aug_obj(object): >>>> for conf_file in conf_files: >>>> self._aug.set(os.path.join(load_path, 'incl[0]'), >>>> conf_file) >>>> self.tree['old'] = self.tree.get(conf_file, None) >>>> - self.tree[conf_file] = aug_node(self._aug, >>>> - os.path.join('/files', >>>> - conf_file[1:])) >>>> + self.tree[conf_file] = aug_node( >>>> + self._aug, os.path.join('/files', conf_file[1:]) >>>> + ) >>>> >>>> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >>>> 'files', and '//error' would be made into either module variables or >>>> class members. >>>> >>>> 8.) >>>> >>>> + def load(self): >>>> + if self._loaded: >>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>> add more' >>>> + 'lenses.') >>>> >>>> Fix the excpetion text in the same way as in 4.) >>>> >>>> 9.) >>>> >>>> + errors = self._aug.match(os.path.join('//error')) >>>> >>>> is the os.path.join necessary here? >>>> >>>> 10.) I guess you can rewrite the error message in load() method using >>>> list comprehension: >>>> >>>> @@ -76,9 +76,9 @@ class aug_obj(object): >>>> self._aug.load() >>>> errors = self._aug.match(os.path.join('//error')) >>>> if errors: >>>> - err_msg = "" >>>> - for error in errors: >>>> - err_msg += ("{}: {}".format(error, >>>> self._aug.get(error))) >>>> + err_msg = '\n'.join( >>>> + ["{}: {}".format(e, self._aug.get(e)) for e in errors] >>>> + ) >>>> raise RuntimeError(err_msg) >>>> self._loaded = True >>>> >>>> 11.) >>>> >>>> +class aug_node(collections.MutableMapping): >>>> + """ Single augeas node. >>>> + Can be handled as python dict(). >>>> + """ >>>> + def __init__(self, aug, path): >>>> + self._aug = aug >>>> + if path and os.path.isabs(path): >>>> + self._path = path >>>> + else: >>>> + self._tmp = _tmp_path(aug, path) >>>> + self._path = self._tmp.path >>>> >>>> Isn't it better to change signature of __init__ to: >>>> >>>> def __init__(self, aug, path=None): >>>> >>>> and then test whether path is None? >>>> >>>> 12.) >>>> >>>> def __setitem__(self, key, node): >>>> + target = os.path.join(self._path, key) >>>> + end = '{0}[0]'.format(os.path.join(self._path, key)) >>>> + if self._aug.match(target): >>>> + self._aug.remove(target) >>>> + target_list = aug_list(self._aug, target) >>>> + for src_node in aug_list(node._aug, node._path): >>>> + target_list.append(src_node) >>>> >>>> The 'end' variable is declared but not used. >>>> >>>> 13.) >>>> >>>> + >>>> + def __len__(self): >>>> + return len(self._aug.match('{0}/*'.format(self._path))) >>>> + >>>> + def __iter__(self): >>>> + for key in self._aug.match('{0}/*'.format(self._path)): >>>> + yield self._aug.label(key) >>>> + raise StopIteration() >>>> + >>>> >>>> Shouldn't we construct paths using os.path.join for the sake of >>>> consistency? >>>> >>>> 14.) >>>> >>>> + def __bool__(self): >>>> + return (bool(len(self)) or bool(self.value)) >>>> >>>> The parentheses around the boolean expression are not needed >>>> >>>> 15.) >>>> >>>> +class aug_list(collections.MutableSequence): >>>> + """Augeas NODESET. >>>> + Can be handled as a list(). >>>> + """ >>>> + def __init__(self, aug, path): >>>> + self._aug = aug >>>> + if path and os.path.isabs(path): >>>> + self._path = path >>>> + else: >>>> + self._tmp = _tmp_path(aug, path) >>>> + self._path = self._tmp.path >>>> >>>> I would use 'path=None' int he signature and then test whether 'path >>>> is not None'. >>>> >>>> 16.) >>>> >>>> + if not self._aug.match(target): >>>> + raise IndexError() >>>> >>>> It would be nice if you could put some basic error message into the >>>> raised exceptions, like "node index out of range" or something like >>>> that >>>> >>>> 17.) >>>> >>>> + elif isinstance(index, slice): >>>> + label = self._path.split('/')[-1] >>>> >>>> you could use os.path.basename() to get the leaf node. >>>> >>>> >>>> 18.) >>>> >>>> + replace = range_target[:len(node)] >>>> + delete = create = [] >>>> >>>> Be careful here as you create two references to the same empty list >>>> object, which is probably not what you wanted. >>>> >>>> 19.) >>>> + try: >>>> + create_start = range_target[-1]+1 >>>> + except IndexError: >>>> + create_start = self._idx_pos(index.start) >>>> + create_stop = create_start+len(node)-len(replace) >>>> + create = list(range(create_start, create_stop)) >>>> >>>> Please respect PEP8 and put spaces around arithmetic operators in >>>> assignments. >>>> >>>> Also it would be nice to have at least a minimal test suite for this >>>> module, but that may be a separate ticket. >>>> >>>> patch 0096: >>>> >>>> 1.) please fix the commit message >>>> 2.) please use new-style license header in ipapython/ntp.py >>>> 3.) >>>> >>>> + return ("Conflicting Time&Date synchroniztion service '%s' >>>> is " >>>> + "currently enabled and/or running on the system." >>>> + % self.conflicting_service) >>>> >>>> Please fix the typo in the error message. >>>> >>>> 4.) >>>> + service = services.service(self.service_name) >>>> + if sstore: >>>> + if sstore.get_state('ntp', 'enabled') is None: >>>> + sstore.backup_state('ntp', 'enabled', >>>> service.is_enabled()) >>>> + >>>> + if fstore: >>>> + if not fstore.has_file(self.conf_file): >>>> + fstore.backup_file(self.conf_file) >>>> >>>> the conditions in the 'if' statement can be merged into single AND >>>> expression >>>> >>>> 5.) >>>> + self._store_service_state(sstore, fstore) >>>> + if sstore: >>>> + sstore.backup_state('ntp', "enabled", >>>> service.is_enabled()) >>>> + >>>> + if fstore: >>>> + fstore.backup_file(self.conf_file) >>>> >>>> I think these checks are redundant here. >>>> >>>> 6.) >>>> + # In such case it is OK to fail >>>> + try: >>>> + restored = fstore.restore_file(self.conf_file) >>>> + except Exception: >>>> + pass >>>> >>>> Instead of 'pass' it would be better to set restored to False so that >>>> you don't hit NameError later. >>>> >>>> 7.) >>>> + >>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>> fstore=None): >>>> + self.server_options['burst'] = None >>>> + self.server_options['iburst'] = None >>>> >>>> I would rather set these instance variables in __init__() than here. >>>> >>>> 8.) >>>> >>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>> fstore=None): >>>> + self.conf_file = paths.CHRONY_CONF >>>> self.conf_file is already defined in constructor. >>>> >>>> 9.) >>>> >>>> + self.server_options['iburst'] = None >>>> this should be moved to __init__() >>>> >>>> 10.) >>>> + with ipaaugeas.aug_obj() as aug: >>>> + try: >>>> + aug.add_lens(self.lens, [self.conf_file]) >>>> + aug.load() >>>> + except RuntimeError as e: >>>> + raise NTPConfigurationError(e) >>>> >>>> This code is repeated quite a few times, maybe it would be a good idea >>>> to factor it out to a method of NTPService object. >>>> >>>> >>>> Patch 0097: >>>> >>>> 1.) please fix a typo here: >>>> >>>> + description="Disble any other Time synchronization services." >>>> >>>> 2.) >>>> >>>> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >>>> you have 2 spaces before 'ntpinstance' >>>> >>> >>> I'm adding my nitpicks too :) >>> >>> 1) >>> +#!/usr/bin/python >>> >>> This should not be in modules, only in executable files >>> >>> 2) >>> Missing license in ipaaugeas.py >>> >>> Martin^2 >> >> Hello, >> after offline discussion with Honza I've rewritten the augeas wrapper >> and modified ipautil/ntp.py accordingly. The rest should be pretty much >> the same. >> Patches attached. >> > Rebased and added minimal test suite. > Hi David, patch 0095: I second Petr's opinion, at least some short examples of fetching and modifying configuration values for .e.g /etc/hosts would be welcome. Also there is some leftover comment in the Element.__setitem__: # self.aug.copy(value.path, self(loc).path) copy(self.aug, value.path, self(loc).path) patch 0096: 1.) + def __init__(self): + self.service_name = '' + self.conf_file = '' + self.lens = '' + self.source_keywords = ['server'] + self.server_options = {} + self.global_options = {} I would rather rewrite this as a proper __init__ method with parameters: def __init__(self, service_name = '', self.conf_file = '', ...) This is clearer for me than calling empty __init__() of superclass and then setting instance attributes separately. Also the self.lens attribute seems to be unused (leftover from previous revisions?) 2.) + + def configure_client(self, ntp_servers=[], sstore=None, fstore=None): + service = services.service(self.service_name) + + self._store_service_state(sstore, fstore) Use 'ntp_servers=()' so that there is one less case of pylint complaining about using mutable object as default when we switch on this check in the future ;). 3.) I would not turn "check_services" into instance method since it does not use instance variable at all. I would rather turn this into normal module-level function as was before and name it to 'check_conflicting_timedate_services' or something like that. In this way you wouldn't have to instantiate the whole class just to check whether there is a conflict between ntpd/chrony/whatever. The same could be argued about 'force' and 'restore_forced' methods. 4.) + +class Ntp(NTPService): + according to pep8 style guide[1]: """ Note: When using abbreviations in CapWords, capitalize all the letters of the abbreviation. Thus HTTPServerError is better than HttpServerError. """ so name the class NTP please. 5.) "NTP" and "Chrony" do not need to override parent's 'configure_client' method since the overriden one only calls super-method anyway. Patch 0097 Double-check that you are not creating cyclic imports ipapython->ipaplatform. And please import only ipapython.ntp, not the whole package. Patch 0098 1.) + tasks.ntp_check_conflict(options.force_ntp) + except ntp.NTPConflictingService as e: + print(e) I know that this is ipa-client-install and people expect it to print errors into stdout, but it would be nice to also put the error into logger at warning level so that there is a trace of it in the logs in case of trouble. The same can be said about the check for conflicting NTP services in 'ipa-server/replica-install'. Patch 101 Yay test and it even passes! It would be nice to have there some negative test cases but that can be extended by ^QE later. [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles -- Martin^3 Babinsky From mbasti at redhat.com Fri May 20 12:40:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 14:40:22 +0200 Subject: [Freeipa-devel] [PATCH 0112] pylint: replace Refactor category with individual check name In-Reply-To: References: Message-ID: On 20.05.2016 10:26, Petr Spacek wrote: > On 19.5.2016 14:47, Martin Basti wrote: >> On 19.05.2016 14:26, Petr Spacek wrote: >>> Hello, >>> >>> pylint: replace Refactor category with individual check names >>> >>> This eases enabling/disabling individual tests like cyclic-import. >>> >> I like this patch but, NACK >> >> ......... >> ************* Module ipalib.config >> ipalib/config.py:260: [R0204(redefined-variable-type), Env.__setitem__] >> Redefinition of value type from int to ipapython.dn.DN) >> ipalib/config.py:458: [R0102(simplifiable-if-statement), Env._bootstrap] The >> if statement can be replaced with 'var = bool(test)') >> ************* Module ipalib.messages >> ipalib/messages.py:90: [R0204(redefined-variable-type), >> process_message_arguments] Redefinition of obj.strerror type from unicode to str) >> ************* Module ipalib.plugable >> ipalib/plugable.py:569: [R0204(redefined-variable-type), API.import_plugins] >> Redefinition of modules type from generator to list) >> ************* Module ipalib.rpc >> ipalib/rpc.py:609: [R0101(too-many-nested-blocks), >> KerbTransport.single_request] Too many nested blocks (6/5)) >> ipalib/rpc.py:753: [R0204(redefined-variable-type), RPCClient.get_url_list] >> Redefinition of answers type from dns.resolver.Answer to list) >> ........ >> >> >> tested with pylint-1.5.5-1.fc24.noarch > Here it is. > ACK Pushed to master: 6e4b749b59ebae82c613fe799dda7cb21dc080cd I'm looking forward to enabling any of that checks :) From mbabinsk at redhat.com Fri May 20 12:54:42 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 May 2016 14:54:42 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <16f8ee5e-46ce-c2ef-8d1b-465cfab65869@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> <16f8ee5e-46ce-c2ef-8d1b-465cfab65869@redhat.com> Message-ID: On 05/20/2016 02:29 PM, Martin Babinsky wrote: > On 05/16/2016 01:58 PM, David Kupka wrote: >> On 26/04/16 10:09, David Kupka wrote: >>> On 14/03/16 14:01, Martin Basti wrote: >>>> >>>> >>>> On 14.03.2016 13:46, Martin Babinsky wrote: >>>>> On 03/11/2016 09:16 AM, David Kupka wrote: >>>>>> Current version (0.5.0) of python-augeas is missing copy() method. >>>>>> Use >>>>>> dkupka/python-augeas copr repo before new version it's build and >>>>>> available in the official repos. >>>>>> >>>>>> >>>>>> >>>>> Hi David, >>>>> >>>>> TLDR: NACK :D. >>>>> >>>>> Here are high-level remarks to discuss: >>>>> >>>>> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >>>>> ipaplatform since it is dealing with (sorta) platform specific >>>>> behavior (ntp vs. chrony vs. whatever we will have for timesync in the >>>>> future). CC'ing Jan for thoughts. >>>>> >>>>> Also regarding patches 0096-0097, we could have platform specific >>>>> TimeDateService object that could wrap NTP/chrony management. for >>>>> example, the task namespace functions in Pathc 0096 could be >>>>> reimplemented as a methods of the service (RedhatTimeDateService, >>>>> FedoraTimeDateService etc.) and then called in a platform-agnostic >>>>> manner. >>>>> >>>>> Here are some comments regarding code: >>>>> >>>>> Patch 0095: >>>>> >>>>> 1.) >>>>> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >>>>> >>>>> Do not forget to add this directory to %install and %files spection of >>>>> the spec file so that it is correctly added to RPM build. >>>>> >>>>> 2.) >>>>> >>>>> please separate import of system-wide and IPA-specific modules by >>>>> blank line >>>>> >>>>> +import collections >>>>> +from augeas import Augeas >>>>> +from ipaplatform.paths import paths >>>>> +from ipapython.ipa_log_manager import root_logger >>>>> >>>>> 3.) the call to parent's __new__ should have signature 'super(aug_obj, >>>>> cls).__new__(*args, **kwargs)' >>>>> >>>>> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >>>>> **kwargs) >>>>> >>>>> 4.) >>>>> >>>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>>> add more' >>>>> + 'lenses.') >>>>> >>>>> Should be 'Augeas lenses _were_ loaded' >>>>> >>>>> 5.) >>>>> >>>>> + if lens in self.lenses: >>>>> + raise RuntimeError('Lens %s already added.' % lens) >>>>> + self.lenses.append(lens) >>>>> + load_path = '/augeas/load/{0}'.format(lens >>>>> >>>>> >>>>> Shouldn't the following code use os.path,join to construct the >>>>> load_path? >>>>> >>>>> 6.) I would prefer the following indentation style in the add_lens() >>>>> method >>>>> >>>>> @@ -65,9 +65,9 @@ class aug_obj(object): >>>>> for conf_file in conf_files: >>>>> self._aug.set(os.path.join(load_path, 'incl[0]'), >>>>> conf_file) >>>>> self.tree['old'] = self.tree.get(conf_file, None) >>>>> - self.tree[conf_file] = aug_node(self._aug, >>>>> - os.path.join('/files', >>>>> - conf_file[1:])) >>>>> + self.tree[conf_file] = aug_node( >>>>> + self._aug, os.path.join('/files', conf_file[1:]) >>>>> + ) >>>>> >>>>> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >>>>> 'files', and '//error' would be made into either module variables or >>>>> class members. >>>>> >>>>> 8.) >>>>> >>>>> + def load(self): >>>>> + if self._loaded: >>>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>>> add more' >>>>> + 'lenses.') >>>>> >>>>> Fix the excpetion text in the same way as in 4.) >>>>> >>>>> 9.) >>>>> >>>>> + errors = self._aug.match(os.path.join('//error')) >>>>> >>>>> is the os.path.join necessary here? >>>>> >>>>> 10.) I guess you can rewrite the error message in load() method using >>>>> list comprehension: >>>>> >>>>> @@ -76,9 +76,9 @@ class aug_obj(object): >>>>> self._aug.load() >>>>> errors = self._aug.match(os.path.join('//error')) >>>>> if errors: >>>>> - err_msg = "" >>>>> - for error in errors: >>>>> - err_msg += ("{}: {}".format(error, >>>>> self._aug.get(error))) >>>>> + err_msg = '\n'.join( >>>>> + ["{}: {}".format(e, self._aug.get(e)) for e in >>>>> errors] >>>>> + ) >>>>> raise RuntimeError(err_msg) >>>>> self._loaded = True >>>>> >>>>> 11.) >>>>> >>>>> +class aug_node(collections.MutableMapping): >>>>> + """ Single augeas node. >>>>> + Can be handled as python dict(). >>>>> + """ >>>>> + def __init__(self, aug, path): >>>>> + self._aug = aug >>>>> + if path and os.path.isabs(path): >>>>> + self._path = path >>>>> + else: >>>>> + self._tmp = _tmp_path(aug, path) >>>>> + self._path = self._tmp.path >>>>> >>>>> Isn't it better to change signature of __init__ to: >>>>> >>>>> def __init__(self, aug, path=None): >>>>> >>>>> and then test whether path is None? >>>>> >>>>> 12.) >>>>> >>>>> def __setitem__(self, key, node): >>>>> + target = os.path.join(self._path, key) >>>>> + end = '{0}[0]'.format(os.path.join(self._path, key)) >>>>> + if self._aug.match(target): >>>>> + self._aug.remove(target) >>>>> + target_list = aug_list(self._aug, target) >>>>> + for src_node in aug_list(node._aug, node._path): >>>>> + target_list.append(src_node) >>>>> >>>>> The 'end' variable is declared but not used. >>>>> >>>>> 13.) >>>>> >>>>> + >>>>> + def __len__(self): >>>>> + return len(self._aug.match('{0}/*'.format(self._path))) >>>>> + >>>>> + def __iter__(self): >>>>> + for key in self._aug.match('{0}/*'.format(self._path)): >>>>> + yield self._aug.label(key) >>>>> + raise StopIteration() >>>>> + >>>>> >>>>> Shouldn't we construct paths using os.path.join for the sake of >>>>> consistency? >>>>> >>>>> 14.) >>>>> >>>>> + def __bool__(self): >>>>> + return (bool(len(self)) or bool(self.value)) >>>>> >>>>> The parentheses around the boolean expression are not needed >>>>> >>>>> 15.) >>>>> >>>>> +class aug_list(collections.MutableSequence): >>>>> + """Augeas NODESET. >>>>> + Can be handled as a list(). >>>>> + """ >>>>> + def __init__(self, aug, path): >>>>> + self._aug = aug >>>>> + if path and os.path.isabs(path): >>>>> + self._path = path >>>>> + else: >>>>> + self._tmp = _tmp_path(aug, path) >>>>> + self._path = self._tmp.path >>>>> >>>>> I would use 'path=None' int he signature and then test whether 'path >>>>> is not None'. >>>>> >>>>> 16.) >>>>> >>>>> + if not self._aug.match(target): >>>>> + raise IndexError() >>>>> >>>>> It would be nice if you could put some basic error message into the >>>>> raised exceptions, like "node index out of range" or something like >>>>> that >>>>> >>>>> 17.) >>>>> >>>>> + elif isinstance(index, slice): >>>>> + label = self._path.split('/')[-1] >>>>> >>>>> you could use os.path.basename() to get the leaf node. >>>>> >>>>> >>>>> 18.) >>>>> >>>>> + replace = range_target[:len(node)] >>>>> + delete = create = [] >>>>> >>>>> Be careful here as you create two references to the same empty list >>>>> object, which is probably not what you wanted. >>>>> >>>>> 19.) >>>>> + try: >>>>> + create_start = range_target[-1]+1 >>>>> + except IndexError: >>>>> + create_start = self._idx_pos(index.start) >>>>> + create_stop = create_start+len(node)-len(replace) >>>>> + create = list(range(create_start, create_stop)) >>>>> >>>>> Please respect PEP8 and put spaces around arithmetic operators in >>>>> assignments. >>>>> >>>>> Also it would be nice to have at least a minimal test suite for this >>>>> module, but that may be a separate ticket. >>>>> >>>>> patch 0096: >>>>> >>>>> 1.) please fix the commit message >>>>> 2.) please use new-style license header in ipapython/ntp.py >>>>> 3.) >>>>> >>>>> + return ("Conflicting Time&Date synchroniztion service '%s' >>>>> is " >>>>> + "currently enabled and/or running on the system." >>>>> + % self.conflicting_service) >>>>> >>>>> Please fix the typo in the error message. >>>>> >>>>> 4.) >>>>> + service = services.service(self.service_name) >>>>> + if sstore: >>>>> + if sstore.get_state('ntp', 'enabled') is None: >>>>> + sstore.backup_state('ntp', 'enabled', >>>>> service.is_enabled()) >>>>> + >>>>> + if fstore: >>>>> + if not fstore.has_file(self.conf_file): >>>>> + fstore.backup_file(self.conf_file) >>>>> >>>>> the conditions in the 'if' statement can be merged into single AND >>>>> expression >>>>> >>>>> 5.) >>>>> + self._store_service_state(sstore, fstore) >>>>> + if sstore: >>>>> + sstore.backup_state('ntp', "enabled", >>>>> service.is_enabled()) >>>>> + >>>>> + if fstore: >>>>> + fstore.backup_file(self.conf_file) >>>>> >>>>> I think these checks are redundant here. >>>>> >>>>> 6.) >>>>> + # In such case it is OK to fail >>>>> + try: >>>>> + restored = fstore.restore_file(self.conf_file) >>>>> + except Exception: >>>>> + pass >>>>> >>>>> Instead of 'pass' it would be better to set restored to False so that >>>>> you don't hit NameError later. >>>>> >>>>> 7.) >>>>> + >>>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>>> fstore=None): >>>>> + self.server_options['burst'] = None >>>>> + self.server_options['iburst'] = None >>>>> >>>>> I would rather set these instance variables in __init__() than here. >>>>> >>>>> 8.) >>>>> >>>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>>> fstore=None): >>>>> + self.conf_file = paths.CHRONY_CONF >>>>> self.conf_file is already defined in constructor. >>>>> >>>>> 9.) >>>>> >>>>> + self.server_options['iburst'] = None >>>>> this should be moved to __init__() >>>>> >>>>> 10.) >>>>> + with ipaaugeas.aug_obj() as aug: >>>>> + try: >>>>> + aug.add_lens(self.lens, [self.conf_file]) >>>>> + aug.load() >>>>> + except RuntimeError as e: >>>>> + raise NTPConfigurationError(e) >>>>> >>>>> This code is repeated quite a few times, maybe it would be a good idea >>>>> to factor it out to a method of NTPService object. >>>>> >>>>> >>>>> Patch 0097: >>>>> >>>>> 1.) please fix a typo here: >>>>> >>>>> + description="Disble any other Time synchronization services." >>>>> >>>>> 2.) >>>>> >>>>> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >>>>> you have 2 spaces before 'ntpinstance' >>>>> >>>> >>>> I'm adding my nitpicks too :) >>>> >>>> 1) >>>> +#!/usr/bin/python >>>> >>>> This should not be in modules, only in executable files >>>> >>>> 2) >>>> Missing license in ipaaugeas.py >>>> >>>> Martin^2 >>> >>> Hello, >>> after offline discussion with Honza I've rewritten the augeas wrapper >>> and modified ipautil/ntp.py accordingly. The rest should be pretty much >>> the same. >>> Patches attached. >>> >> Rebased and added minimal test suite. >> > > Hi David, > > patch 0095: > > I second Petr's opinion, at least some short examples of fetching and > modifying configuration values for .e.g /etc/hosts would be welcome. > > Also there is some leftover comment in the Element.__setitem__: > # self.aug.copy(value.path, self(loc).path) > copy(self.aug, value.path, self(loc).path) > > > patch 0096: > > 1.) > + def __init__(self): > + self.service_name = '' > + self.conf_file = '' > + self.lens = '' > + self.source_keywords = ['server'] > + self.server_options = {} > + self.global_options = {} > > I would rather rewrite this as a proper __init__ method with parameters: > > def __init__(self, service_name = '', self.conf_file = '', ...) > > This is clearer for me than calling empty __init__() of superclass and > then setting instance attributes separately. > > Also the self.lens attribute seems to be unused (leftover from previous > revisions?) > > 2.) > + > + def configure_client(self, ntp_servers=[], sstore=None, fstore=None): > + service = services.service(self.service_name) > + > + self._store_service_state(sstore, fstore) > > Use 'ntp_servers=()' so that there is one less case of pylint > complaining about using mutable object as default when we switch on this > check in the future ;). > > 3.) > I would not turn "check_services" into instance method since it does not > use instance variable at all. I would rather turn this into normal > module-level function as was before and name it to > 'check_conflicting_timedate_services' or something like that. > > In this way you wouldn't have to instantiate the whole class just to > check whether there is a conflict between ntpd/chrony/whatever. > > The same could be argued about 'force' and 'restore_forced' methods. > > 4.) > + > +class Ntp(NTPService): > + > > according to pep8 style guide[1]: > > """ > Note: When using abbreviations in CapWords, capitalize all the letters > of the abbreviation. Thus HTTPServerError is better than HttpServerError. > """ > so name the class NTP please. > > 5.) "NTP" and "Chrony" do not need to override parent's > 'configure_client' method since the overriden one only calls > super-method anyway. > > Patch 0097 > > Double-check that you are not creating cyclic imports > ipapython->ipaplatform. And please import only ipapython.ntp, not the > whole package. > > Patch 0098 > > 1.) > > + tasks.ntp_check_conflict(options.force_ntp) > + except ntp.NTPConflictingService as e: > + print(e) > > I know that this is ipa-client-install and people expect it to print > errors into stdout, but it would be nice to also put the error into > logger at warning level so that there is a trace of it in the logs in > case of trouble. The same can be said about the check for conflicting > NTP services in 'ipa-server/replica-install'. > > Patch 101 > > Yay test and it even passes! It would be nice to have there some > negative test cases but that can be extended by ^QE later. > > [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles > Also an attempt to install IPA server on F23 with chrony running resulted in this traceback: """ 2016-05-20T12:51:14Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 447, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 437, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", line 39, in __configure_server tasks.ntp_configure_server(self.sstore, self.fstore, self.force) File "/usr/lib/python2.7/site-packages/ipaplatform/tasks.py", line 52, in ntp_configure_server ntp.configure_server(sstore, fstore) File "/usr/lib/python2.7/site-packages/ipapython/ntp.py", line 303, in configure_server if not timesync['allow']: File "/usr/lib/python2.7/site-packages/ipapython/configfile.py", line 83, in __getitem__ raise KeyError(loc) KeyError: 'allow' """ That was probably caused by commented "allow" directive in default chrony config (http://paste.fedoraproject.org/368862/63748838). -- Martin^3 Babinsky From mbasti at redhat.com Fri May 20 13:00:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 15:00:39 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA In-Reply-To: References: Message-ID: On 19.05.2016 13:34, Stanislav Laznicka wrote: > > Also, I tried to upgrade from 4.2.4 to 4.3.1 and it seems that it > might be necessary to start the service even earlier in the upgrade > logic. Attached is the trace that occurred during the upgrade. > > I sent the whole log earlier accidentally, hopefully it will not > arrive here as well. > > On 05/19/2016 11:10 AM, Stanislav Laznicka wrote: >> >> NACK, see my comments below >> >> + # following upgrade steps require running CA >> This is a nitpicky nitpick but could you please change this comment >> for # the following ... >> Took me a while to understand what you were trying to say here. >> + if ca_running and not ca.is_running(): >> + ca.stop('pki-tomcat') >> + elif not ca_running and ca.is_running(): >> + ca.start('pki-tomcat') >> + >> You should swap ca.stop and ca.start here, you're stopping the >> service when it's stopped and starting it when it's already running. Shame, shame, shame on me. >> >> On 05/12/2016 04:34 PM, Martin Basti wrote: >>> Patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/5868 >>> >>> >>> >> >> >> > I moved starting of CA to the earlier phase and swapped start/stop to correct order. Patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0477.2-Upgrade-always-start-CA.patch Type: text/x-patch Size: 1970 bytes Desc: not available URL: From mbasti at redhat.com Fri May 20 13:03:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 15:03:13 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin Message-ID: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> The removed code is unused for long time. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0484-Remove-unused-variables-in-automount-plugin.patch Type: text/x-patch Size: 2160 bytes Desc: not available URL: From mbabinsk at redhat.com Fri May 20 13:03:14 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 May 2016 15:03:14 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <572228FA.6040007@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> Message-ID: On 04/28/2016 05:15 PM, Petr Spacek wrote: > On 28.4.2016 14:52, Abhijeet Kasurde wrote: >> Hi Petr, >> >> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>> Hello, >>> >>> ipa-nis-manage: add status option >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>> >>> >>> >> Can you reword the error message here as well ? >> >> if len(args) != 1: >> sys.exit("You must specify one action, either enable or disable") >> >> Thanks, >> Abhijeet Kasurde > > Good catch! > > > Hi Petr, please use upstream ticket provided by Petr Vobornik[1] in the commit message. Also I would rewrite """+ elif args[0] != "enable" and args[0] != "disable" and args[0] != "status": """ in a more pythonic way: " elif args[0] not in {"enable", "disable", "status"}:" Otherwise the patch works as expected. [1] https://fedorahosted.org/freeipa/ticket/5856 -- Martin^3 Babinsky From mbasti at redhat.com Fri May 20 13:06:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 15:06:03 +0200 Subject: [Freeipa-devel] [PATCH 0483] fix referenced before assignment error in baseldap In-Reply-To: <420297df-5226-5658-b8fd-af6a733c4244@redhat.com> References: <3f1231fb-b7f3-b867-c483-d7805b9ad323@redhat.com> <420297df-5226-5658-b8fd-af6a733c4244@redhat.com> Message-ID: <56e6aa9e-f630-dd29-8258-6d0c4bb014e3@redhat.com> On 19.05.2016 10:09, Stanislav Laznicka wrote: > > ACK > > > On 05/18/2016 07:24 PM, Martin Basti wrote: >> Patch attached >> >> >> > Pushed to master: ad1cac12834615a4666624885ae4997286641548 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri May 20 13:32:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 15:32:08 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> Message-ID: <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> On 20.05.2016 12:30, Petr Spacek wrote: > On 18.5.2016 12:43, Martin Basti wrote: >> >> On 12.05.2016 16:16, Martin Basti wrote: >>> >>> >>> On 12.05.2016 11:01, Martin Basti wrote: >>>> >>>> On 11.05.2016 09:41, Martin Basti wrote: >>>>> >>>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>> >>>>>>>>>>>> Patches attached. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>>>>>> privileges >>>>>>>>>>>> >>>>>>>>>>>> DNS privileges are important for handling DNS locations which can be >>>>>>>>>>>> created without DNS servers in IPA topology. We will also need this >>>>>>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>>> objectclasses >>>>>>>>>>>> >>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>> --- >>>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif >>>>>>>>>>>> index >>>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>>> booleanMatch >>>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX >>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC >>>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX >>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX >>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' >>>>>>>>>>>> DESC 'dns >>>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ >>>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ >>>>>>>>>>>> a6Record $ >>>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>>>>> mXRecord $ >>>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ >>>>>>>>>>>> KeyRecord >>>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ >>>>>>>>>>>> dNameRecord >>>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ >>>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ IPSECKEYRecord $ >>>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC >>>>>>>>>>>> 'Zone >>>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>>> idnsForwarders $ >>>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ >>>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' >>>>>>>>>>>> SUP top >>>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' >>>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ >>>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ >>>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( idnsName >>>>>>>>>>>> ) MAY ( >>>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because there >>>>>>>>>>> will not be >>>>>>>>>>> any other object class on the location object (at least not in the >>>>>>>>>>> beginning). >>>>>>>>>>> >>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>>> >>>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command are just >>>>>>>>>>>> prototypes and does not provide any information about server (will be >>>>>>>>>>>> done later) >>>>>>>>>>>> >>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>> --- >>>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>>> API.txt | 59 ++++++++++++++ >>>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>>> index >>>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/VERSION >>>>>>>>>>>> +++ b/VERSION >>>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>>> # # >>>>>>>>>>>> ######################################################## >>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value to 255 >>>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>>> Needs rebase. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>>> index >>>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>>> objectClass: top >>>>>>>>>>>> cn: etc >>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>> +changetype: add >>>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>>> +objectClass: top >>>>>>>>>>>> +cn: locations >>>>>>>>>>>> + >>>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>>> changetype: add >>>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>>> index >>>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>>> +default: objectClass: top >>>>>>>>>>>> +default: cn: locations >>>>>>>>>>> Ok. >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> diff --git a/ipalib/plugins/location.py b/ipalib/plugins/location.py >>>>>>>>>>>> index >>>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>>> [...] >>>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>>> +IPA locations >>>>>>>>>>>> +""") + _(""" >>>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> + at register() >>>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>>> + """ >>>>>>>>>>>> + IPA locations >>>>>>>>>>>> + """ >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>>> + managed_permissions = { >>>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>>> + }, >>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>> + }, >>>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>> + }, >>>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>> + }, >>>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>> + 'description', >>>>>>>>>>>> + }, >>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>> + }, >>>>>>>>>>>> + } >>>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but IMHO >>>>>>>>>>> this is >>>>>>>>>>> okay. >>>>>>>>>>> Less renames we support the better. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> + >>>>>>>>>>>> + takes_params = ( >>>>>>>>>>>> + DNSNameParam( >>>>>>>>>>>> + 'idnsname', >>>>>>>>>>>> + cli_name='name', >>>>>>>>>>>> + primary_key=True, >>>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>>> + # dns name must be relative, we will put it into >>>>>>>>>>>> middle of >>>>>>>>>>>> + # location domain name for location records >>>>>>>>>>>> + only_relative=True, >>>>>>>>>>>> + ), >>>>>>>>>>> Okay. We need to make sure that relative names with multiple labels >>>>>>>>>>> work - >>>>>>>>>>> but >>>>>>>>>>> this should automagically work as long as we are handling DNS names >>>>>>>>>>> using >>>>>>>>>>> proper data types (not as strings). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> + Str( >>>>>>>>>>>> + 'description?', >>>>>>>>>>>> + label=_('Description'), >>>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>>> + ), >>>>>>>>>>> After discussion with Honza we will keep description as single-value >>>>>>>>>>> in the >>>>>>>>>>> IPA framework and ignore that description attribute is multi-value >>>>>>>>>>> in LDAP. >>>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> + at register() >>>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>>>>>> This should say 'Modify description' because nothing else can be >>>>>>>>>>> modified. >>>>>>>>>>> More specific text would hopefully stop some people from looking for >>>>>>>>>>> rename >>>>>>>>>>> options. >>>>>>>>>> I disagree, this is general description about the modify command, see >>>>>>>>>> privilege-add it is the same as I made. I can see in future that we will >>>>>>>>>> forgot to update description of command if we add something new there. >>>>>>>>> This is really an invalid argument. >>>>>>>>> >>>>>>>>> "We must not touch XYZ because its documentation might become obsolete in >>>>>>>>> future if we forget to update it!" :-) >>>>>>>>> >>>>>>>> How about inconsistency with description of older commands? I don't >>>>>>>> think that >>>>>>>> command description should describe attributes that are allowed to change. >>>>>>>> Allowed attributes are shown in --help output >>>>>>> I do not agree but push whatever variant you like, it costed too much >>>>>>> already. >>>>>> NACK anyway. ipa-dns-install screams if you install a server without DNS and >>>>>> run ipa-dns-install later on: >>>>>> >>>>>> The log contains this: >>>>>> >>>>>> add objectClass: >>>>>> top >>>>>> groupofnames >>>>>> nestedgroup >>>>>> add cn: >>>>>> DNS Administrators >>>>>> add description: >>>>>> DNS Administrators >>>>>> adding new entry "cn=DNS >>>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>>> >>>>>> >>>>>> >>>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>>> >>>>>> ) >>>>>> SASL/EXTERNAL authentication started >>>>>> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>>> SASL SSF: 0 >>>>>> ldap_add: Already exists (68) >>>>>> >>>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket -Y >>>>>> >>>>>> EXTERNAL' returned non-zero exit status 68 >>>>>> >>>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>>> >>>> Updated patches attached >>>> >>>> I found that IDNA did not work with previous version, fixed + IDNA tests added >>>> >>>> >>> Fixed here, I sent wrong patches before >>> >>> >>> >>> >> More patches added, all patches are available here: >> https://github.com/bastiak/freeipa/tree/DNS-locations > Functional NACK > > location-show returns incorrect location weight for servers > > # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all > dn: > cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > Server name: vm-046.abc.idm.lab.eng.brq.redhat.com > Managed suffixes: domain > Min domain level: 0 > Max domain level: 1 > Location: l2 > Location weight: 200 > objectclass: ipalocationmember, ipaReplTopoManagedServer, top, > ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig > > # ipa location-show l2 > Location name: l2 > Description: Loc 2 > Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) > > - Did you forget --all somewhere? Nope, I forgot to put it to default attributes, nice catch, I will add test for it. > > Other than that I have only nitpick regarding error message: > ipa: ERROR: l2 cannot be deleted because IPA Server(s) > vm-046.abc.idm.lab.eng.brq.redhat.com requires it > > - Please unify singular/plural. This is how the exception is generated, so you can choose just label, so which label is the right? {'IPA server', 'IPA servers', 'IPA server(s)'} (I think server should be with lower cased 's') raise DependentEntry( label=_('IPA Server(s)'), key=keys[-1], dependent=location_members ) > > I did not require the code because Honza will surely look into details. > Martin From mbasti at redhat.com Fri May 20 14:20:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 16:20:44 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Incorrect message when KRA already installed In-Reply-To: <4f7aef64-e444-f81d-a22e-acbaa4a90b6e@redhat.com> References: <4f7aef64-e444-f81d-a22e-acbaa4a90b6e@redhat.com> Message-ID: <4e13e8ac-f30b-b334-9b76-7a8baa60daf5@redhat.com> On 20.05.2016 12:12, Petr Spacek wrote: > On 17.5.2016 10:54, Patrice Duc-Jacquet wrote: >> Hi everyone >> >> Please see attached candidate patch for ticket >> >> https://fedorahosted.org/freeipa/ticket/5315 > ACK, please add link to the ticket to commit message before pushing. > Pushed to master: 65794fc71c6b76a8fe96423e3fac128dc5de2c7d From mbasti at redhat.com Fri May 20 14:27:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 16:27:36 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Incorrect message when KRA already installed In-Reply-To: <4e13e8ac-f30b-b334-9b76-7a8baa60daf5@redhat.com> References: <4f7aef64-e444-f81d-a22e-acbaa4a90b6e@redhat.com> <4e13e8ac-f30b-b334-9b76-7a8baa60daf5@redhat.com> Message-ID: <3ca22b1f-566e-f6e1-f696-c15970be2b3f@redhat.com> On 20.05.2016 16:20, Martin Basti wrote: > > > On 20.05.2016 12:12, Petr Spacek wrote: >> On 17.5.2016 10:54, Patrice Duc-Jacquet wrote: >>> Hi everyone >>> >>> Please see attached candidate patch for ticket >>> >>> https://fedorahosted.org/freeipa/ticket/5315 >> ACK, please add link to the ticket to commit message before pushing. >> > Pushed to master: 65794fc71c6b76a8fe96423e3fac128dc5de2c7d > yes I forgot to add ticket there before push, sorry From mbasti at redhat.com Fri May 20 14:28:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 May 2016 16:28:11 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin In-Reply-To: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> References: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> Message-ID: <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> On 20.05.2016 15:03, Martin Basti wrote: > The removed code is unused for long time. > > Patch attached. > > > https://fedorahosted.org/freeipa/attachment/ticket/5899/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri May 20 15:04:43 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 May 2016 17:04:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0789-0796 Python 3 fixes for the server part Message-ID: <31cf8af1-a133-73b8-7304-90f827a8ad4e@redhat.com> Hello, Here are some more Python3 patches. Most are pretty routine, but pay special attention to the first and last patch. With these patches, running the in-tree test suite gives me the same errors in Python 2 and Python 3, except: - test_install ? failures in the updater that I haven't investigated yet - test_ipaserver ? test bug (relying on order of values in an LDAP attribute) and a text/bytes issue in certificate parsing In the next few months, I'll need to focus less on IPA and more on Samba, which is a prerequisite for porting the IPA server. So I'll quickly summarize the current state of the porting effort: All of FreeIPA's dependencies except Samba are ported to Python 3 (and packaged in Fedora). A recent change switched the IPA client to running on Python 3. With the patches I'm sending now, most of the "single machine" tests are passing. The install scripts will still need some work, as will the server parts that aren't shared with the client. I'd like to ask the IPA team to sometimes take a look at the Python 3 tests, and try to avoid too many regressions. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0789-ipaldap-Keep-attribute-names-as-text-not-bytes.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0790-ipapython.secrets.kem-Use-ConfigParser-from-six.move.patch Type: text/x-patch Size: 1447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0791-test_topology_plugin-Don-t-rely-on-order-of-an-attri.patch Type: text/x-patch Size: 1256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0792-test_rpcserver-Expect-updated-error-message-under-Py.patch Type: text/x-patch Size: 1386 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0793-ipaplatform.redhat-Use-bytestrings-when-calling-rpm..patch Type: text/x-patch Size: 1327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0794-test_ipaserver.test_ldap-Use-bytestrings-for-raw-LDA.patch Type: text/x-patch Size: 2257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0795-ipaldap-Convert-dict-items-to-list-before-iterating.patch Type: text/x-patch Size: 1032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0796-test_ipaserver.test_ldap-Adjust-tests-to-Python-3-s-.patch Type: text/x-patch Size: 2050 bytes Desc: not available URL: From sbose at redhat.com Fri May 20 19:23:46 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 20 May 2016 21:23:46 +0200 Subject: [Freeipa-devel] [PATCH] 0156 extdom: add certificate request Message-ID: <20160520192346.GH11015@p.Speedport_W_724V_Typ_A_05011603_00_009> Hi, this patch allows the extom plugin to lookup users by certificate which is needed in the case where a IPA client wants to lookup an AD user who has the certificate stored in AD. To make this work the related patches I just send to sssd-devel are needed as well. Currently the patches miss the change in the required version of SSSD. since the SSSD patches are not committed. But the patches are needed to fully test the SSSD patches. I will send a new version with the needed changes to the minimal SSSD version when the SSSD patches are committed. bye, Sumit -------------- next part -------------- From b7b84fb4192af70e784c4cee18ff4be532d0f83f Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 26 Apr 2016 13:22:40 +0200 Subject: [PATCH] extdom: add certificate request Related to https://fedorahosted.org/freeipa/ticket/4955 --- .../ipa-extdom-extop/ipa_extdom.h | 4 ++- .../ipa-extdom-extop/ipa_extdom_common.c | 31 +++++++++++++++++----- 2 files changed, 27 insertions(+), 8 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index a77711977186b702caafa2729dc13090c6031791..aa7855650789448ae4220b33cc2de858883fe302 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -80,7 +80,8 @@ enum input_types { INP_SID = 1, INP_NAME, INP_POSIX_UID, - INP_POSIX_GID + INP_POSIX_GID, + INP_CERT }; enum request_types { @@ -115,6 +116,7 @@ struct extdom_req { char *domain_name; gid_t gid; } posix_gid; + char *cert; } data; char *err_msg; }; diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 823c05c810361f121cb46831fb2d4e846729d792..e629247fd771e374d50486d836cd3b0d8d32a78a 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -349,6 +349,9 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) &id); req->data.posix_gid.gid = (gid_t) id; break; + case INP_CERT: + tag = ber_scanf(ber, "a}", &req->data.cert); + break; default: ber_free(ber, 1); set_err_msg(req, "Unknown input type"); @@ -383,6 +386,9 @@ void free_req_data(struct extdom_req *req) case INP_POSIX_GID: ber_memfree(req->data.posix_gid.domain_name); break; + case INP_CERT: + ber_memfree(req->data.cert); + break; } free(req->err_msg); @@ -861,10 +867,12 @@ done: return ret; } -static int handle_sid_request(struct ipa_extdom_ctx *ctx, - struct extdom_req *req, - enum request_types request_type, const char *sid, - struct berval **berval) +static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx, + struct extdom_req *req, + enum request_types request_type, + enum input_types input_type, + const char *input, + struct berval **berval) { int ret; struct passwd pwd; @@ -878,7 +886,11 @@ static int handle_sid_request(struct ipa_extdom_ctx *ctx, enum sss_id_type id_type; struct sss_nss_kv *kv_list = NULL; - ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); + if (input_type == INP_SID) { + ret = sss_nss_getnamebysid(input, &fq_name, &id_type); + } else { + ret = sss_nss_getnamebycert(input, &fq_name, &id_type); + } if (ret != 0) { if (ret == ENOENT) { ret = LDAP_NO_SUCH_OBJECT; @@ -1135,8 +1147,13 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, break; case INP_SID: - ret = handle_sid_request(ctx, req, req->request_type, req->data.sid, - berval); + case INP_CERT: + ret = handle_sid_or_cert_request(ctx, req, req->request_type, + req->input_type, + req->input_type == INP_SID ? + req->data.sid : + req->data.cert, + berval); break; case INP_NAME: ret = handle_name_request(ctx, req, req->request_type, -- 2.4.11 From jcholast at redhat.com Mon May 23 05:44:29 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 May 2016 07:44:29 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> Message-ID: On 20.5.2016 15:32, Martin Basti wrote: > > > On 20.05.2016 12:30, Petr Spacek wrote: >> On 18.5.2016 12:43, Martin Basti wrote: >>> >>> On 12.05.2016 16:16, Martin Basti wrote: >>>> >>>> >>>> On 12.05.2016 11:01, Martin Basti wrote: >>>>> >>>>> On 11.05.2016 09:41, Martin Basti wrote: >>>>>> >>>>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>> >>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS related >>>>>>>>>>>>> privileges >>>>>>>>>>>>> >>>>>>>>>>>>> DNS privileges are important for handling DNS locations >>>>>>>>>>>>> which can be >>>>>>>>>>>>> created without DNS servers in IPA topology. We will also >>>>>>>>>>>>> need this >>>>>>>>>>>>> privileges presented for future feature 'External DNS support' >>>>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>>>> objectclasses >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>> --- >>>>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>>>>>> index >>>>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100644 >>>>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>>>> booleanMatch >>>>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN >>>>>>>>>>>>> 'IPA v4.1' ) >>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch >>>>>>>>>>>>> SINGLE-VALUE SYNTAX >>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>>>>>> 'ipaLocation' DESC >>>>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>>>>>> SYNTAX >>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY >>>>>>>>>>>>> integerMatch SYNTAX >>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>>>>>> 'idnsRecord' >>>>>>>>>>>>> DESC 'dns >>>>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName >>>>>>>>>>>>> MAY ( cn $ >>>>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ >>>>>>>>>>>>> aAAARecord $ >>>>>>>>>>>>> a6Record $ >>>>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>>>>>> mXRecord $ >>>>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ >>>>>>>>>>>>> SigRecord $ >>>>>>>>>>>>> KeyRecord >>>>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ >>>>>>>>>>>>> certRecord $ >>>>>>>>>>>>> dNameRecord >>>>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ >>>>>>>>>>>>> DLVRecord $ >>>>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>>>>>> IPSECKEYRecord $ >>>>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME >>>>>>>>>>>>> 'idnsZone' DESC >>>>>>>>>>>>> 'Zone >>>>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ >>>>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>>>> idnsForwarders $ >>>>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( >>>>>>>>>>>>> idnsForwardPolicy $ >>>>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>>>>>> 'ipaDNSZone' >>>>>>>>>>>>> SUP top >>>>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>>>>>> 'idnsSecKey' >>>>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>>>>>> idnsSecKeyCreated $ >>>>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ >>>>>>>>>>>>> idnsSecKeyActivate $ >>>>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>>>>>> idnsName >>>>>>>>>>>>> ) MAY ( >>>>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>>>>>> there >>>>>>>>>>>> will not be >>>>>>>>>>>> any other object class on the location object (at least not >>>>>>>>>>>> in the >>>>>>>>>>>> beginning). >>>>>>>>>>>> >>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ >>>>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>>>> >>>>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command >>>>>>>>>>>>> are just >>>>>>>>>>>>> prototypes and does not provide any information about >>>>>>>>>>>>> server (will be >>>>>>>>>>>>> done later) >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>> --- >>>>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>>>> API.txt | 59 >>>>>>>>>>>>> ++++++++++++++ >>>>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>>>> index >>>>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100644 >>>>>>>>>>>>> --- a/VERSION >>>>>>>>>>>>> +++ b/VERSION >>>>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>>>> # # >>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value >>>>>>>>>>>>> to 255 >>>>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>>>> Needs rebase. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>>>> index >>>>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100644 >>>>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>>>> objectClass: top >>>>>>>>>>>>> cn: etc >>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>> +changetype: add >>>>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>>>> +objectClass: top >>>>>>>>>>>>> +cn: locations >>>>>>>>>>>>> + >>>>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>>>> changetype: add >>>>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>>>> index >>>>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100644 >>>>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>>>> +default: objectClass: top >>>>>>>>>>>>> +default: cn: locations >>>>>>>>>>>> Ok. >>>>>>>>>>>> >>>>>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>>>>>> index >>>>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100644 >>>>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>>>> [...] >>>>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>>>> +IPA locations >>>>>>>>>>>>> +""") + _(""" >>>>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> + at register() >>>>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>>>> + """ >>>>>>>>>>>>> + IPA locations >>>>>>>>>>>>> + """ >>>>>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>>>> + managed_permissions = { >>>>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>> + 'description', >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>> + }, >>>>>>>>>>>>> + } >>>>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>>>>>> IMHO >>>>>>>>>>>> this is >>>>>>>>>>>> okay. >>>>>>>>>>>> Less renames we support the better. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> + >>>>>>>>>>>>> + takes_params = ( >>>>>>>>>>>>> + DNSNameParam( >>>>>>>>>>>>> + 'idnsname', >>>>>>>>>>>>> + cli_name='name', >>>>>>>>>>>>> + primary_key=True, >>>>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>>>> + # dns name must be relative, we will put it into >>>>>>>>>>>>> middle of >>>>>>>>>>>>> + # location domain name for location records >>>>>>>>>>>>> + only_relative=True, >>>>>>>>>>>>> + ), >>>>>>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>>>>>> labels >>>>>>>>>>>> work - >>>>>>>>>>>> but >>>>>>>>>>>> this should automagically work as long as we are handling >>>>>>>>>>>> DNS names >>>>>>>>>>>> using >>>>>>>>>>>> proper data types (not as strings). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> + Str( >>>>>>>>>>>>> + 'description?', >>>>>>>>>>>>> + label=_('Description'), >>>>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>>>> + ), >>>>>>>>>>>> After discussion with Honza we will keep description as >>>>>>>>>>>> single-value >>>>>>>>>>>> in the >>>>>>>>>>>> IPA framework and ignore that description attribute is >>>>>>>>>>>> multi-value >>>>>>>>>>>> in LDAP. >>>>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>>>> >>>>>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>>> + at register() >>>>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>>>> + __doc__ = _('Modify information about an IPA location .') >>>>>>>>>>>> This should say 'Modify description' because nothing else >>>>>>>>>>>> can be >>>>>>>>>>>> modified. >>>>>>>>>>>> More specific text would hopefully stop some people from >>>>>>>>>>>> looking for >>>>>>>>>>>> rename >>>>>>>>>>>> options. >>>>>>>>>>> I disagree, this is general description about the modify >>>>>>>>>>> command, see >>>>>>>>>>> privilege-add it is the same as I made. I can see in future >>>>>>>>>>> that we will >>>>>>>>>>> forgot to update description of command if we add something >>>>>>>>>>> new there. >>>>>>>>>> This is really an invalid argument. >>>>>>>>>> >>>>>>>>>> "We must not touch XYZ because its documentation might become >>>>>>>>>> obsolete in >>>>>>>>>> future if we forget to update it!" :-) >>>>>>>>>> >>>>>>>>> How about inconsistency with description of older commands? I >>>>>>>>> don't >>>>>>>>> think that >>>>>>>>> command description should describe attributes that are allowed >>>>>>>>> to change. >>>>>>>>> Allowed attributes are shown in --help output >>>>>>>> I do not agree but push whatever variant you like, it costed too >>>>>>>> much >>>>>>>> already. >>>>>>> NACK anyway. ipa-dns-install screams if you install a server >>>>>>> without DNS and >>>>>>> run ipa-dns-install later on: >>>>>>> >>>>>>> The log contains this: >>>>>>> >>>>>>> add objectClass: >>>>>>> top >>>>>>> groupofnames >>>>>>> nestedgroup >>>>>>> add cn: >>>>>>> DNS Administrators >>>>>>> add description: >>>>>>> DNS Administrators >>>>>>> adding new entry "cn=DNS >>>>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>>>> >>>>>>> >>>>>>> ) >>>>>>> SASL/EXTERNAL authentication started >>>>>>> SASL username: >>>>>>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>>>> SASL SSF: 0 >>>>>>> ldap_add: Already exists (68) >>>>>>> >>>>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>>>>>> -Y >>>>>>> >>>>>>> EXTERNAL' returned non-zero exit status 68 >>>>>>> >>>>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>>>> >>>>> Updated patches attached >>>>> >>>>> I found that IDNA did not work with previous version, fixed + IDNA >>>>> tests added >>>>> >>>>> >>>> Fixed here, I sent wrong patches before >>>> >>>> >>>> >>>> >>> More patches added, all patches are available here: >>> https://github.com/bastiak/freeipa/tree/DNS-locations >> Functional NACK >> >> location-show returns incorrect location weight for servers >> >> # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all >> dn: >> cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> >> Server name: vm-046.abc.idm.lab.eng.brq.redhat.com >> Managed suffixes: domain >> Min domain level: 0 >> Max domain level: 1 >> Location: l2 >> Location weight: 200 >> objectclass: ipalocationmember, ipaReplTopoManagedServer, top, >> ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig >> >> # ipa location-show l2 >> Location name: l2 >> Description: Loc 2 >> Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) >> >> - Did you forget --all somewhere? > Nope, I forgot to put it to default attributes, nice catch, I will add > test for it. >> >> Other than that I have only nitpick regarding error message: >> ipa: ERROR: l2 cannot be deleted because IPA Server(s) >> vm-046.abc.idm.lab.eng.brq.redhat.com requires it >> >> - Please unify singular/plural. > This is how the exception is generated, so you can choose just label, so > which label is the right? {'IPA server', 'IPA servers', 'IPA server(s)'} > (I think server should be with lower cased 's') > raise DependentEntry( > label=_('IPA Server(s)'), > key=keys[-1], > dependent=location_members > ) Use ngettext here to handle singular/plural correctly. >> >> I did not require the code because Honza will surely look into details. "Allow to use non-Str attributes as keys for members": There is no actual API change, so don't bump VERSION. "Remove CSV from from member params": Again, no actual API change, don't bump VERSION. CSV params should be removed completely. I have a patch in my drawer which does exactly that, should I post it? "DNS Locations: extend server-* command with locations": I don't think ipalocationweight should be in server-find. Searching for servers by exact weight does not strike me as something useful. Or is it? In server.normalize_location(), don't call location.get_dn() with **options, as it contains server options, not location options. Also you are calling kw.pop('ipalocation_location') twice, which is most likely a bug. In server_mod.pre_callback(), don't raise NotFound manually, but rather use self.api.Object.location.handle_not_found(). Honza -- Jan Cholasta From jcholast at redhat.com Mon May 23 06:25:36 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 May 2016 08:25:36 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> <95b3a32f-22cb-6180-94e0-ed7cca807d25@redhat.com> <16f8ee5e-46ce-c2ef-8d1b-465cfab65869@redhat.com> Message-ID: On 20.5.2016 14:54, Martin Babinsky wrote: > On 05/20/2016 02:29 PM, Martin Babinsky wrote: >> On 05/16/2016 01:58 PM, David Kupka wrote: >>> On 26/04/16 10:09, David Kupka wrote: >>>> On 14/03/16 14:01, Martin Basti wrote: >>>>> >>>>> >>>>> On 14.03.2016 13:46, Martin Babinsky wrote: >>>>>> On 03/11/2016 09:16 AM, David Kupka wrote: >>>>>>> Current version (0.5.0) of python-augeas is missing copy() method. >>>>>>> Use >>>>>>> dkupka/python-augeas copr repo before new version it's build and >>>>>>> available in the official repos. >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi David, >>>>>> >>>>>> TLDR: NACK :D. >>>>>> >>>>>> Here are high-level remarks to discuss: >>>>>> >>>>>> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >>>>>> ipaplatform since it is dealing with (sorta) platform specific >>>>>> behavior (ntp vs. chrony vs. whatever we will have for timesync in >>>>>> the >>>>>> future). CC'ing Jan for thoughts. >>>>>> >>>>>> Also regarding patches 0096-0097, we could have platform specific >>>>>> TimeDateService object that could wrap NTP/chrony management. for >>>>>> example, the task namespace functions in Pathc 0096 could be >>>>>> reimplemented as a methods of the service (RedhatTimeDateService, >>>>>> FedoraTimeDateService etc.) and then called in a platform-agnostic >>>>>> manner. >>>>>> >>>>>> Here are some comments regarding code: >>>>>> >>>>>> Patch 0095: >>>>>> >>>>>> 1.) >>>>>> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >>>>>> >>>>>> Do not forget to add this directory to %install and %files >>>>>> spection of >>>>>> the spec file so that it is correctly added to RPM build. >>>>>> >>>>>> 2.) >>>>>> >>>>>> please separate import of system-wide and IPA-specific modules by >>>>>> blank line >>>>>> >>>>>> +import collections >>>>>> +from augeas import Augeas >>>>>> +from ipaplatform.paths import paths >>>>>> +from ipapython.ipa_log_manager import root_logger >>>>>> >>>>>> 3.) the call to parent's __new__ should have signature >>>>>> 'super(aug_obj, >>>>>> cls).__new__(*args, **kwargs)' >>>>>> >>>>>> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >>>>>> **kwargs) >>>>>> >>>>>> 4.) >>>>>> >>>>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>>>> add more' >>>>>> + 'lenses.') >>>>>> >>>>>> Should be 'Augeas lenses _were_ loaded' >>>>>> >>>>>> 5.) >>>>>> >>>>>> + if lens in self.lenses: >>>>>> + raise RuntimeError('Lens %s already added.' % lens) >>>>>> + self.lenses.append(lens) >>>>>> + load_path = '/augeas/load/{0}'.format(lens >>>>>> >>>>>> >>>>>> Shouldn't the following code use os.path,join to construct the >>>>>> load_path? >>>>>> >>>>>> 6.) I would prefer the following indentation style in the add_lens() >>>>>> method >>>>>> >>>>>> @@ -65,9 +65,9 @@ class aug_obj(object): >>>>>> for conf_file in conf_files: >>>>>> self._aug.set(os.path.join(load_path, 'incl[0]'), >>>>>> conf_file) >>>>>> self.tree['old'] = self.tree.get(conf_file, None) >>>>>> - self.tree[conf_file] = aug_node(self._aug, >>>>>> - os.path.join('/files', >>>>>> - conf_file[1:])) >>>>>> + self.tree[conf_file] = aug_node( >>>>>> + self._aug, os.path.join('/files', conf_file[1:]) >>>>>> + ) >>>>>> >>>>>> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >>>>>> 'files', and '//error' would be made into either module variables or >>>>>> class members. >>>>>> >>>>>> 8.) >>>>>> >>>>>> + def load(self): >>>>>> + if self._loaded: >>>>>> + raise RuntimeError('Augeas lenses was loaded. Could not >>>>>> add more' >>>>>> + 'lenses.') >>>>>> >>>>>> Fix the excpetion text in the same way as in 4.) >>>>>> >>>>>> 9.) >>>>>> >>>>>> + errors = self._aug.match(os.path.join('//error')) >>>>>> >>>>>> is the os.path.join necessary here? >>>>>> >>>>>> 10.) I guess you can rewrite the error message in load() method using >>>>>> list comprehension: >>>>>> >>>>>> @@ -76,9 +76,9 @@ class aug_obj(object): >>>>>> self._aug.load() >>>>>> errors = self._aug.match(os.path.join('//error')) >>>>>> if errors: >>>>>> - err_msg = "" >>>>>> - for error in errors: >>>>>> - err_msg += ("{}: {}".format(error, >>>>>> self._aug.get(error))) >>>>>> + err_msg = '\n'.join( >>>>>> + ["{}: {}".format(e, self._aug.get(e)) for e in >>>>>> errors] >>>>>> + ) >>>>>> raise RuntimeError(err_msg) >>>>>> self._loaded = True >>>>>> >>>>>> 11.) >>>>>> >>>>>> +class aug_node(collections.MutableMapping): >>>>>> + """ Single augeas node. >>>>>> + Can be handled as python dict(). >>>>>> + """ >>>>>> + def __init__(self, aug, path): >>>>>> + self._aug = aug >>>>>> + if path and os.path.isabs(path): >>>>>> + self._path = path >>>>>> + else: >>>>>> + self._tmp = _tmp_path(aug, path) >>>>>> + self._path = self._tmp.path >>>>>> >>>>>> Isn't it better to change signature of __init__ to: >>>>>> >>>>>> def __init__(self, aug, path=None): >>>>>> >>>>>> and then test whether path is None? >>>>>> >>>>>> 12.) >>>>>> >>>>>> def __setitem__(self, key, node): >>>>>> + target = os.path.join(self._path, key) >>>>>> + end = '{0}[0]'.format(os.path.join(self._path, key)) >>>>>> + if self._aug.match(target): >>>>>> + self._aug.remove(target) >>>>>> + target_list = aug_list(self._aug, target) >>>>>> + for src_node in aug_list(node._aug, node._path): >>>>>> + target_list.append(src_node) >>>>>> >>>>>> The 'end' variable is declared but not used. >>>>>> >>>>>> 13.) >>>>>> >>>>>> + >>>>>> + def __len__(self): >>>>>> + return len(self._aug.match('{0}/*'.format(self._path))) >>>>>> + >>>>>> + def __iter__(self): >>>>>> + for key in self._aug.match('{0}/*'.format(self._path)): >>>>>> + yield self._aug.label(key) >>>>>> + raise StopIteration() >>>>>> + >>>>>> >>>>>> Shouldn't we construct paths using os.path.join for the sake of >>>>>> consistency? >>>>>> >>>>>> 14.) >>>>>> >>>>>> + def __bool__(self): >>>>>> + return (bool(len(self)) or bool(self.value)) >>>>>> >>>>>> The parentheses around the boolean expression are not needed >>>>>> >>>>>> 15.) >>>>>> >>>>>> +class aug_list(collections.MutableSequence): >>>>>> + """Augeas NODESET. >>>>>> + Can be handled as a list(). >>>>>> + """ >>>>>> + def __init__(self, aug, path): >>>>>> + self._aug = aug >>>>>> + if path and os.path.isabs(path): >>>>>> + self._path = path >>>>>> + else: >>>>>> + self._tmp = _tmp_path(aug, path) >>>>>> + self._path = self._tmp.path >>>>>> >>>>>> I would use 'path=None' int he signature and then test whether 'path >>>>>> is not None'. >>>>>> >>>>>> 16.) >>>>>> >>>>>> + if not self._aug.match(target): >>>>>> + raise IndexError() >>>>>> >>>>>> It would be nice if you could put some basic error message into the >>>>>> raised exceptions, like "node index out of range" or something like >>>>>> that >>>>>> >>>>>> 17.) >>>>>> >>>>>> + elif isinstance(index, slice): >>>>>> + label = self._path.split('/')[-1] >>>>>> >>>>>> you could use os.path.basename() to get the leaf node. >>>>>> >>>>>> >>>>>> 18.) >>>>>> >>>>>> + replace = range_target[:len(node)] >>>>>> + delete = create = [] >>>>>> >>>>>> Be careful here as you create two references to the same empty list >>>>>> object, which is probably not what you wanted. >>>>>> >>>>>> 19.) >>>>>> + try: >>>>>> + create_start = range_target[-1]+1 >>>>>> + except IndexError: >>>>>> + create_start = self._idx_pos(index.start) >>>>>> + create_stop = create_start+len(node)-len(replace) >>>>>> + create = list(range(create_start, create_stop)) >>>>>> >>>>>> Please respect PEP8 and put spaces around arithmetic operators in >>>>>> assignments. >>>>>> >>>>>> Also it would be nice to have at least a minimal test suite for this >>>>>> module, but that may be a separate ticket. >>>>>> >>>>>> patch 0096: >>>>>> >>>>>> 1.) please fix the commit message >>>>>> 2.) please use new-style license header in ipapython/ntp.py >>>>>> 3.) >>>>>> >>>>>> + return ("Conflicting Time&Date synchroniztion service '%s' >>>>>> is " >>>>>> + "currently enabled and/or running on the system." >>>>>> + % self.conflicting_service) >>>>>> >>>>>> Please fix the typo in the error message. >>>>>> >>>>>> 4.) >>>>>> + service = services.service(self.service_name) >>>>>> + if sstore: >>>>>> + if sstore.get_state('ntp', 'enabled') is None: >>>>>> + sstore.backup_state('ntp', 'enabled', >>>>>> service.is_enabled()) >>>>>> + >>>>>> + if fstore: >>>>>> + if not fstore.has_file(self.conf_file): >>>>>> + fstore.backup_file(self.conf_file) >>>>>> >>>>>> the conditions in the 'if' statement can be merged into single AND >>>>>> expression >>>>>> >>>>>> 5.) >>>>>> + self._store_service_state(sstore, fstore) >>>>>> + if sstore: >>>>>> + sstore.backup_state('ntp', "enabled", >>>>>> service.is_enabled()) >>>>>> + >>>>>> + if fstore: >>>>>> + fstore.backup_file(self.conf_file) >>>>>> >>>>>> I think these checks are redundant here. >>>>>> >>>>>> 6.) >>>>>> + # In such case it is OK to fail >>>>>> + try: >>>>>> + restored = fstore.restore_file(self.conf_file) >>>>>> + except Exception: >>>>>> + pass >>>>>> >>>>>> Instead of 'pass' it would be better to set restored to False so that >>>>>> you don't hit NameError later. >>>>>> >>>>>> 7.) >>>>>> + >>>>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>>>> fstore=None): >>>>>> + self.server_options['burst'] = None >>>>>> + self.server_options['iburst'] = None >>>>>> >>>>>> I would rather set these instance variables in __init__() than here. >>>>>> >>>>>> 8.) >>>>>> >>>>>> + def configure_client(self, ntp_servers=[], sstore=None, >>>>>> fstore=None): >>>>>> + self.conf_file = paths.CHRONY_CONF >>>>>> self.conf_file is already defined in constructor. >>>>>> >>>>>> 9.) >>>>>> >>>>>> + self.server_options['iburst'] = None >>>>>> this should be moved to __init__() >>>>>> >>>>>> 10.) >>>>>> + with ipaaugeas.aug_obj() as aug: >>>>>> + try: >>>>>> + aug.add_lens(self.lens, [self.conf_file]) >>>>>> + aug.load() >>>>>> + except RuntimeError as e: >>>>>> + raise NTPConfigurationError(e) >>>>>> >>>>>> This code is repeated quite a few times, maybe it would be a good >>>>>> idea >>>>>> to factor it out to a method of NTPService object. >>>>>> >>>>>> >>>>>> Patch 0097: >>>>>> >>>>>> 1.) please fix a typo here: >>>>>> >>>>>> + description="Disble any other Time synchronization >>>>>> services." >>>>>> >>>>>> 2.) >>>>>> >>>>>> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >>>>>> you have 2 spaces before 'ntpinstance' >>>>>> >>>>> >>>>> I'm adding my nitpicks too :) >>>>> >>>>> 1) >>>>> +#!/usr/bin/python >>>>> >>>>> This should not be in modules, only in executable files >>>>> >>>>> 2) >>>>> Missing license in ipaaugeas.py >>>>> >>>>> Martin^2 >>>> >>>> Hello, >>>> after offline discussion with Honza I've rewritten the augeas wrapper >>>> and modified ipautil/ntp.py accordingly. The rest should be pretty much >>>> the same. >>>> Patches attached. >>>> >>> Rebased and added minimal test suite. >>> >> >> Hi David, >> >> patch 0095: >> >> I second Petr's opinion, at least some short examples of fetching and >> modifying configuration values for .e.g /etc/hosts would be welcome. >> >> Also there is some leftover comment in the Element.__setitem__: >> # self.aug.copy(value.path, self(loc).path) >> copy(self.aug, value.path, self(loc).path) >> >> >> patch 0096: >> >> 1.) >> + def __init__(self): >> + self.service_name = '' >> + self.conf_file = '' >> + self.lens = '' >> + self.source_keywords = ['server'] >> + self.server_options = {} >> + self.global_options = {} >> >> I would rather rewrite this as a proper __init__ method with parameters: >> >> def __init__(self, service_name = '', self.conf_file = '', ...) >> >> This is clearer for me than calling empty __init__() of superclass and >> then setting instance attributes separately. >> >> Also the self.lens attribute seems to be unused (leftover from previous >> revisions?) >> >> 2.) >> + >> + def configure_client(self, ntp_servers=[], sstore=None, >> fstore=None): >> + service = services.service(self.service_name) >> + >> + self._store_service_state(sstore, fstore) >> >> Use 'ntp_servers=()' so that there is one less case of pylint >> complaining about using mutable object as default when we switch on this >> check in the future ;). >> >> 3.) >> I would not turn "check_services" into instance method since it does not >> use instance variable at all. I would rather turn this into normal >> module-level function as was before and name it to >> 'check_conflicting_timedate_services' or something like that. >> >> In this way you wouldn't have to instantiate the whole class just to >> check whether there is a conflict between ntpd/chrony/whatever. >> >> The same could be argued about 'force' and 'restore_forced' methods. >> >> 4.) >> + >> +class Ntp(NTPService): >> + >> >> according to pep8 style guide[1]: >> >> """ >> Note: When using abbreviations in CapWords, capitalize all the letters >> of the abbreviation. Thus HTTPServerError is better than HttpServerError. >> """ >> so name the class NTP please. >> >> 5.) "NTP" and "Chrony" do not need to override parent's >> 'configure_client' method since the overriden one only calls >> super-method anyway. >> >> Patch 0097 >> >> Double-check that you are not creating cyclic imports >> ipapython->ipaplatform. And please import only ipapython.ntp, not the >> whole package. >> >> Patch 0098 >> >> 1.) >> >> + tasks.ntp_check_conflict(options.force_ntp) >> + except ntp.NTPConflictingService as e: >> + print(e) >> >> I know that this is ipa-client-install and people expect it to print >> errors into stdout, but it would be nice to also put the error into >> logger at warning level so that there is a trace of it in the logs in >> case of trouble. The same can be said about the check for conflicting >> NTP services in 'ipa-server/replica-install'. >> >> Patch 101 >> >> Yay test and it even passes! It would be nice to have there some >> negative test cases but that can be extended by ^QE later. >> >> [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles >> > Also an attempt to install IPA server on F23 with chrony running > resulted in this traceback: > > """ > 2016-05-20T12:51:14Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 447, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 437, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", > line 39, in __configure_server > tasks.ntp_configure_server(self.sstore, self.fstore, self.force) > File "/usr/lib/python2.7/site-packages/ipaplatform/tasks.py", line 52, > in ntp_configure_server > ntp.configure_server(sstore, fstore) > File "/usr/lib/python2.7/site-packages/ipapython/ntp.py", line 303, in > configure_server > if not timesync['allow']: > File "/usr/lib/python2.7/site-packages/ipapython/configfile.py", line > 83, in __getitem__ > raise KeyError(loc) > KeyError: 'allow' > > """ > > That was probably caused by commented "allow" directive in default > chrony config (http://paste.fedoraproject.org/368862/63748838). > Patch 95: Rather than checking for existence of Augeas.copy each time your copy is called, check it when the module is loaded: try: copy = augeas.Augeas.copy except attributeError: def copy(aug, src, dst): ... It looks like only the Config class should be public, please underscore everything else. Ditto for object attributes. IMO the classes could be named to better reflect what they are doing. I would go with Element -> Expression, Node -> Predicate, List -> Child. Element.__call__ and Element.__getitem__ should require at least 1 argument and raise TypeError instead of returning None with invalid arguments. The "__nonzero__ = __bool__" should be right below __bool__ definition. In Config, split the file path once in __init__. You should also probably canonicalize it before splitting it. Patch 97: Could you use polymorphism here instead of copy-paste? Patch 98: You should keep --force-ntpd as an alias for --force-ntp for backward compatibility. Honza -- Jan Cholasta From ofayans at redhat.com Mon May 23 07:23:59 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 23 May 2016 09:23:59 +0200 Subject: [Freeipa-devel] [Testplan Review] In-Reply-To: <15def057-454b-8fe1-7e93-0e63d81c2a62@redhat.com> References: <573D97BE.8020202@redhat.com> <15def057-454b-8fe1-7e93-0e63d81c2a62@redhat.com> Message-ID: <5742B00F.4090509@redhat.com> Hi Petr, The test plan is updated. On 05/19/2016 12:54 PM, Petr Vobornik wrote: > On 05/19/2016 12:38 PM, Oleg Fayans wrote: >> Hi all, >> >> I've created the first versio of the testplan for Topology Management >> feature in 4.4 release: >> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >> >> Could someone please review it? >> > > I'll mention what are the important parts. > > 1. In the 3 scenarios, the most important one is testing the > `ipa-server-install --uninstall`. There it is more important to check > whether it did the same as `ipa-csreplica-manage del`, > `ipa-replica-manage del` and `ipa-server-install --uninstall` procedure. > Which means removal of master entry, DNS records, Kerberos keys, > revocation of certificates... Checking RUVs is not the critical part. > > 2. I miss test for move of `ipa-replica-manage set-renewal-master` to API Isn't it more related to the server roles feature? Will it be one of the ipa server* commands? > > 3. test of new `ipa server-del` method > > when these three are done then I'd focus on RUVs > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jcholast at redhat.com Mon May 23 08:02:44 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 May 2016 10:02:44 +0200 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <20160517125029.GJ1323@dhcp-40-8.bne.redhat.com> References: <57161E1F.6020001@redhat.com> <6b09c0a9-2887-92a0-b284-4b5af947dfde@redhat.com> <20160510103617.GP1237@dhcp-40-8.bne.redhat.com> <9eb88563-3d22-3c6e-f314-fc6ce2d69985@redhat.com> <20160517125029.GJ1323@dhcp-40-8.bne.redhat.com> Message-ID: <25104587-46d2-6574-2220-3b453b0af599@redhat.com> On 17.5.2016 14:50, Fraser Tweedale wrote: > On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote: >> On 10.5.2016 12:36, Fraser Tweedale wrote: >>> Honza, thanks for the review. Comments inline. >>> >>> Copy Nalin, re certmonger discussion at the very bottom. >>> >>> On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote: >>>> Hi, >>>> >> >> ----8<------ >> >>>> 2) >>>> >>>> It should be mentioned here that the primary CA is also handled by this >>>> plugin. >>>> >>>> I would like to propose two additional fields: >>>> >>>> * subject (required) - subject name of the CA, to be able to look up >>>> sub-CA that issued a certificate from its issuer name. >>>> >>>> * issuer_ca (optional) - name of the sub-CA which issued certificate for >>>> this CA, to have information about the sub-CA hierarchy. If there is no >>>> sub-CA entry for the issuer, it would be unset. >>>> >>> These data exist in the Dogtag database. Adding them to IPA might >>> be useful for avoiding round trips so it is probably worth doing, >>> but are you aware of use cases that would absolutely require them? >> >> As for subject, we are adding the ability to look up information about >> arbitrary certificates to cert-{show,find} as part of >> . Part of this information >> should be whether the certificate was issued by our CA and what CA it was, >> so that the web UI can present an appropriate "revoke certificate" button >> for the certificate. >> >> As for issuer CA, I believe we need it to fix automatic CA certificate >> renewal. The current renewal code uses virtual "profiles" to handle CA >> certificate renewal, but that turned out to be an issue, especially with >> externally signed CA certificates: >> . Instead it could use >> the issuer CA information from LDAP to figure out what needs to be done. >> (Note that during the renewal, Dogtag is offline.) >> >> Also, both the attributes should be included for compatibility with external >> CAs. At this point, I think it's only a matter of time when support for them >> will be added (there were already several requests for such a feature), and >> I would very much prefer to have to maintain only a single code path for the >> generic stuff (which includes both of the attributes), instead of one for >> Dogtag and one for external CAs. >> > OK, I'll add issuer DN and subject DN attributes to the ipaCa > objectClass. Just to be clear, what I meant is for the issuer attribute to contain the DN of the CA entry in LDAP, not the issuer DN itself. > >>> >>>> >> >> ----8<------ >> >>>> 4) >>>> >>>> """ >>>> For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which >>>> implements the KeyRetriever interface. It invokes a Python script that >>>> performs the retrieval, reusing existing FreeIPA Custodia client code. >>>> """ >>>> >>>> Will this be distributed with Dogtag or with IPA? >>>> >>> It's shipped in Dogtag. >>> >>>> The Python script bit sounds like an implementation detail rather than an >>>> actual design. Ideally the whole thing would be done in Java, right? >>>> >>> I removed the script from the design page (it had changed, though >>> not dramatically). It is written in Python so that we can reuse the >>> CustodiaClient. >> >> I figured as much. My point is that whether you are executing an external >> binary or using native code is an implementation detail, so it should not be >> in the "Design" section, but rather the "Implementation" section. >> > Fair point; I'll move what remains the Implementation section. > >>> >>>> """ >>>> The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key >>>> and shall be executed as pkiuser. >>>> """ >>>> >>>> Could you please use a subdirectory? Like /usr/libexec/pki (if the script is >>>> going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is >>>> going to be distributed with IPA). >>>> >>> What is the rationale - is it a packaging guideline or just common >>> sense? >> >> I'm not sure if it's an actual guideline, but IMHO it's definitely common >> sense - I don't think littering the global namespace (i.e. /usr/libexec) is >> ever preferable to keeping your stuff in your own namespace. >> > I'll drop the script in a subdir. While I'm at it, I think I will > move it to the IPA codebase, to improve locality of the Python code. > e.g. if CustodiaClient API or any other IPA Python API changes, the > code in pki repo will be too easily missed. OK, makes sense. > >>> >>>> """ >>>> pkiuser does not have read access to either of these locations, so a new >>>> service principal shall be created for each Dogtag CA instance for the >>>> purpose of authenticating to Custodia and retrieving lightweight CA private >>>> keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its >>>> keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and >>>> mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and >>>> /etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively. >>>> """ >>>> >>>> Don't forget to update this paragraph with the new principal name. >>>> >>> Thanks, I updated it. >>> >>>> >>>> 5) >>>> >>>> """ >>>> A CA object for the top-level CA will initially be created, with DN >>>> cn=.,ou=cas,cn=ca,$SUFFIX. >>>> """ >>>> >>>> I would rather not use punctuation for the short name, as it can be easily >>>> overlooked (think logs). (Also it should be '/' if anything, not '.', which >>>> usually means "current".) >>>> >>>> Above you stated that the subject name will be derived from the short name >>>> of the sub-CA. The top-level CA has subject name of the form "CN=Certificate >>>> Authority,$SUBJECT_BASE", so its short name should be "Certificate >>>> Authority". >>>> >>> >>> This section was also part of the old design. The entry for the >>> host authority has ``ipaUniqueId=...`` as rightmost RDN, like other >>> CAs. The cn is ``host-authority``. Subject DN is no longer derived >>> from cn. >> >> Please don't use ipaUniqueId as the RDN unless absolutely necessary. Not >> only it makes debugging harder (because you can't tell which object is which >> just by looking at the DN), it also requires the framework to do an extra >> LDAP search every time the DN needs to be translated to primary key. >> > If cn is used in RDN, will changing cn (which then will be a modrdn > operation) correctly update the references from CA ACLs? Yes, the referint DS plugin takes care of that. > >> "host-authority" does not strike me as something familiar, and the "host" >> bit is kind of confusing, since it is not at all related to IPA hosts. Could >> we use something more obvious ("default", "root", ...)? >> > We shouldn't use "root" because it might not be a root CA. > > We probably shouldn't use "default" because we might later want to > allow different default CAs for different profiles or principal > types. What about "main"? > > Perhaps simply "IPA CA", "ipa", or some variation on that theme? Something like this might be the best, as we currently refer to this CA as "IPA CA". > >> In the current schema, there are 3 different key attributes (cn, >> ipaUniqueId, ipaCaId). Can we reduce the number? I don't see anything that >> would mandate more than 2 (cn, ipaCaId). Would it be possible to have only 1 >> (cn)? >> > If we go with cn in RDN then ipaUniqueId can go away. ipaCaId is > needed (stores Dogtag authority ID, which is a UUID and not > user-controlled). I see, OK. > > As discussed above, there will now also be attributes for issuer DN > and subject DN. > >> Why does a Dogtag lightweight CA need to be created before the LDAP entry? I >> assume it's because deleting an LDAP entry is easier than deleting a Dogtag >> lightweight CA in case something goes wrong, in which case I think ipaCaId >> should be required and use a placeholder value in the initial LDAP entry. >> > The IPA object is created first to ensure that the user has the > permissions to do so. Apart from that it is not important which > happens first. I can check permissions with can_add() but defer IPA > object creation until after the Dogtag LWCA has been created. In > fact this is a cleaner approach. Yes, I agree. > >>> >>>> >>>> 6) >>>> >>>> """ >>>> ipa ca-del >>>> >>>> Delete the given certificate authority. This will remove knowledge of the CA >>>> from the FreeIPA directory but will not delete the sub-CA from Dogtag. >>>> Dogtag will still know about the CA and the certificates it issued, be able >>>> to act at a CRL / OCSP authority for it, etc. >>>> """ >>>> >>>> What is the use case for this? Will the certificates issued by the sub-CA >>>> still be valid after delete or not? Will the sub-CA certificate be >>>> explicitly distrusted on delete or not? >>>> >>>> IMO it should be possible to delete only a leaf sub-CA, i.e. anything but >>>> the top-level CA in the current design. >> >> Judging from the updated design, it seems to me that the only thing ca-del >> does is that it prevents further certificate requests to the CA. If that's >> really the case, I think it should be replaced with a "ca-disable" command, >> since every other -del command makes the deleted object invalid for all >> uses. >> > ca-del results in deletion of the signing key from Dogtag's NSSDB, > and deletion of the Dogtag lightweight authority object. On IPA > side it removes the ipaCa object, removes references from CA ACLs, > etc. ca-del should be a command. OK, but should the certificates issued by the CA stay valid? I would think not - when authorization is based on group membership and the group is deleted, it is no longer possible to authorize - when authorization is based on the CA, I assume it should work analogically and authorization should stop working when the CA is deleted. Or am I missing something? > > We can add ca-disable and ca-enable - these behaviours are > implemented in Dogtag already. I prefer the more fine-grained > control that CA ACLs give you, but I suppose people will want > wholesale enable/disable as well? Or is it premature to assume so? I think it can be added later. The advantage over CA ACLs is that you don't have to go through potentially many ACLs to enable/disable a single CA. > >>>> >>>> """ >>>> ipa cert-find [shortname] >>>> >>>> shortname >>>> Optional positional parameter to specify a sub-CA to use (omit to >>>> specify the top-level CA). The special shortname * is used to search in all >>>> CAs. >>>> """ >>>> >>>> This should be "ipa cert-find [--ca=]". At some point, cert-find >>>> should be fixed to be consistent with every other -find command and have an >>>> optional 'criteria' positional argument, and there can't be two optional >>>> positional arguments, as it creates an ambiguity. >>>> >>>> I would prefer a separate argument (e.g. --all-cas, or --cacat=all) rather >>>> than a magic value for an all-CA search. Magic value might work for >>>> cert-find alone, but you are creating a precedent for the whole framework >>>> here. >>>> >>> Design updated. No position arg anymore. No special arg for "all >>> CAs" - it is implied unless one of ``--issuer=DN`` or ``--ca=NAME`` >>> is given. >>> >>>> >>>> """ >>>> ipa cert-show [shortname] >>>> >>>> shortname >>>> Optional positional parameter to specify a sub-CA (omit to specify the >>>> top-level CA). >>>> --chain >>>> Request the certificate chain (when saving via --out , PEM format >>>> is used; this is the format uesd for the end-entity certificate). >>>> """ >>>> >>>> This should be "ipa cert-show [--ca=]", for consistency with >>>> cert-find, see above. >>>> >>> Actually, we do not (at the moment) need a CA argument, because >>> serial numbers are unique in the whole Dogtag instance. I have >>> removed the argument but if it makes a comeback in future, it will >>> be in the form you recommend. >> >> This is not right, for a number of reasons. >> >> First of all, it violates our object model. It may not be very apparent, as >> the cert plugin is currently implemented as a bunch of loosely related >> ad-hoc commands rather than an object with methods, but nonetheless, all of >> the commands which implement CRUD operations on certificates >> (cert-{request,status,show,revoke,remove-hold}) should have the same CA >> argument with the same default value, or no CA argument at all. >> >> Second, the design should not revolve around Dogtag implementation details, >> because implementation details, as well as the circumstances in which the >> feature is used, may change. In particular, this design would not work well >> with the aforementioned external CA support, because instead of using >> issuer+serial as unique identifier of certificates, it uses just serial and >> assumes it is unique among all issuers, which is generally not true. >> > Your reasoning is irrefutable :) There shall be a CA argument, > defaulting to the top-level CA. > >> Last, -show commands are supposed to implement a retrieve operation, but >> what you are proposing is effectively a search for all certificates with a >> given serial number, which actually belongs to cert-find. >> >>> >>>> IMO it would make sense to add --chain to cert-request as well, it should be >>>> useful for certmonger. >>>> >>>> >>>> 7) >>>> >>>> How is a certificate going to be requested from a specific sub-CA using the >>>> getcert command? >>>> >>> I added a preliminary design; add a new certmonger property and >>> corresponding getcert-request(1) option for specifying the target >>> CA. >>> >>> http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA >> >> LGTM. >> > Cool, thanks! > >>> >>> Alternative approaches involve overloading an existing property >>> (e.g. profile) to optionally carry both profile and CA. The >>> overloading could be handled in Certmonger or in FreeIPA. Either >>> way is feasible - both are nasty hacks! - but it is worth mentioning >>> the alternatives. >> >> I don't think the solution proposed in the design page is a hack. >> Overloading an existing property definitely is, so thanks for mentioning it, >> but please don't do it :-) >> > Ah, "both" meant the two overloading options - overloading in > Certmonger or in IPA. I am encouraged that you do not consider the > actual proposal a hack. But the implementation is yet to come ;) > > Honza, thank you for your ongoing input. I will update the design > page tomorrow. And thank you for bearing with me and my slow response times :-) > > Cheers, > Fraser > -- Jan Cholasta From mkosek at redhat.com Mon May 23 08:43:00 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 May 2016 10:43:00 +0200 Subject: [Freeipa-devel] FreeIPA.org mediawiki upgraded to 1.26.3 Message-ID: <66f2cabd-853b-b7e6-eb9a-21a9fdb9400e@redhat.com> Hi all, As there was a security release of Mediawiki software and FreeIPA.org run an obsoleted version of Mediawiki (1.24), I had to upgrade it to the latest and greatest version - 1.26.3. The upgrade is now live: http://www.freeipa.org/page/Special:Version If you have any issue with the wiki, please let me know. -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. From pspacek at redhat.com Mon May 23 11:55:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 May 2016 13:55:02 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> Message-ID: <089d8cdf-eade-b66d-7798-011ccb99a11f@redhat.com> On 20.5.2016 15:03, Martin Babinsky wrote: > On 04/28/2016 05:15 PM, Petr Spacek wrote: >> On 28.4.2016 14:52, Abhijeet Kasurde wrote: >>> Hi Petr, >>> >>> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> ipa-nis-manage: add status option >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>>> >>>> >>>> >>> Can you reword the error message here as well ? >>> >>> if len(args) != 1: >>> sys.exit("You must specify one action, either enable or disable") >>> >>> Thanks, >>> Abhijeet Kasurde >> >> Good catch! >> >> >> > > Hi Petr, > > please use upstream ticket provided by Petr Vobornik[1] in the commit message. > > Also I would rewrite > > """+ elif args[0] != "enable" and args[0] != "disable" and args[0] != > "status": > > """ > > in a more pythonic way: > > " elif args[0] not in {"enable", "disable", "status"}:" > > Otherwise the patch works as expected. > > [1] https://fedorahosted.org/freeipa/ticket/5856 Here you go. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0099-3-ipa-nis-manage-add-status-option.patch Type: text/x-patch Size: 3910 bytes Desc: not available URL: From pspacek at redhat.com Mon May 23 12:05:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 May 2016 14:05:35 +0200 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160520104334.cbzj2nc52lvm6sfn@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> Message-ID: On 20.5.2016 12:43, Alexander Bokovoy wrote: > On Fri, 20 May 2016, Petr Spacek wrote: >> Theory I have seen looks good to me but Security considerations section is >> missing. The design must spell out what are security implications of >> ignore_acceptor_hostname = true >> GSSAPIStrictAcceptorCheck no > I'll add security considerations, thanks for noticing that. > >> All of the implementation details are missing so this review cannot be >> considered complete. > There is nothing to implement here on our side. We discussed it with > Martin K. and he suggested that we might add a link to documentation > when it would be written but that's as much as we can do. > > Thing is, a proper implementation means changes to be done way above > ipa-client-install level, even way above FreeIPA deployment itself, > especially for SSO case where a CNAME would need to be created in a > separate DNS zone that is not under control of FreeIPA. So all we can do > is to suggest something rather than implement. We do that already and > Mark is going to turn the design into a section in the Windows > Integration Guide. Let me clarify that. I did not mean that ipa-client-install should *create* CNAME records. I was thinking more about tailored installation process which can be automatically enabled when CNAME is detected during installation. >> I'm very interested in implementation details & usability of it. Can we make >> this setup easier to achieve by changing ipa-client-install? >> >> Some ideas: >> - populate krb.conf only with >> [domain_realm] >> canonical hostname = IPA.EXAMPLE.COM >> >> and enable DNS auto-detection for everything else. > We already have auto-detection working. For non-SSO case > 'ipa-client-install --domain=ipa.example.com' on ipa-client.example.com > will automatically configure everything. The only change is indeed by > setting 'ipa-client.example.com = IPA.EXAMPLE.COM'. For SSO case we > simply discover that AD DC is not IPA LDAP server so we refuse to > operate unless you provide manual options. Sorry for not being clear. I did not mean auto-detection of domain, this surely needs to be handled by --domain option. I was thinking about detection of CNAME which could trigger addition of ipa-client.example.com = IPA.EXAMPLE.COM to krb5.conf. Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM to krb5.conf unconditionally? I do not see any harm in doing so. > However, it is impossible to > do anything here automatically because the actual behavior would depend > on external conditions which we cannot control. > > This is really something that has to be written in the planning guide. > For example, if you have SSO case and want to put A/AAAA record and > CNAME record, it is not a given fact that both of them have to be named > in the same way. In fact, they most likely will be different as CNAME > record is part of user-facing application namespace and A/AAAA records > in IPA DNS zone are part of a backend naming. There is no > standardization here. Sure. I was thinking about special handling for case where ipa-client-install is ran with parameters "--domain=ipa --hostname=cname". It could modify krb5.conf and possibly print hint about ignore_acceptor_hostname or just a link to docs "it seems that you should read ". >> I think that: >> a) For normal setups with disjoint domains this should just work as usual. >> >> b) For setup without CNAME for IPA client it should work because example.com >> will be detected as AD domain and scenario described in the section 'No single >> sign-on required' will work. >> >> c) For setup with CNAME the user will need to add ignore_acceptor_hostname but >> krb5.conf will be configured properly. >> >> >> >> BTW why is it needed to use ignore_acceptor_hostname if there is a CNAME? MIT >> Kerberos should see the correct name as it detects CNAMEs. Does AD ignore the >> CNAME when requesting a ticket? What else? > No, it does not ignore, it resolves CNAME to A/AAAA name. However, there > are cases when people want to have both principals from IPA and AD > realms in /etc/krb5.keytab and want to support both ways to access it. > >> If it is needed, can we detect the CNAME and turn on ignore_acceptor_hostname >> automatically? (This depends on security considerations section, of course.) > Exactly because it is part of the behavior defined by application > frontend considerations, we can only document it and not do automated > handling. Okay, understood. >> Speaking of certs, should we introduce a aliases for host entries to avoid the >> need of fake hosts? > These 'fake hosts' are as good as aliases, even better, because they > allow us to have full control over who can manage them. I do not see how this is different from any other object which has managedBy attribute. It is not a special property of host. -- Petr^2 Spacek From frenaud at redhat.com Mon May 23 14:24:38 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Mon, 23 May 2016 16:24:38 +0200 Subject: [Freeipa-devel] Questions on git Message-ID: Hi all, as I am ramping up with git, I have a few questions. Let's imagine the following development workflow: - I start working on a specific issue and decide to create a branch on my git repository (on my laptop) git clone git://git.fedorahosted.org/git/freeipa.git git branch -b issue - When my code looks ok, I decide to commit on the branch (still on my ldaptop) git add git commit - Now I would like to push this on my development VM (I already cloned the repos on the VM). What would be the right command to push only the branch "issue" to my VM repo? Does the following command push only the current branch? git push --repo=ssh://frenaud@:/path/to/src/freeipa - When the tests are ok and I want to submit a patch, can I stay on the branch "issue" to create the patch or should I merge first with the main branch? If a merge is required, is it recommended to pull then merge or merge then pull? Thanks for your tips, Flo. -- Florence Blanc-Renaud Identity Management Team, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon May 23 14:33:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 May 2016 16:33:29 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: References: Message-ID: On 23.05.2016 16:24, Florence Blanc-Renaud wrote: > Hi all, > > as I am ramping up with git, I have a few questions. Let's imagine the > following development workflow: > > - I start working on a specific issue and decide to create a branch on > my git repository (on my laptop) > git clone git://git.fedorahosted.org/git/freeipa.git > git branch -b issue > - When my code looks ok, I decide to commit on the branch (still on my > ldaptop) > git add > git commit I found handy also 'git add -p' which allows you to choose what commit > > - Now I would like to push this on my development VM (I already cloned > the repos on the VM). What would be the right command to push only the > branch "issue" to my VM repo? Does the following command push only the > current branch? > git push --repo=ssh://frenaud@:/path/to/src/freeipa Could work, I usually just rsync the whole folder to VM > > - When the tests are ok and I want to submit a patch, can I stay on > the branch "issue" to create the patch or should I merge first with > the main branch? If a merge is required, is it recommended to pull > then merge or merge then pull? You can stay on your issue branch, but patch should be rebased to current master (patch should apply on top of master) something like: git checkout master git pull git check issue git rebase master issue or interactive rebase if you want change order of patches or something git rebase -i master issue > > Thanks for your tips, > Flo. > -- > Florence Blanc-Renaud > Identity Management Team, Red Hat > > Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon May 23 14:47:02 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 May 2016 16:47:02 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: References: Message-ID: <20160523144702.GC3443@hendrix> On Mon, May 23, 2016 at 04:33:29PM +0200, Martin Basti wrote: > > > On 23.05.2016 16:24, Florence Blanc-Renaud wrote: > > Hi all, > > > > as I am ramping up with git, I have a few questions. Let's imagine the > > following development workflow: > > > > - I start working on a specific issue and decide to create a branch on > > my git repository (on my laptop) > > git clone git://git.fedorahosted.org/git/freeipa.git > > git branch -b issue > > - When my code looks ok, I decide to commit on the branch (still on my > > ldaptop) > > git add > > git commit > > I found handy also 'git add -p' which allows you to choose what commit ...or git add -e > > > > > - Now I would like to push this on my development VM (I already cloned > > the repos on the VM). What would be the right command to push only the > > branch "issue" to my VM repo? Does the following command push only the > > current branch? > > git push --repo=ssh://frenaud@:/path/to/src/freeipa > > Could work, I usually just rsync the whole folder to VM For local VMs, I use an NFS share so that I don't rsync anything, but the sources magically appear in the VMs (vagrant's shared folders make this easy once you're past the initial setup pain). > > > > - When the tests are ok and I want to submit a patch, can I stay on the > > branch "issue" to create the patch or should I merge first with the main > > branch? If a merge is required, is it recommended to pull then merge or > > merge then pull? > > You can stay on your issue branch, but patch should be rebased to current > master (patch should apply on top of master) > > something like: > > git checkout master > git pull > git check issue > git rebase master issue > > or interactive rebase if you want change order of patches or something > git rebase -i master issue IMO creating the branch with "--track origin/master" helps.. btw I find this man page helpful: https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html as well as this free book: https://git-scm.com/book/en/v2 From mbabinsk at redhat.com Mon May 23 16:12:04 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 23 May 2016 18:12:04 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <089d8cdf-eade-b66d-7798-011ccb99a11f@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> <089d8cdf-eade-b66d-7798-011ccb99a11f@redhat.com> Message-ID: <7b9ac910-b88b-8131-4091-4f444fb77efa@redhat.com> On 05/23/2016 01:55 PM, Petr Spacek wrote: > On 20.5.2016 15:03, Martin Babinsky wrote: >> On 04/28/2016 05:15 PM, Petr Spacek wrote: >>> On 28.4.2016 14:52, Abhijeet Kasurde wrote: >>>> Hi Petr, >>>> >>>> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> ipa-nis-manage: add status option >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>>>> >>>>> >>>>> >>>> Can you reword the error message here as well ? >>>> >>>> if len(args) != 1: >>>> sys.exit("You must specify one action, either enable or disable") >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>> >>> Good catch! >>> >>> >>> >> >> Hi Petr, >> >> please use upstream ticket provided by Petr Vobornik[1] in the commit message. >> >> Also I would rewrite >> >> """+ elif args[0] != "enable" and args[0] != "disable" and args[0] != >> "status": >> >> """ >> >> in a more pythonic way: >> >> " elif args[0] not in {"enable", "disable", "status"}:" >> >> Otherwise the patch works as expected. >> >> [1] https://fedorahosted.org/freeipa/ticket/5856 > > Here you go. > Thanks, ACK. -- Martin^3 Babinsky From jcholast at redhat.com Tue May 24 05:49:15 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 May 2016 07:49:15 +0200 Subject: [Freeipa-devel] [PATCH 557] replica install: do not set CA renewal master flag Message-ID: Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-557-replica-install-do-not-set-CA-renewal-master-flag.patch Type: text/x-patch Size: 4009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-557.0.4_2-replica-install-do-not-set-CA-renewal-master-flag.patch Type: text/x-patch Size: 3378 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 24 06:56:01 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 May 2016 09:56:01 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> Message-ID: <20160524065601.q337a2mq5qfocr6o@redhat.com> On Mon, 23 May 2016, Petr Spacek wrote: >On 20.5.2016 12:43, Alexander Bokovoy wrote: >> On Fri, 20 May 2016, Petr Spacek wrote: >>> Theory I have seen looks good to me but Security considerations section is >>> missing. The design must spell out what are security implications of >>> ignore_acceptor_hostname = true >>> GSSAPIStrictAcceptorCheck no >> I'll add security considerations, thanks for noticing that. >> >>> All of the implementation details are missing so this review cannot be >>> considered complete. >> There is nothing to implement here on our side. We discussed it with >> Martin K. and he suggested that we might add a link to documentation >> when it would be written but that's as much as we can do. >> >> Thing is, a proper implementation means changes to be done way above >> ipa-client-install level, even way above FreeIPA deployment itself, >> especially for SSO case where a CNAME would need to be created in a >> separate DNS zone that is not under control of FreeIPA. So all we can do >> is to suggest something rather than implement. We do that already and >> Mark is going to turn the design into a section in the Windows >> Integration Guide. > >Let me clarify that. I did not mean that ipa-client-install should *create* >CNAME records. I was thinking more about tailored installation process which >can be automatically enabled when CNAME is detected during installation. If CNAME is detected, we can do some magic, right. But would it help? Two things matter here: - if `hostname` is a CNAME, we need to register real hostname - also create host object for CNAME record and make sure realm hostname is used to manage it Question is what to do if hostname was forced via command line option and it is different from the CNAME which is `hostname`. In current code we ignore `hostname` and force the hostname via /etc/hosts to whatever was specified on the command line. > >I was thinking about detection of CNAME which could trigger addition of >ipa-client.example.com = IPA.EXAMPLE.COM >to krb5.conf. > >Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM >to krb5.conf unconditionally? I do not see any harm in doing so. That sounds better. May be you can file a ticket for this one? It doesn't need to be tied to the discussed proposal although you can certainly mention it. >> However, it is impossible to >> do anything here automatically because the actual behavior would depend >> on external conditions which we cannot control. >> >> This is really something that has to be written in the planning guide. >> For example, if you have SSO case and want to put A/AAAA record and >> CNAME record, it is not a given fact that both of them have to be named >> in the same way. In fact, they most likely will be different as CNAME >> record is part of user-facing application namespace and A/AAAA records >> in IPA DNS zone are part of a backend naming. There is no >> standardization here. > >Sure. I was thinking about special handling for case where ipa-client-install >is ran with parameters "--domain=ipa --hostname=cname". It could modify >krb5.conf and possibly print hint about ignore_acceptor_hostname or just a >link to docs "it seems that you should read ". Well, we don't have the documentation for it yet, only upstream wiki. May be we should add instead a section to ipa-client-install manual page and reference it? > >>> Speaking of certs, should we introduce a aliases for host entries to avoid the >>> need of fake hosts? >> These 'fake hosts' are as good as aliases, even better, because they >> allow us to have full control over who can manage them. > >I do not see how this is different from any other object which has managedBy >attribute. It is not a special property of host. We have managedBy handling in hosts and services specifically to allow certificate issuing on behalf of another entity. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 24 07:22:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 May 2016 09:22:12 +0200 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160524065601.q337a2mq5qfocr6o@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> Message-ID: On 24.5.2016 08:56, Alexander Bokovoy wrote: > On Mon, 23 May 2016, Petr Spacek wrote: >> On 20.5.2016 12:43, Alexander Bokovoy wrote: >>> On Fri, 20 May 2016, Petr Spacek wrote: >>>> Theory I have seen looks good to me but Security considerations section is >>>> missing. The design must spell out what are security implications of >>>> ignore_acceptor_hostname = true >>>> GSSAPIStrictAcceptorCheck no >>> I'll add security considerations, thanks for noticing that. >>> >>>> All of the implementation details are missing so this review cannot be >>>> considered complete. >>> There is nothing to implement here on our side. We discussed it with >>> Martin K. and he suggested that we might add a link to documentation >>> when it would be written but that's as much as we can do. >>> >>> Thing is, a proper implementation means changes to be done way above >>> ipa-client-install level, even way above FreeIPA deployment itself, >>> especially for SSO case where a CNAME would need to be created in a >>> separate DNS zone that is not under control of FreeIPA. So all we can do >>> is to suggest something rather than implement. We do that already and >>> Mark is going to turn the design into a section in the Windows >>> Integration Guide. >> >> Let me clarify that. I did not mean that ipa-client-install should *create* >> CNAME records. I was thinking more about tailored installation process which >> can be automatically enabled when CNAME is detected during installation. > If CNAME is detected, we can do some magic, right. But would it help? > Two things matter here: > - if `hostname` is a CNAME, we need to register real hostname > - also create host object for CNAME record and make sure realm hostname > is used to manage it Yes, I think that this could and should be done automatically to ease deployment. > Question is what to do if hostname was forced via command line option > and it is different from the CNAME which is `hostname`. In current code > we ignore `hostname` and force the hostname via /etc/hosts to whatever > was specified on the command line. I would keep this behavior - after all, user wanted an explicit hostname so give it to him. It may break things but any usage of override options (hostname, domain, server ...) can break something when used improperly. >> I was thinking about detection of CNAME which could trigger addition of >> ipa-client.example.com = IPA.EXAMPLE.COM >> to krb5.conf. >> >> Or, alternatively, why can't we add ipa-client.example.com = IPA.EXAMPLE.COM >> to krb5.conf unconditionally? I do not see any harm in doing so. > That sounds better. May be you can file a ticket for this one? It > doesn't need to be tied to the discussed proposal although you can > certainly mention it. > > >>> However, it is impossible to >>> do anything here automatically because the actual behavior would depend >>> on external conditions which we cannot control. >>> >>> This is really something that has to be written in the planning guide. >>> For example, if you have SSO case and want to put A/AAAA record and >>> CNAME record, it is not a given fact that both of them have to be named >>> in the same way. In fact, they most likely will be different as CNAME >>> record is part of user-facing application namespace and A/AAAA records >>> in IPA DNS zone are part of a backend naming. There is no >>> standardization here. >> >> Sure. I was thinking about special handling for case where ipa-client-install >> is ran with parameters "--domain=ipa --hostname=cname". It could modify >> krb5.conf and possibly print hint about ignore_acceptor_hostname or just a >> link to docs "it seems that you should read ". > Well, we don't have the documentation for it yet, only upstream wiki. > May be we should add instead a section to ipa-client-install manual page > and reference it? Sounds good to me. >>>> Speaking of certs, should we introduce a aliases for host entries to avoid >>>> the >>>> need of fake hosts? >>> These 'fake hosts' are as good as aliases, even better, because they >>> allow us to have full control over who can manage them. >> >> I do not see how this is different from any other object which has managedBy >> attribute. It is not a special property of host. > We have managedBy handling in hosts and services specifically to allow > certificate issuing on behalf of another entity. I'm still not convinced that 'we historically do it this way' is good enough justification for using fake host objects instead of tailored aliases. -- Petr^2 Spacek From abokovoy at redhat.com Tue May 24 07:26:53 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 May 2016 10:26:53 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> Message-ID: <20160524072653.okijne4ulaihutvm@redhat.com> On Tue, 24 May 2016, Petr Spacek wrote: >>>>> Speaking of certs, should we introduce a aliases for host entries to avoid >>>>> the >>>>> need of fake hosts? >>>> These 'fake hosts' are as good as aliases, even better, because they >>>> allow us to have full control over who can manage them. >>> >>> I do not see how this is different from any other object which has managedBy >>> attribute. It is not a special property of host. >> We have managedBy handling in hosts and services specifically to allow >> certificate issuing on behalf of another entity. > >I'm still not convinced that 'we historically do it this way' is good enough >justification for using fake host objects instead of tailored aliases. I'm not sure it is good to add that. Note that host objects can be used to provide a lot more than just mere aliases: - they can have services associated, with both Kerberos keys and certificates - they can be used to target HBAC rules against them which will be extremely useful when we'll get Authentication Indicators management in place Having "fake" host objects is also crucial for clustered services. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 24 07:32:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 May 2016 09:32:50 +0200 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160524072653.okijne4ulaihutvm@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> Message-ID: <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> On 24.5.2016 09:26, Alexander Bokovoy wrote: > On Tue, 24 May 2016, Petr Spacek wrote: >>>>>> Speaking of certs, should we introduce a aliases for host entries to avoid >>>>>> the >>>>>> need of fake hosts? >>>>> These 'fake hosts' are as good as aliases, even better, because they >>>>> allow us to have full control over who can manage them. >>>> >>>> I do not see how this is different from any other object which has managedBy >>>> attribute. It is not a special property of host. >>> We have managedBy handling in hosts and services specifically to allow >>> certificate issuing on behalf of another entity. >> >> I'm still not convinced that 'we historically do it this way' is good enough >> justification for using fake host objects instead of tailored aliases. > I'm not sure it is good to add that. Note that host objects can be used > to provide a lot more than just mere aliases: > - they can have services associated, with both Kerberos keys and > certificates > - they can be used to target HBAC rules against them which will be > extremely useful when we'll get Authentication Indicators management > in place > > Having "fake" host objects is also crucial for clustered services. Let me clarify this: I'm not saying that we should drop host object completely. I'm saying that 1 host should have exactly 1 host object + 0..n alises pointing to the host object. HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes possible to automate things like 'get certificate will all associated names in SAN' etc. without manual procedures. This would make it easy to distinguish what is canonical name and what is mere alias. That will get handy e.g. when a host is deleted - it would allow us to delete all aliases with host etc. Alternative technical approach is to add aliases to an host's attribute and use it from there. I suspect that this would be less flexible and less future-proof. -- Petr^2 Spacek From abokovoy at redhat.com Tue May 24 07:44:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 May 2016 10:44:38 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> Message-ID: <20160524074438.2xvpshhbrcnuphly@redhat.com> On Tue, 24 May 2016, Petr Spacek wrote: >On 24.5.2016 09:26, Alexander Bokovoy wrote: >> On Tue, 24 May 2016, Petr Spacek wrote: >>>>>>> Speaking of certs, should we introduce a aliases for host entries to avoid >>>>>>> the >>>>>>> need of fake hosts? >>>>>> These 'fake hosts' are as good as aliases, even better, because they >>>>>> allow us to have full control over who can manage them. >>>>> >>>>> I do not see how this is different from any other object which has managedBy >>>>> attribute. It is not a special property of host. >>>> We have managedBy handling in hosts and services specifically to allow >>>> certificate issuing on behalf of another entity. >>> >>> I'm still not convinced that 'we historically do it this way' is good enough >>> justification for using fake host objects instead of tailored aliases. >> I'm not sure it is good to add that. Note that host objects can be used >> to provide a lot more than just mere aliases: >> - they can have services associated, with both Kerberos keys and >> certificates >> - they can be used to target HBAC rules against them which will be >> extremely useful when we'll get Authentication Indicators management >> in place >> >> Having "fake" host objects is also crucial for clustered services. > >Let me clarify this: >I'm not saying that we should drop host object completely. > >I'm saying that 1 host should have exactly 1 host object + 0..n alises >pointing to the host object. > >HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes >possible to automate things like 'get certificate will all associated names in >SAN' etc. without manual procedures. > >This would make it easy to distinguish what is canonical name and what is mere >alias. That will get handy e.g. when a host is deleted - it would allow us to >delete all aliases with host etc. The latter is the only benefit I see here, sorry. The rest is not giving any real feature. If you want to have automated case for retrieving a certificate with all dNSName records, we can add this one specifically as an option to existing code to just follow managedBy -- CA has right to ignore anything in the certificate request already and issue what it thinks is right. >Alternative technical approach is to add aliases to an host's attribute and >use it from there. I suspect that this would be less flexible and less >future-proof. I don't see a need for alias-as-a-property. Instead, I'm interested in having a possibility to have different keys, certificates, etc, on objects used as aliases. This improves security position by splitting the manager and the user of the resource. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 24 07:55:55 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 May 2016 09:55:55 +0200 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160524074438.2xvpshhbrcnuphly@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> Message-ID: <53483a63-35b5-4b84-a049-d20adec19ad1@redhat.com> On 24.5.2016 09:44, Alexander Bokovoy wrote: > On Tue, 24 May 2016, Petr Spacek wrote: >> On 24.5.2016 09:26, Alexander Bokovoy wrote: >>> On Tue, 24 May 2016, Petr Spacek wrote: >>>>>>>> Speaking of certs, should we introduce a aliases for host entries to >>>>>>>> avoid >>>>>>>> the >>>>>>>> need of fake hosts? >>>>>>> These 'fake hosts' are as good as aliases, even better, because they >>>>>>> allow us to have full control over who can manage them. >>>>>> >>>>>> I do not see how this is different from any other object which has >>>>>> managedBy >>>>>> attribute. It is not a special property of host. >>>>> We have managedBy handling in hosts and services specifically to allow >>>>> certificate issuing on behalf of another entity. >>>> >>>> I'm still not convinced that 'we historically do it this way' is good enough >>>> justification for using fake host objects instead of tailored aliases. >>> I'm not sure it is good to add that. Note that host objects can be used >>> to provide a lot more than just mere aliases: >>> - they can have services associated, with both Kerberos keys and >>> certificates >>> - they can be used to target HBAC rules against them which will be >>> extremely useful when we'll get Authentication Indicators management >>> in place >>> >>> Having "fake" host objects is also crucial for clustered services. >> >> Let me clarify this: >> I'm not saying that we should drop host object completely. >> >> I'm saying that 1 host should have exactly 1 host object + 0..n alises >> pointing to the host object. >> >> HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes >> possible to automate things like 'get certificate will all associated names in >> SAN' etc. without manual procedures. >> >> This would make it easy to distinguish what is canonical name and what is mere >> alias. That will get handy e.g. when a host is deleted - it would allow us to >> delete all aliases with host etc. > The latter is the only benefit I see here, sorry. The rest is not giving > any real feature. If you want to have automated case for retrieving a > certificate with all dNSName records, we can add this one specifically > as an option to existing code to just follow managedBy -- CA has right > to ignore anything in the certificate request already and issue what it > thinks is right. > >> Alternative technical approach is to add aliases to an host's attribute and >> use it from there. I suspect that this would be less flexible and less >> future-proof. > I don't see a need for alias-as-a-property. Instead, I'm interested in > having a possibility to have different keys, certificates, etc, on > objects used as aliases. This improves security position by splitting > the manager and the user of the resource. I think that these two are not mutually exclusive. a) If you need separate keys (and the headache associated with it) use a new host object. b) If you need to share keys use alias. Aliases could have other advantages, e.g. using diffrent DNS checks to the user does not need to use --force just to create the alias. Right now we do not have the (b) option so code needs to use hacks like the one you proposed above: "we can add this one specifically as an option to existing code to just follow managedBy" This is simply a hack and relies on user not forgetting to add option --follow-managed-by (e.g.) when requesting a certificate. Not speaking about automated processes requesting certs which would need own heuristics to detect when the option should be supplied. I really do not like these ad-hoc hacks and I'm looking for a systematic solution. -- Petr^2 Spacek From abokovoy at redhat.com Tue May 24 08:12:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 May 2016 11:12:55 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <53483a63-35b5-4b84-a049-d20adec19ad1@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> <53483a63-35b5-4b84-a049-d20adec19ad1@redhat.com> Message-ID: <20160524081255.2sgmdp5p4ikeqsse@redhat.com> On Tue, 24 May 2016, Petr Spacek wrote: >On 24.5.2016 09:44, Alexander Bokovoy wrote: >> On Tue, 24 May 2016, Petr Spacek wrote: >>> On 24.5.2016 09:26, Alexander Bokovoy wrote: >>>> On Tue, 24 May 2016, Petr Spacek wrote: >>>>>>>>> Speaking of certs, should we introduce a aliases for host entries to >>>>>>>>> avoid >>>>>>>>> the >>>>>>>>> need of fake hosts? >>>>>>>> These 'fake hosts' are as good as aliases, even better, because they >>>>>>>> allow us to have full control over who can manage them. >>>>>>> >>>>>>> I do not see how this is different from any other object which has >>>>>>> managedBy >>>>>>> attribute. It is not a special property of host. >>>>>> We have managedBy handling in hosts and services specifically to allow >>>>>> certificate issuing on behalf of another entity. >>>>> >>>>> I'm still not convinced that 'we historically do it this way' is good enough >>>>> justification for using fake host objects instead of tailored aliases. >>>> I'm not sure it is good to add that. Note that host objects can be used >>>> to provide a lot more than just mere aliases: >>>> - they can have services associated, with both Kerberos keys and >>>> certificates >>>> - they can be used to target HBAC rules against them which will be >>>> extremely useful when we'll get Authentication Indicators management >>>> in place >>>> >>>> Having "fake" host objects is also crucial for clustered services. >>> >>> Let me clarify this: >>> I'm not saying that we should drop host object completely. >>> >>> I'm saying that 1 host should have exactly 1 host object + 0..n alises >>> pointing to the host object. >>> >>> HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes >>> possible to automate things like 'get certificate will all associated names in >>> SAN' etc. without manual procedures. >>> >>> This would make it easy to distinguish what is canonical name and what is mere >>> alias. That will get handy e.g. when a host is deleted - it would allow us to >>> delete all aliases with host etc. >> The latter is the only benefit I see here, sorry. The rest is not giving >> any real feature. If you want to have automated case for retrieving a >> certificate with all dNSName records, we can add this one specifically >> as an option to existing code to just follow managedBy -- CA has right >> to ignore anything in the certificate request already and issue what it >> thinks is right. >> >>> Alternative technical approach is to add aliases to an host's attribute and >>> use it from there. I suspect that this would be less flexible and less >>> future-proof. >> I don't see a need for alias-as-a-property. Instead, I'm interested in >> having a possibility to have different keys, certificates, etc, on >> objects used as aliases. This improves security position by splitting >> the manager and the user of the resource. > >I think that these two are not mutually exclusive. > >a) If you need separate keys (and the headache associated with it) use a new >host object. >b) If you need to share keys use alias. >Aliases could have other advantages, e.g. using diffrent DNS checks to the >user does not need to use --force just to create the alias. Well, nothing prevents you from adding 'ipa host-make-alias' command that would essentially create a host and set managedBy to a proper existing host, and would use internally a different DNS check. This would be trivial. Given that enrollment code expects there is already a pre-created host object (or it will be created with enough privileges), we can then use it in ipa-client-install to clearly express CNAME case. >Right now we do not have the (b) option so code needs to use hacks like the >one you proposed above: >"we can add this one specifically as an option to existing code to just follow >managedBy" > >This is simply a hack and relies on user not forgetting to add option >--follow-managed-by (e.g.) when requesting a certificate. Not speaking about >automated processes requesting certs which would need own heuristics to detect >when the option should be supplied. It is not an ad-hoc -- we already getting into situation that we have three different layers of permission checks on top of certificate issuance -- managedBy to permit issuing a cert, CA ACLs to allow using a specific certificate profile, and interpretation of cert request by CA. Adding pure aliases into the mix is going to be 'interesting', while making use of existing managedBy semantics is not complicating anything here. Don't also forget that people usually want to have aliases to allow use of them by name at the edge -- i.e. in HBAC or SUDO rules. Adding an alias concept means you'd need to make all of these (and HBAC/SUDO aren't the only ones, actually) places to be modified, including client software which is something you cannot change. To me aliases on objects look like a huge pain. If we want to have better management of co-related objects, then we should improve the management, e.g. IPA framework. However, the objects are there and their behavior expected to not change dramatically by the client side. >I really do not like these ad-hoc hacks and I'm looking for a systematic solution. The solution you proposed is actually asking for a systematic reshuffling of all client pieces. This is not going to happen, sorry. I'd like to come back to the original topic, though. Aside from security consideration section which I'm going to add today, I need to add 'how to use' section with clear sequenced instructions. Dmitri also asked for a different type of deployment when the host is enrolled into both IPA and AD with and without different names. While it is a possible case, I don't think we want to promote it as to do it correctly we need to have a perfect AD deployment. This is not the case for majority of customer networks I've saw, and what's more important, there is no real gain from such deployment. > >-- >Petr^2 Spacek -- / Alexander Bokovoy From mbasti at redhat.com Tue May 24 08:18:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 May 2016 10:18:29 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <7b9ac910-b88b-8131-4091-4f444fb77efa@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> <572228FA.6040007@redhat.com> <089d8cdf-eade-b66d-7798-011ccb99a11f@redhat.com> <7b9ac910-b88b-8131-4091-4f444fb77efa@redhat.com> Message-ID: <88fb2efa-43dd-c48f-0a4c-3121ac17ca15@redhat.com> On 23.05.2016 18:12, Martin Babinsky wrote: > On 05/23/2016 01:55 PM, Petr Spacek wrote: >> On 20.5.2016 15:03, Martin Babinsky wrote: >>> On 04/28/2016 05:15 PM, Petr Spacek wrote: >>>> On 28.4.2016 14:52, Abhijeet Kasurde wrote: >>>>> Hi Petr, >>>>> >>>>> On 04/25/2016 08:28 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> ipa-nis-manage: add status option >>>>>> >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >>>>>> >>>>>> >>>>>> >>>>> Can you reword the error message here as well ? >>>>> >>>>> if len(args) != 1: >>>>> sys.exit("You must specify one action, either enable or >>>>> disable") >>>>> >>>>> Thanks, >>>>> Abhijeet Kasurde >>>> >>>> Good catch! >>>> >>>> >>>> >>> >>> Hi Petr, >>> >>> please use upstream ticket provided by Petr Vobornik[1] in the >>> commit message. >>> >>> Also I would rewrite >>> >>> """+ elif args[0] != "enable" and args[0] != "disable" and >>> args[0] != >>> "status": >>> >>> """ >>> >>> in a more pythonic way: >>> >>> " elif args[0] not in {"enable", "disable", "status"}:" >>> >>> Otherwise the patch works as expected. >>> >>> [1] https://fedorahosted.org/freeipa/ticket/5856 >> >> Here you go. >> > > Thanks, ACK. > Pushed to master: 9079d2f9c8a948702f1234e8337d8bf0dc291756 From mbasti at redhat.com Tue May 24 08:40:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 May 2016 10:40:16 +0200 Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set In-Reply-To: <1326069377.36201827.1463669218575.JavaMail.zimbra@redhat.com> References: <5735B5AD.9050803@redhat.com> <573C29DD.6070103@redhat.com> <394813195.35159567.1463572280337.JavaMail.zimbra@redhat.com> <573D989A.7020709@redhat.com> <1326069377.36201827.1463669218575.JavaMail.zimbra@redhat.com> Message-ID: <8c24f46a-1b55-ef00-a5de-9e401592b013@redhat.com> On 19.05.2016 16:46, Ganna Kaihorodova wrote: > Hello! > > Everything is ok, so ack > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer Pushed to master: d71de186cc4d942b2a1bb7fcd9677bfcedd86b26 > > > ----- Original Message ----- > From: "Lenka Doudova" > To: "Ganna Kaihorodova" > Cc: freeipa-devel at redhat.com > Sent: Thursday, May 19, 2016 12:42:34 PM > Subject: Re: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set > > > > On 05/18/2016 01:51 PM, Ganna Kaihorodova wrote: >> ----- Original Message ----- >> From: "Lenka Doudova" >> To: "Ganna Kaihorodova" >> Sent: Wednesday, May 18, 2016 10:37:49 AM >> Subject: Fwd: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set >> >> >> >> -------- Forwarded Message -------- >> Subject: [Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length >> higher than 255 cannot be set >> Date: Fri, 13 May 2016 13:08:29 +0200 >> From: Lenka Doudova >> To: freeipa-devel >> >> >> >> Patch attached. >> >> Lenka >> >> >> Hello, >> >> sorry, nack, because: >> 1. Tests doesn't clean up after performing. Max user name isn't returned original value. >> >> 2. pep8 errors: >> ./ipatests/test_xmlrpc/test_config_plugin.py:167:21: E126 continuation line over-indented for hanging indent >> ./ipatests/test_xmlrpc/test_config_plugin.py:170:17: E121 continuation line under-indented for hanging indent >> >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer > Hi, > > thanks for review, fixed patch attached. > > Lenka > From mbabinsk at redhat.com Tue May 24 08:44:39 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 May 2016 10:44:39 +0200 Subject: [Freeipa-devel] [PATCH 557] replica install: do not set CA renewal master flag In-Reply-To: References: Message-ID: <88dc2655-1147-5d78-108c-eb88abb5b199@redhat.com> On 05/24/2016 07:49 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Tue May 24 10:10:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 May 2016 12:10:45 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> Message-ID: <6a678451-e4ec-fb49-5050-a863693e2a5c@redhat.com> On 23.05.2016 07:44, Jan Cholasta wrote: > On 20.5.2016 15:32, Martin Basti wrote: >> >> >> On 20.05.2016 12:30, Petr Spacek wrote: >>> On 18.5.2016 12:43, Martin Basti wrote: >>>> >>>> On 12.05.2016 16:16, Martin Basti wrote: >>>>> >>>>> >>>>> On 12.05.2016 11:01, Martin Basti wrote: >>>>>> >>>>>> On 11.05.2016 09:41, Martin Basti wrote: >>>>>>> >>>>>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 >>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS >>>>>>>>>>>>>> related >>>>>>>>>>>>>> privileges >>>>>>>>>>>>>> >>>>>>>>>>>>>> DNS privileges are important for handling DNS locations >>>>>>>>>>>>>> which can be >>>>>>>>>>>>>> created without DNS servers in IPA topology. We will also >>>>>>>>>>>>>> need this >>>>>>>>>>>>>> privileges presented for future feature 'External DNS >>>>>>>>>>>>>> support' >>>>>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 >>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>>>>> objectclasses >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>>>>>>> index >>>>>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>>>>> booleanMatch >>>>>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN >>>>>>>>>>>>>> 'IPA v4.1' ) >>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch >>>>>>>>>>>>>> SINGLE-VALUE SYNTAX >>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>>>>>>> 'ipaLocation' DESC >>>>>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>>>>>>> SYNTAX >>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY >>>>>>>>>>>>>> integerMatch SYNTAX >>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>>>>>>> 'idnsRecord' >>>>>>>>>>>>>> DESC 'dns >>>>>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName >>>>>>>>>>>>>> MAY ( cn $ >>>>>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ >>>>>>>>>>>>>> aAAARecord $ >>>>>>>>>>>>>> a6Record $ >>>>>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ >>>>>>>>>>>>>> mXRecord $ >>>>>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ >>>>>>>>>>>>>> SigRecord $ >>>>>>>>>>>>>> KeyRecord >>>>>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ >>>>>>>>>>>>>> certRecord $ >>>>>>>>>>>>>> dNameRecord >>>>>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ >>>>>>>>>>>>>> DLVRecord $ >>>>>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>>>>>>> IPSECKEYRecord $ >>>>>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME >>>>>>>>>>>>>> 'idnsZone' DESC >>>>>>>>>>>>>> 'Zone >>>>>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ >>>>>>>>>>>>>> idnsSOAretry $ >>>>>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>>>>> idnsForwarders $ >>>>>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( >>>>>>>>>>>>>> idnsForwardPolicy $ >>>>>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>>>>>>> 'ipaDNSZone' >>>>>>>>>>>>>> SUP top >>>>>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>>>>>>> 'idnsSecKey' >>>>>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>>>>>>> idnsSecKeyCreated $ >>>>>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ >>>>>>>>>>>>>> idnsSecKeyActivate $ >>>>>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>>>>>>> idnsName >>>>>>>>>>>>>> ) MAY ( >>>>>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>>>>>>> there >>>>>>>>>>>>> will not be >>>>>>>>>>>>> any other object class on the location object (at least not >>>>>>>>>>>>> in the >>>>>>>>>>>>> beginning). >>>>>>>>>>>>> >>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( >>>>>>>>>>>>>> ipaLocation $ >>>>>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon Sep 17 >>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>>>>> >>>>>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command >>>>>>>>>>>>>> are just >>>>>>>>>>>>>> prototypes and does not provide any information about >>>>>>>>>>>>>> server (will be >>>>>>>>>>>>>> done later) >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>>>>> API.txt | 59 >>>>>>>>>>>>>> ++++++++++++++ >>>>>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>>>>> index >>>>>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>> --- a/VERSION >>>>>>>>>>>>>> +++ b/VERSION >>>>>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>>>>> # # >>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value >>>>>>>>>>>>>> to 255 >>>>>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>>>>> Needs rebase. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>> index >>>>>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>>>>> objectClass: top >>>>>>>>>>>>>> cn: etc >>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>> +changetype: add >>>>>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>>>>> +objectClass: top >>>>>>>>>>>>>> +cn: locations >>>>>>>>>>>>>> + >>>>>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>>>>> changetype: add >>>>>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>>>>> index >>>>>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>>>>> +default: objectClass: top >>>>>>>>>>>>>> +default: cn: locations >>>>>>>>>>>>> Ok. >>>>>>>>>>>>> >>>>>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>>>>>>> index >>>>>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>>>>> [...] >>>>>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>>>>> +IPA locations >>>>>>>>>>>>>> +""") + _(""" >>>>>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>>>>> + """ >>>>>>>>>>>>>> + IPA locations >>>>>>>>>>>>>> + """ >>>>>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>>>>> + managed_permissions = { >>>>>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>> + 'description', >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>> + }, >>>>>>>>>>>>>> + } >>>>>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>>>>>>> IMHO >>>>>>>>>>>>> this is >>>>>>>>>>>>> okay. >>>>>>>>>>>>> Less renames we support the better. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + takes_params = ( >>>>>>>>>>>>>> + DNSNameParam( >>>>>>>>>>>>>> + 'idnsname', >>>>>>>>>>>>>> + cli_name='name', >>>>>>>>>>>>>> + primary_key=True, >>>>>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>>>>> + # dns name must be relative, we will put it >>>>>>>>>>>>>> into >>>>>>>>>>>>>> middle of >>>>>>>>>>>>>> + # location domain name for location records >>>>>>>>>>>>>> + only_relative=True, >>>>>>>>>>>>>> + ), >>>>>>>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>>>>>>> labels >>>>>>>>>>>>> work - >>>>>>>>>>>>> but >>>>>>>>>>>>> this should automagically work as long as we are handling >>>>>>>>>>>>> DNS names >>>>>>>>>>>>> using >>>>>>>>>>>>> proper data types (not as strings). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> + Str( >>>>>>>>>>>>>> + 'description?', >>>>>>>>>>>>>> + label=_('Description'), >>>>>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>>>>> + ), >>>>>>>>>>>>> After discussion with Honza we will keep description as >>>>>>>>>>>>> single-value >>>>>>>>>>>>> in the >>>>>>>>>>>>> IPA framework and ignore that description attribute is >>>>>>>>>>>>> multi-value >>>>>>>>>>>>> in LDAP. >>>>>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>>>>> >>>>>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>>>>> + __doc__ = _('Modify information about an IPA >>>>>>>>>>>>>> location .') >>>>>>>>>>>>> This should say 'Modify description' because nothing else >>>>>>>>>>>>> can be >>>>>>>>>>>>> modified. >>>>>>>>>>>>> More specific text would hopefully stop some people from >>>>>>>>>>>>> looking for >>>>>>>>>>>>> rename >>>>>>>>>>>>> options. >>>>>>>>>>>> I disagree, this is general description about the modify >>>>>>>>>>>> command, see >>>>>>>>>>>> privilege-add it is the same as I made. I can see in future >>>>>>>>>>>> that we will >>>>>>>>>>>> forgot to update description of command if we add something >>>>>>>>>>>> new there. >>>>>>>>>>> This is really an invalid argument. >>>>>>>>>>> >>>>>>>>>>> "We must not touch XYZ because its documentation might become >>>>>>>>>>> obsolete in >>>>>>>>>>> future if we forget to update it!" :-) >>>>>>>>>>> >>>>>>>>>> How about inconsistency with description of older commands? I >>>>>>>>>> don't >>>>>>>>>> think that >>>>>>>>>> command description should describe attributes that are allowed >>>>>>>>>> to change. >>>>>>>>>> Allowed attributes are shown in --help output >>>>>>>>> I do not agree but push whatever variant you like, it costed too >>>>>>>>> much >>>>>>>>> already. >>>>>>>> NACK anyway. ipa-dns-install screams if you install a server >>>>>>>> without DNS and >>>>>>>> run ipa-dns-install later on: >>>>>>>> >>>>>>>> The log contains this: >>>>>>>> >>>>>>>> add objectClass: >>>>>>>> top >>>>>>>> groupofnames >>>>>>>> nestedgroup >>>>>>>> add cn: >>>>>>>> DNS Administrators >>>>>>>> add description: >>>>>>>> DNS Administrators >>>>>>>> adding new entry "cn=DNS >>>>>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ) >>>>>>>> SASL/EXTERNAL authentication started >>>>>>>> SASL username: >>>>>>>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>>>>> SASL SSF: 0 >>>>>>>> ldap_add: Already exists (68) >>>>>>>> >>>>>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>>>>>>> >>>>>>>> -Y >>>>>>>> >>>>>>>> EXTERNAL' returned non-zero exit status 68 >>>>>>>> >>>>>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>>>>> >>>>>> Updated patches attached >>>>>> >>>>>> I found that IDNA did not work with previous version, fixed + IDNA >>>>>> tests added >>>>>> >>>>>> >>>>> Fixed here, I sent wrong patches before >>>>> >>>>> >>>>> >>>>> >>>> More patches added, all patches are available here: >>>> https://github.com/bastiak/freeipa/tree/DNS-locations >>> Functional NACK >>> >>> location-show returns incorrect location weight for servers >>> >>> # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all >>> dn: >>> cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> >>> >>> Server name: vm-046.abc.idm.lab.eng.brq.redhat.com >>> Managed suffixes: domain >>> Min domain level: 0 >>> Max domain level: 1 >>> Location: l2 >>> Location weight: 200 >>> objectclass: ipalocationmember, ipaReplTopoManagedServer, top, >>> ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig >>> >>> # ipa location-show l2 >>> Location name: l2 >>> Description: Loc 2 >>> Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) >>> >>> - Did you forget --all somewhere? >> Nope, I forgot to put it to default attributes, nice catch, I will add >> test for it. >>> >>> Other than that I have only nitpick regarding error message: >>> ipa: ERROR: l2 cannot be deleted because IPA Server(s) >>> vm-046.abc.idm.lab.eng.brq.redhat.com requires it >>> >>> - Please unify singular/plural. >> This is how the exception is generated, so you can choose just label, so >> which label is the right? {'IPA server', 'IPA servers', 'IPA server(s)'} >> (I think server should be with lower cased 's') >> raise DependentEntry( >> label=_('IPA Server(s)'), >> key=keys[-1], >> dependent=location_members >> ) > > Use ngettext here to handle singular/plural correctly. It will fix only half of sentence, I put there just singular. > >>> >>> I did not require the code because Honza will surely look into details. > > "Allow to use non-Str attributes as keys for members": > > There is no actual API change, so don't bump VERSION. Bump version removed > > > "Remove CSV from from member params": > > Again, no actual API change, don't bump VERSION. > > CSV params should be removed completely. I have a patch in my drawer > which does exactly that, should I post it? > Removed Please post it. > > "DNS Locations: extend server-* command with locations": > > I don't think ipalocationweight should be in server-find. Searching > for servers by exact weight does not strike me as something useful. Or > is it? I agree, it will even not work with default location weight > > In server.normalize_location(), don't call location.get_dn() with > **options, as it contains server options, not location options. Also > you are calling kw.pop('ipalocation_location') twice, which is most > likely a bug. Fixed. It is not twice, it was called in different if-else branches, but I rewrote the code it should looks better now. > > In server_mod.pre_callback(), don't raise NotFound manually, but > rather use self.api.Object.location.handle_not_found(). > Changed > > Honza > Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0473.4-DNS-Locations-Always-create-DNS-related-privileges.patch Type: text/x-patch Size: 4774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0474.4-DNS-Locations-add-new-attributes-and-objectclasses.patch Type: text/x-patch Size: 4065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0475.4-DNS-Locations-location-commands.patch Type: text/x-patch Size: 14464 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0476.4-DNS-Locations-API-tests.patch Type: text/x-patch Size: 9331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0478.4-Allow-to-use-non-Str-attributes-as-keys-for-members.patch Type: text/x-patch Size: 29561 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0479.4-DNS-Locations-extend-server-command-with-locations.patch Type: text/x-patch Size: 10592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0480.4-DNS-Location-location-show-return-list-of-servers-in.patch Type: text/x-patch Size: 5186 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0481.4-DNS-Locations-prevent-to-remove-used-locations.patch Type: text/x-patch Size: 4056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0482.4-DNS-Locations-extend-tests-with-server-commands.patch Type: text/x-patch Size: 11837 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 24 11:07:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 May 2016 13:07:36 +0200 Subject: [Freeipa-devel] [PATCH 0146-0147] Server Roles: basic infrastructure In-Reply-To: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> References: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> Message-ID: <472ed85a-97b1-3c66-412b-265afe787dfc@redhat.com> On 05/19/2016 04:59 PM, Martin Babinsky wrote: > Patch 0146 implements lower-lever infrastructure for querying server > roles/attributes > > Patch 0147 are some basic tests slapped together for the `serverroles` > backend to ensure that it works as expected. > > The new/modified CLI commands specified in the design page [1] will be > coming soon. > > Also coming soon will be an interface to construct DNS records for each > role requested by Petr^2 and Martin^2 which I will start implement when > we agree on the backend implementation. > > https://fedorahosted.org/freeipa/ticket/5181 > > [1] https://www.freeipa.org/page/V4/Server_Roles#CLI > > > I have found some small errors in the code, attaching updated patch 146 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0146.1-Server-Roles-infrastructure-for-role-attribute-defin.patch Type: text/x-patch Size: 29094 bytes Desc: not available URL: From jcholast at redhat.com Tue May 24 12:56:09 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 May 2016 14:56:09 +0200 Subject: [Freeipa-devel] [PATCH 557] replica install: do not set CA renewal master flag In-Reply-To: <88dc2655-1147-5d78-108c-eb88abb5b199@redhat.com> References: <88dc2655-1147-5d78-108c-eb88abb5b199@redhat.com> Message-ID: <8c098dce-6291-d992-14d1-2e963ffff865@redhat.com> On 24.5.2016 10:44, Martin Babinsky wrote: > On 05/24/2016 07:49 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > > ACK Thanks. Pushed to: master: dea924ac8a04c923d96e04c4c40e253ae1ee857c ipa-4-2: 9d39d5e965d9207c04640f5f82cc9309013c4f75 ipa-4-3: 1b427d3c91bde7b2430e095745efca3f1273c144 -- Jan Cholasta From simo at redhat.com Tue May 24 13:18:11 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 May 2016 09:18:11 -0400 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160524074438.2xvpshhbrcnuphly@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> Message-ID: <1464095891.18643.206.camel@redhat.com> On Tue, 2016-05-24 at 10:44 +0300, Alexander Bokovoy wrote: > >Alternative technical approach is to add aliases to an host's > attribute and > >use it from there. I suspect that this would be less flexible and > less > >future-proof. > I don't see a need for alias-as-a-property. Instead, I'm interested in > having a possibility to have different keys, certificates, etc, on > objects used as aliases. This improves security position by splitting > the manager and the user of the resource. Can you elaborate on this ? Are you misusing the "alias" word here to just mean "host that have multiple identities" like clusters/load ballancers/proxies etc... ? Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Tue May 24 13:25:29 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 24 May 2016 15:25:29 +0200 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <1463088806.2785.23.camel@redhat.com> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> Message-ID: <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote: > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote: > > > This series of patches implements authentication indicator > > > insertion, > > > evaluation and management in FreeIPA. Besides these patches, two > > > other > > > patches are needed to round out support. > > > > > > First, we need a UI patch:?https://fedorahosted.org/freeipa/ticket/ > > > 5872 > > > > > > Second, we need a SSSD patch to handle the new case where multiple > > > responders are set (when either 1FA or 2FA can be used). > > > > I've already some initial work done here and will continue with your > > patches. > > > > > > > > Please note that the last patch in this series (0093) is untested > > > and > > > simply represents my desire to get these patches off of my hard > > > disk > > > before I take a long weekend. This patch also requires mrogers' > > > patch > > > 0001 (already merged to master). > > > > > > Also worthy of note is the need for an OID for the authentication > > > control. Hopefully Simo can assign this after we agree that this > > > control method is sufficient. One question I had was whether or not > > > it > > > would be possible to send the control only on UNIX sockets (0089; > > > report_auth_method()). > > > > > > Please review the approaches taken here. I plan to hit this hard on > > > Monday. > > > > I'm on a conference next week and currently busy preparing my > > presentation. I will give you feedback in the following week. > > Thanks! sorry for the delay, I was distracted because on some of my VMs OTP in general does not work anymore. I assume some issue, maybe with libverto on 32bit systems, but I'm still debugging. Nevertheless I was able to successfully test the patches in 64bits. Simo, please see OID assignment request below. > > The attached patches offer the latest version of the work. The only > major outstanding item that I see is OID assignment (which we can do > just before committing). > > I have tested the full stack both for appropriate approvals and denials > across all possible scenarios. In short it works. > > The easiest way to test this is as following: > > # After Clean Install of FreeIPA > $ kinit admin > > # Add a service allowed by either 1FA or 2FA > $ ipa service-add ANY/ipa.example.com > $ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab > > # Add a service allowed only by 2FA > $ ipa service-add OTP/ipa.example.com --auth-ind=otp > $ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab > > # Add the test user > $ ipa user-add test --user-auth-type=otp --user-auth-type=password > $ ipa passwd test > $ kinit test > > # Try to get tickets for the services > $ kvno ANY/ipa.example.com # Expected success > $ kvno OTP/ipa.example.com # Expected failure > > # Add a token and login with 2FA > $ ipa otptoken-add > $ kinit -T test # Log in with 2FA > > # Try to get tickets for the services > $ kvno ANY/ipa.example.com # > Expected success > $ kvno OTP/ipa.example.com # Expected success > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Wed, 4 May 2016 17:08:45 -0400 > Subject: [PATCH 5/5] Enable service authentication indicator management > For me the patch looks good, but it would be nice if someone more used to our usage of python can have a short look to see if all conventioens are met. ACK for the functionality. > From 356daafb001bd868f37f6f0b58338bd0c4da135c Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Sun, 21 Feb 2016 19:44:19 -0500 > Subject: [PATCH 4/5] Enable authentication indicators for OTP and RADIUS > ACK > From c33d0d2af5284a6eb5e50a4f5864f94fa8b3cf21 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Sun, 21 Feb 2016 19:43:52 -0500 > Subject: [PATCH 3/5] Return password-only preauth if passwords are allowed > ACK, on the client krb5_responder_list_questions() return both "password" and "otp" if the user is configured for both. Btw, what is the right way for a client to skip "otp" and only do "password" should something like krb5_responder_otp_set_answer(ctx, rctx, i, NULL, NULL); work ? > From 42768f63cdfd47ff3ac0bcdc228fb363b421e2b2 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Thu, 12 May 2016 15:10:47 -0400 > Subject: [PATCH 2/5] Ensure that ipa-otpd bind auths validate an OTP ACK. Depending on the user setting LDAP simple bind does work with password, password+token or both. > > Before this patch, if the user was configured for either OTP or password > it was possible to do a 1FA authentication through ipa-otpd. Because this > correctly respected the configuration, it is not a security error. > > However, once we begin to insert authentication indicators into the > Kerberos tickets, we cannot allow 1FA authentications through this > code path. Otherwise the ticket would contain a 2FA indicator when > only 1FA was actually performed. > > To solve this problem, we have ipa-otpd send a critical control during > the bind operation which informs the LDAP server that it *MUST* validate > an OTP token for authentication to be successful. Next, we implement > support for this control in the ipa-pwd-extop plugin. The end result is > that the bind operation will always fail if the control is present and > no OTP is validated. > > TODO: assign an OID > > https://fedorahosted.org/freeipa/ticket/433 > --- > daemons/ipa-otpd/bind.c | 5 ++++- > daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h | 3 +++ > daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 13 ++++++++----- > 3 files changed, 15 insertions(+), 6 deletions(-) > > diff --git a/daemons/ipa-otpd/bind.c b/daemons/ipa-otpd/bind.c > index c985ccd7e73c6e8182cafcef49fd9873ab3340ea..022525b786705b4f58f861bc3b0a745ab8693755 100644 > --- a/daemons/ipa-otpd/bind.c > +++ b/daemons/ipa-otpd/bind.c > @@ -26,9 +26,12 @@ > */ > > #include "internal.h" > +#include "../ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h" > > static void on_bind_writable(verto_ctx *vctx, verto_ev *ev) > { > + LDAPControl control = { OTP_REQUIRED_OID, {}, true }; > + LDAPControl *ctrls[] = { &control, NULL }; > struct otpd_queue *push = &ctx.stdio.responses; > const krb5_data *data; > struct berval cred; > @@ -55,7 +58,7 @@ static void on_bind_writable(verto_ctx *vctx, verto_ev *ev) > cred.bv_val = data->data; > cred.bv_len = data->length; > i = ldap_sasl_bind(verto_get_private(ev), item->user.dn, LDAP_SASL_SIMPLE, > - &cred, NULL, NULL, &item->msgid); > + &cred, ctrls, NULL, &item->msgid); > if (i != LDAP_SUCCESS) { > otpd_log_err(errno, "Unable to initiate bind: %s", ldap_err2string(i)); > verto_break(ctx.vctx); > diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > index 0b5cbc586118fe43b6e9ac823179174a7b3ba91e..184962095029edec15dac800721eb63b3353ec50 100644 > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > @@ -53,6 +53,9 @@ > */ > #define OTP_SYNC_REQUEST_OID "2.16.840.1.113730.3.8.10.6" > > +/* This control has no data. */ > +#define OTP_REQUIRED_OID "1.2.3.4.5.6.7.8.9" > + Simo, can you assign a proper OID for OTP_REQUIRED_OID ? > bool otpctrl_present(Slapi_PBlock *pb, const char *oid); > > From ec1c3e3ef0e3b06c6fd93b3d4709b55f28e12873 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Thu, 12 May 2016 14:57:29 -0400 > Subject: [PATCH 1/5] Rename syncreq.[ch] to otpctrl.[ch] > ... > index 98a97c4c9f6d2e6bf74f97fc93053b3aebbc7821..0b5cbc586118fe43b6e9ac823179174a7b3ba91e 100644 > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > @@ -37,9 +37,7 @@ > * All rights reserved. > * END COPYRIGHT BLOCK **/ > > - > -#ifndef SYNCREQ_H_ > -#define SYNCREQ_H_ > +#pragma once > I would prefer to keep the old way for now and discuss on the list if we should move to '#pragma once'. If we can get an agreement we can switch to '#pragma once' completely later. bye, Sumit From simo at redhat.com Tue May 24 13:26:41 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 May 2016 09:26:41 -0400 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <53483a63-35b5-4b84-a049-d20adec19ad1@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> <53483a63-35b5-4b84-a049-d20adec19ad1@redhat.com> Message-ID: <1464096401.18643.213.camel@redhat.com> On Tue, 2016-05-24 at 09:55 +0200, Petr Spacek wrote: > >> Alternative technical approach is to add aliases to an host's > attribute and > >> use it from there. I suspect that this would be less flexible and > less > >> future-proof. > > I don't see a need for alias-as-a-property. Instead, I'm interested > in > > having a possibility to have different keys, certificates, etc, on > > objects used as aliases. This improves security position by > splitting > > the manager and the user of the resource. > > I think that these two are not mutually exclusive. > > a) If you need separate keys (and the headache associated with it) use > a new host object. This is what we do today, and we need to keep it that way, we do not really have a choice, it's how it works, 1 identity 1 key, attaching multiple identities to a single object is just going to cause a lot of issues, and I do not see any benefit. > b) If you need to share keys use alias. No, you need to use a separate identity, that just happens to be common to multiple hosts. Please let's not conflate the "alias" concept with "additional identity". > Aliases could have other advantages, e.g. using diffrent DNS checks to > the user does not need to use --force just to create the alias. How ? > Right now we do not have the (b) option so code needs to use hacks > like the one you proposed above: > "we can add this one specifically as an option to existing code to > just follow managedBy" This is news to me. I suspect there is a language issue here ? > This is simply a hack and relies on user not forgetting to add option > --follow-managed-by (e.g.) when requesting a certificate. Not speaking > about automated processes requesting certs which would need own > heuristics to detect when the option should be supplied. What problem, exactly, are we trying to solve here ? For certs, if you have multiple identities you should really use SNI, not try to put all names of the world in one cert, but if you really want to cobble together a fake identity that uses multiple different names with the same key, you should do that manually, there is no automation that can read the admin mind. Note that "manually" may simply mean that the admin prepares appropriate reference attributes on the main object, but it still is a manual setting of "referrals" somewhere. > I really do not like these ad-hoc hacks and I'm looking for a > systematic solution. Is this just for certs ? Or something else ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue May 24 13:32:34 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 May 2016 16:32:34 +0300 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <1464095891.18643.206.camel@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> <1464095891.18643.206.camel@redhat.com> Message-ID: <20160524133234.rsg34kcsjhawcbed@redhat.com> On Tue, 24 May 2016, Simo Sorce wrote: >On Tue, 2016-05-24 at 10:44 +0300, Alexander Bokovoy wrote: >> >Alternative technical approach is to add aliases to an host's >> attribute and >> >use it from there. I suspect that this would be less flexible and >> less >> >future-proof. > >> I don't see a need for alias-as-a-property. Instead, I'm interested in >> having a possibility to have different keys, certificates, etc, on >> objects used as aliases. This improves security position by splitting >> the manager and the user of the resource. > >Can you elaborate on this ? >Are you misusing the "alias" word here to just mean "host that have >multiple identities" like clusters/load ballancers/proxies etc... ? Precisely. -- / Alexander Bokovoy From simo at redhat.com Tue May 24 14:03:51 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 May 2016 10:03:51 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1464098631.18643.216.camel@redhat.com> On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > > #define OTP_SYNC_REQUEST_OID "2.16.840.1.113730.3.8.10.6" > > > > +/* This control has no data. */ > > +#define OTP_REQUIRED_OID "1.2.3.4.5.6.7.8.9" > > + > > Simo, can you assign a proper OID for OTP_REQUIRED_OID ? @@ -446,6 +446,9 @@ IPA Extensions and Controls OIDs 2.16.840.1.113730.3.8.10.6 Token Resynchronization Control OID +2.16.840.1.113730.3.8.10.7 Token Required Control OID + Control to signal an OTP bind is required + -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue May 24 14:04:43 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 May 2016 10:04:43 -0400 Subject: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain In-Reply-To: <20160524133234.rsg34kcsjhawcbed@redhat.com> References: <20160519203932.tqyf5lpppyfde4na@redhat.com> <8f5486f8-a4c8-09f3-509b-dc523cf5f6c8@redhat.com> <20160520104334.cbzj2nc52lvm6sfn@redhat.com> <20160524065601.q337a2mq5qfocr6o@redhat.com> <20160524072653.okijne4ulaihutvm@redhat.com> <8f5f2dfe-a2f1-f321-9856-37f5adf50cd3@redhat.com> <20160524074438.2xvpshhbrcnuphly@redhat.com> <1464095891.18643.206.camel@redhat.com> <20160524133234.rsg34kcsjhawcbed@redhat.com> Message-ID: <1464098683.18643.217.camel@redhat.com> On Tue, 2016-05-24 at 16:32 +0300, Alexander Bokovoy wrote: > On Tue, 24 May 2016, Simo Sorce wrote: > >On Tue, 2016-05-24 at 10:44 +0300, Alexander Bokovoy wrote: > >> >Alternative technical approach is to add aliases to an host's > >> attribute and > >> >use it from there. I suspect that this would be less flexible and > >> less > >> >future-proof. > > > >> I don't see a need for alias-as-a-property. Instead, I'm interested in > >> having a possibility to have different keys, certificates, etc, on > >> objects used as aliases. This improves security position by splitting > >> the manager and the user of the resource. > > > >Can you elaborate on this ? > >Are you misusing the "alias" word here to just mean "host that have > >multiple identities" like clusters/load ballancers/proxies etc... ? > Precisely. then let's find a term that will not make comms, confusing, what about "Shared ID" ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue May 24 14:06:09 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 10:06:09 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1464098769.2783.9.camel@redhat.com> On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > ACK, on the client krb5_responder_list_questions() return both > "password" and "otp" if the user is configured for both. > > Btw, what is the right way for a client to skip "otp" and only do > "password" should something like krb5_responder_otp_set_answer(ctx, > rctx, i, NULL, NULL); work ? This is a good question. I raised the question with MIT. My suspicion is that you will need to set both a prompter and responder callback functions. The prompter function will always unconditionally return an error code. The responder will look at all questions and decide what to do. It will only answer the questions it wants to answer. In this case, I believe that preauth modules which have answered questions will function normally. Those without valid answers will fall back to the prompter. The prompter will return an error code. Thus, the modules with unanswered questions will error out and not send preauth data. > I would prefer to keep the old way for now and discuss on the list if > we > should move to '#pragma once'. If we can get an agreement we can > switch > to '#pragma once' completely later. I'll bring this up on a separate thread. From npmccallum at redhat.com Tue May 24 14:29:31 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 10:29:31 -0400 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once Message-ID: <1464100171.2783.13.camel@redhat.com> Using a pragma instead of guards is easier to write, less error prone and avoids name clashes (a source of very subtle bugs). This pragma is supported on almost all compilers, including all the compilers we care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0094-Migrate-from-ifndef-guards-to-pragma-once.patch Type: text/x-patch Size: 10458 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 24 14:33:46 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 10:33:46 -0400 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464100171.2783.13.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> Message-ID: <1464100426.2783.15.camel@redhat.com> On Tue, 2016-05-24 at 10:29 -0400, Nathaniel McCallum wrote: > Using a pragma instead of guards is easier to write, less error prone > and avoids name clashes (a source of very subtle bugs). This pragma > is supported on almost all compilers, including all the compilers we > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. I forgot to mention that I did not migrate the headers that are generated from asn1c as this would simply cause unnecessary code churn. From mkosek at redhat.com Tue May 24 14:55:07 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 May 2016 16:55:07 +0200 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464100171.2783.13.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> Message-ID: <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> On 05/24/2016 04:29 PM, Nathaniel McCallum wrote: > Using a pragma instead of guards is easier to write, less error prone > and avoids name clashes (a source of very subtle bugs). This pragma > is supported on almost all compilers, including all the compilers we > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. > > > Makes sense to me. I did not test, just saw a potential typo/omission: --- a/daemons/ipa-otpd/internal.h +++ b/daemons/ipa-otpd/internal.h @@ -20,9 +20,6 @@ * along with this program. If not, see . */ -#ifndef INTERNAL_H_ -#define INTERNAL_H_ - ... no pragma there. From cheimes at redhat.com Tue May 24 15:00:16 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 24 May 2016 17:00:16 +0200 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464100171.2783.13.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> Message-ID: <88477d25-64fe-9d30-0e1e-bceb580c0b6a@redhat.com> On 2016-05-24 16:29, Nathaniel McCallum wrote: > Using a pragma instead of guards is easier to write, less error prone > and avoids name clashes (a source of very subtle bugs). This pragma > is supported on almost all compilers, including all the compilers we > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. Good idea! LGTM It's a low risk change. Any issues with pragma once will show up during compilation. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From npmccallum at redhat.com Tue May 24 15:01:45 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 11:01:45 -0400 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> References: <1464100171.2783.13.camel@redhat.com> <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> Message-ID: <1464102105.2783.16.camel@redhat.com> On Tue, 2016-05-24 at 16:55 +0200, Martin Kosek wrote: > On 05/24/2016 04:29 PM, Nathaniel McCallum wrote: > > Using a pragma instead of guards is easier to write, less error > > prone > > and avoids name clashes (a source of very subtle bugs). This pragma > > is supported on almost all compilers, including all the compilers > > we > > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability. > > > > > > > > Makes sense to me. I did not test, just saw a potential > typo/omission: > > --- a/daemons/ipa-otpd/internal.h > +++ b/daemons/ipa-otpd/internal.h > @@ -20,9 +20,6 @@ > ? * along with this program.??If not, see s/>. > ? */ > > -#ifndef INTERNAL_H_ > -#define INTERNAL_H_ > - > > > ... no pragma there. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0094-1-Migrate-from-ifndef-guards-to-pragma-once.patch Type: text/x-patch Size: 10453 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 24 16:08:28 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 12:08:28 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1464106108.2783.25.camel@redhat.com> I have attached new versions of the patches. Comments below. On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote: > > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum > > > wrote: > > > > This series of patches implements authentication indicator > > > > insertion, > > > > evaluation and management in FreeIPA. Besides these patches, > > > > two > > > > other > > > > patches are needed to round out support. > > > > > > > > First, we need a UI patch:?https://fedorahosted.org/freeipa/tic > > > > ket/ > > > > 5872 > > > > > > > > Second, we need a SSSD patch to handle the new case where > > > > multiple > > > > responders are set (when either 1FA or 2FA can be used). > > > > > > I've already some initial work done here and will continue with > > > your > > > patches. > > > > > > > > > > > Please note that the last patch in this series (0093) is > > > > untested > > > > and > > > > simply represents my desire to get these patches off of my hard > > > > disk > > > > before I take a long weekend. This patch also requires mrogers' > > > > patch > > > > 0001 (already merged to master). > > > > > > > > Also worthy of note is the need for an OID for the > > > > authentication > > > > control. Hopefully Simo can assign this after we agree that > > > > this > > > > control method is sufficient. One question I had was whether or > > > > not > > > > it > > > > would be possible to send the control only on UNIX sockets > > > > (0089; > > > > report_auth_method()). > > > > > > > > Please review the approaches taken here. I plan to hit this > > > > hard on > > > > Monday. > > > > > > I'm on a conference next week and currently busy preparing my > > > presentation. I will give you feedback in the following week. > > > > Thanks! > > sorry for the delay, I was distracted because on some of my VMs OTP > in > general does not work anymore. I assume some issue, maybe with > libverto > on 32bit systems, but I'm still debugging. > > Nevertheless I was able to successfully test the patches in 64bits. > > Simo, please see OID assignment request below. > > > > > The attached patches offer the latest version of the work. The only > > major outstanding item that I see is OID assignment (which we can > > do > > just before committing). > > > > I have tested the full stack both for appropriate approvals and > > denials > > across all possible scenarios. In short it works. > > > > The easiest way to test this is as following: > > > > # After Clean Install of FreeIPA > > $ kinit admin > > > > # Add a service allowed by either 1FA or 2FA > > $ ipa service-add ANY/ipa.example.com > > $ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab > > > > # Add a service allowed only by 2FA > > $ ipa service-add OTP/ipa.example.com --auth-ind=otp > > $ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab > > > > # Add the test user > > $ ipa user-add test --user-auth-type=otp --user-auth-type=password > > $ ipa passwd test > > $ kinit test > > > > # Try to get tickets for the services > > $ kvno ANY/ipa.example.com # Expected success > > $ kvno OTP/ipa.example.com # Expected failure > > > > # Add a token and login with 2FA > > $ ipa otptoken-add > > $ kinit -T test # Log in with 2FA > > > > # Try to get tickets for the services > > $ kvno ANY/ipa.example.com # > > Expected success > > $ kvno OTP/ipa.example.com # Expected success > > > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 > > 2001 > > From: Nathaniel McCallum > > Date: Wed, 4 May 2016 17:08:45 -0400 > > Subject: [PATCH 5/5] Enable service authentication indicator > > management > > > > For me the patch looks good, but it would be nice if someone more > used > to our usage of python can have a short look to see if all > conventioens > are met. ACK for the functionality. I would like for us to merge the first four patches first and then concentrate on this one. In particular, the following issue needs to be discussed. We currently only have two, hard-coded indicator values: otp and radius. Thus, we use a StrEnum for this property. However, in the long-term, I'd like to have more flexibility; such as per-token indicators. This implies String. Is there some way to do StrEnum now and easily migrate to String later? I think this will break API. Thoughts? > > From 356daafb001bd868f37f6f0b58338bd0c4da135c Mon Sep 17 00:00:00 > > 2001 > > From: Nathaniel McCallum > > Date: Sun, 21 Feb 2016 19:44:19 -0500 > > Subject: [PATCH 4/5] Enable authentication indicators for OTP and > > RADIUS > > > > ACK > > > From c33d0d2af5284a6eb5e50a4f5864f94fa8b3cf21 Mon Sep 17 00:00:00 > > 2001 > > From: Nathaniel McCallum > > Date: Sun, 21 Feb 2016 19:43:52 -0500 > > Subject: [PATCH 3/5] Return password-only preauth if passwords are > > allowed > > > > ACK, on the client krb5_responder_list_questions() return both > "password" and "otp" if the user is configured for both. > > Btw, what is the right way for a client to skip "otp" and only do > "password" should something like krb5_responder_otp_set_answer(ctx, > rctx, i, NULL, NULL); work ? > > > From 42768f63cdfd47ff3ac0bcdc228fb363b421e2b2 Mon Sep 17 00:00:00 > > 2001 > > From: Nathaniel McCallum > > Date: Thu, 12 May 2016 15:10:47 -0400 > > Subject: [PATCH 2/5] Ensure that ipa-otpd bind auths validate an > > OTP > > ACK. Depending on the user setting LDAP simple bind does work with > password, password+token or both. > > > > > Before this patch, if the user was configured for either OTP or > > password > > it was possible to do a 1FA authentication through ipa-otpd. > > Because this > > correctly respected the configuration, it is not a security error. > > > > However, once we begin to insert authentication indicators into the > > Kerberos tickets, we cannot allow 1FA authentications through this > > code path. Otherwise the ticket would contain a 2FA indicator when > > only 1FA was actually performed. > > > > To solve this problem, we have ipa-otpd send a critical control > > during > > the bind operation which informs the LDAP server that it *MUST* > > validate > > an OTP token for authentication to be successful. Next, we > > implement > > support for this control in the ipa-pwd-extop plugin. The end > > result is > > that the bind operation will always fail if the control is present > > and > > no OTP is validated. > > > > TODO: assign an OID > > > > https://fedorahosted.org/freeipa/ticket/433 > > --- > > ?daemons/ipa-otpd/bind.c???????????????????????????|??5 ++++- > > ?daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h |??3 +++ > > ?daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 13 ++++++++--- > > -- > > ?3 files changed, 15 insertions(+), 6 deletions(-) > > > > diff --git a/daemons/ipa-otpd/bind.c b/daemons/ipa-otpd/bind.c > > index > > c985ccd7e73c6e8182cafcef49fd9873ab3340ea..022525b786705b4f58f861bc3 > > b0a745ab8693755 100644 > > --- a/daemons/ipa-otpd/bind.c > > +++ b/daemons/ipa-otpd/bind.c > > @@ -26,9 +26,12 @@ > > ? */ > > ? > > ?#include "internal.h" > > +#include "../ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h" > > ? > > ?static void on_bind_writable(verto_ctx *vctx, verto_ev *ev) > > ?{ > > +????LDAPControl control = { OTP_REQUIRED_OID, {}, true }; > > +????LDAPControl *ctrls[] = { &control, NULL }; > > ?????struct otpd_queue *push = &ctx.stdio.responses; > > ?????const krb5_data *data; > > ?????struct berval cred; > > @@ -55,7 +58,7 @@ static void on_bind_writable(verto_ctx *vctx, > > verto_ev *ev) > > ?????cred.bv_val = data->data; > > ?????cred.bv_len = data->length; > > ?????i = ldap_sasl_bind(verto_get_private(ev), item->user.dn, > > LDAP_SASL_SIMPLE, > > -???????????????????????&cred, NULL, NULL, &item->msgid); > > +???????????????????????&cred, ctrls, NULL, &item->msgid); > > ?????if (i != LDAP_SUCCESS) { > > ?????????otpd_log_err(errno, "Unable to initiate bind: %s", > > ldap_err2string(i)); > > ?????????verto_break(ctx.vctx); > > diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > index > > 0b5cbc586118fe43b6e9ac823179174a7b3ba91e..184962095029edec15dac8007 > > 21eb63b3353ec50 100644 > > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > @@ -53,6 +53,9 @@ > > ? */ > > ?#define OTP_SYNC_REQUEST_OID "2.16.840.1.113730.3.8.10.6" > > ? > > +/* This control has no data. */ > > +#define OTP_REQUIRED_OID "1.2.3.4.5.6.7.8.9" > > + > > Simo, can you assign a proper OID for OTP_REQUIRED_OID ? I have added the assigned OID now. > > ?bool otpctrl_present(Slapi_PBlock *pb, const char *oid); > > ? > > > From ec1c3e3ef0e3b06c6fd93b3d4709b55f28e12873 Mon Sep 17 00:00:00 > > 2001 > > From: Nathaniel McCallum > > Date: Thu, 12 May 2016 14:57:29 -0400 > > Subject: [PATCH 1/5] Rename syncreq.[ch] to otpctrl.[ch] > > > > ... > > > index > > 98a97c4c9f6d2e6bf74f97fc93053b3aebbc7821..0b5cbc586118fe43b6e9ac823 > > 179174a7b3ba91e 100644 > > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h > > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > @@ -37,9 +37,7 @@ > > ? * All rights reserved. > > ? * END COPYRIGHT BLOCK **/ > > ? > > - > > -#ifndef SYNCREQ_H_ > > -#define SYNCREQ_H_ > > +#pragma once > > ? > > I would prefer to keep the old way for now and discuss on the list if > we > should move to '#pragma once'. If we can get an agreement we can > switch > to '#pragma once' completely later. I have used guards in the latest patch. I now have another patch on the list to migrate all files from using guards to pragma. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 6254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Enable-authentication-indicators-for-OTP-and-RADIUS.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Return-password-only-preauth-if-passwords-are-allowe.patch Type: text/x-patch Size: 1676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Ensure-that-ipa-otpd-bind-auths-validate-an-OTP.patch Type: text/x-patch Size: 5577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rename-syncreq.-ch-to-otpctrl.-ch.patch Type: text/x-patch Size: 4960 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 24 16:21:43 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 12:21:43 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <1464106108.2783.25.camel@redhat.com> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> <1464106108.2783.25.camel@redhat.com> Message-ID: <1464106903.2783.27.camel@redhat.com> New versions again. This time I just removed the stray "TODO: assign OID" line in the commit as it no longer applies. On Tue, 2016-05-24 at 12:08 -0400, Nathaniel McCallum wrote: > I have attached new versions of the patches. Comments below. > > On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > > On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote: > > > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > > > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum > > > > wrote: > > > > > This series of patches implements authentication indicator > > > > > insertion, > > > > > evaluation and management in FreeIPA. Besides these patches, > > > > > two > > > > > other > > > > > patches are needed to round out support. > > > > > > > > > > First, we need a UI patch:?https://fedorahosted.org/freeipa/t > > > > > ic > > > > > ket/ > > > > > 5872 > > > > > > > > > > Second, we need a SSSD patch to handle the new case where > > > > > multiple > > > > > responders are set (when either 1FA or 2FA can be used). > > > > > > > > I've already some initial work done here and will continue with > > > > your > > > > patches. > > > > > > > > > > > > > > Please note that the last patch in this series (0093) is > > > > > untested > > > > > and > > > > > simply represents my desire to get these patches off of my > > > > > hard > > > > > disk > > > > > before I take a long weekend. This patch also requires > > > > > mrogers' > > > > > patch > > > > > 0001 (already merged to master). > > > > > > > > > > Also worthy of note is the need for an OID for the > > > > > authentication > > > > > control. Hopefully Simo can assign this after we agree that > > > > > this > > > > > control method is sufficient. One question I had was whether > > > > > or > > > > > not > > > > > it > > > > > would be possible to send the control only on UNIX sockets > > > > > (0089; > > > > > report_auth_method()). > > > > > > > > > > Please review the approaches taken here. I plan to hit this > > > > > hard on > > > > > Monday. > > > > > > > > I'm on a conference next week and currently busy preparing my > > > > presentation. I will give you feedback in the following week. > > > > > > Thanks! > > > > sorry for the delay, I was distracted because on some of my VMs OTP > > in > > general does not work anymore. I assume some issue, maybe with > > libverto > > on 32bit systems, but I'm still debugging. > > > > Nevertheless I was able to successfully test the patches in 64bits. > > > > Simo, please see OID assignment request below. > > > > > > > > The attached patches offer the latest version of the work. The > > > only > > > major outstanding item that I see is OID assignment (which we can > > > do > > > just before committing). > > > > > > I have tested the full stack both for appropriate approvals and > > > denials > > > across all possible scenarios. In short it works. > > > > > > The easiest way to test this is as following: > > > > > > # After Clean Install of FreeIPA > > > $ kinit admin > > > > > > # Add a service allowed by either 1FA or 2FA > > > $ ipa service-add ANY/ipa.example.com > > > $ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab > > > > > > # Add a service allowed only by 2FA > > > $ ipa service-add OTP/ipa.example.com --auth-ind=otp > > > $ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab > > > > > > # Add the test user > > > $ ipa user-add test --user-auth-type=otp --user-auth- > > > type=password > > > $ ipa passwd test > > > $ kinit test > > > > > > # Try to get tickets for the services > > > $ kvno ANY/ipa.example.com # Expected success > > > $ kvno OTP/ipa.example.com # Expected failure > > > > > > # Add a token and login with 2FA > > > $ ipa otptoken-add > > > $ kinit -T test # Log in with 2FA > > > > > > # Try to get tickets for the services > > > $ kvno ANY/ipa.example.com # > > > Expected success > > > $ kvno OTP/ipa.example.com # Expected success > > > > > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 > > > 2001 > > > From: Nathaniel McCallum > > > Date: Wed, 4 May 2016 17:08:45 -0400 > > > Subject: [PATCH 5/5] Enable service authentication indicator > > > management > > > > > > > For me the patch looks good, but it would be nice if someone more > > used > > to our usage of python can have a short look to see if all > > conventioens > > are met. ACK for the functionality. > > I would like for us to merge the first four patches first and then > concentrate on this one. > > In particular, the following issue needs to be discussed. We > currently > only have two, hard-coded indicator values: otp and radius. Thus, we > use a StrEnum for this property. However, in the long-term, I'd like > to > have more flexibility; such as per-token indicators. This implies > String. > > Is there some way to do StrEnum now and easily migrate to String > later? > I think this will break API. Thoughts? > > > > From 356daafb001bd868f37f6f0b58338bd0c4da135c Mon Sep 17 00:00:00 > > > 2001 > > > From: Nathaniel McCallum > > > Date: Sun, 21 Feb 2016 19:44:19 -0500 > > > Subject: [PATCH 4/5] Enable authentication indicators for OTP and > > > RADIUS > > > > > > > ACK > > > > > From c33d0d2af5284a6eb5e50a4f5864f94fa8b3cf21 Mon Sep 17 00:00:00 > > > 2001 > > > From: Nathaniel McCallum > > > Date: Sun, 21 Feb 2016 19:43:52 -0500 > > > Subject: [PATCH 3/5] Return password-only preauth if passwords > > > are > > > allowed > > > > > > > ACK, on the client krb5_responder_list_questions() return both > > "password" and "otp" if the user is configured for both. > > > > Btw, what is the right way for a client to skip "otp" and only do > > "password" should something like krb5_responder_otp_set_answer(ctx, > > rctx, i, NULL, NULL); work ? > > > > > From 42768f63cdfd47ff3ac0bcdc228fb363b421e2b2 Mon Sep 17 00:00:00 > > > 2001 > > > From: Nathaniel McCallum > > > Date: Thu, 12 May 2016 15:10:47 -0400 > > > Subject: [PATCH 2/5] Ensure that ipa-otpd bind auths validate an > > > OTP > > > > ACK. Depending on the user setting LDAP simple bind does work with > > password, password+token or both. > > > > > > > > Before this patch, if the user was configured for either OTP or > > > password > > > it was possible to do a 1FA authentication through ipa-otpd. > > > Because this > > > correctly respected the configuration, it is not a security > > > error. > > > > > > However, once we begin to insert authentication indicators into > > > the > > > Kerberos tickets, we cannot allow 1FA authentications through > > > this > > > code path. Otherwise the ticket would contain a 2FA indicator > > > when > > > only 1FA was actually performed. > > > > > > To solve this problem, we have ipa-otpd send a critical control > > > during > > > the bind operation which informs the LDAP server that it *MUST* > > > validate > > > an OTP token for authentication to be successful. Next, we > > > implement > > > support for this control in the ipa-pwd-extop plugin. The end > > > result is > > > that the bind operation will always fail if the control is > > > present > > > and > > > no OTP is validated. > > > > > > TODO: assign an OID > > > > > > https://fedorahosted.org/freeipa/ticket/433 > > > --- > > > ?daemons/ipa-otpd/bind.c???????????????????????????|??5 ++++- > > > ?daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h |??3 +++ > > > ?daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 13 ++++++++- > > > -- > > > -- > > > ?3 files changed, 15 insertions(+), 6 deletions(-) > > > > > > diff --git a/daemons/ipa-otpd/bind.c b/daemons/ipa-otpd/bind.c > > > index > > > c985ccd7e73c6e8182cafcef49fd9873ab3340ea..022525b786705b4f58f861b > > > c3 > > > b0a745ab8693755 100644 > > > --- a/daemons/ipa-otpd/bind.c > > > +++ b/daemons/ipa-otpd/bind.c > > > @@ -26,9 +26,12 @@ > > > ? */ > > > ? > > > ?#include "internal.h" > > > +#include "../ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h" > > > ? > > > ?static void on_bind_writable(verto_ctx *vctx, verto_ev *ev) > > > ?{ > > > +????LDAPControl control = { OTP_REQUIRED_OID, {}, true }; > > > +????LDAPControl *ctrls[] = { &control, NULL }; > > > ?????struct otpd_queue *push = &ctx.stdio.responses; > > > ?????const krb5_data *data; > > > ?????struct berval cred; > > > @@ -55,7 +58,7 @@ static void on_bind_writable(verto_ctx *vctx, > > > verto_ev *ev) > > > ?????cred.bv_val = data->data; > > > ?????cred.bv_len = data->length; > > > ?????i = ldap_sasl_bind(verto_get_private(ev), item->user.dn, > > > LDAP_SASL_SIMPLE, > > > -???????????????????????&cred, NULL, NULL, &item->msgid); > > > +???????????????????????&cred, ctrls, NULL, &item->msgid); > > > ?????if (i != LDAP_SUCCESS) { > > > ?????????otpd_log_err(errno, "Unable to initiate bind: %s", > > > ldap_err2string(i)); > > > ?????????verto_break(ctx.vctx); > > > diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > > b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > > index > > > 0b5cbc586118fe43b6e9ac823179174a7b3ba91e..184962095029edec15dac80 > > > 07 > > > 21eb63b3353ec50 100644 > > > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > > @@ -53,6 +53,9 @@ > > > ? */ > > > ?#define OTP_SYNC_REQUEST_OID "2.16.840.1.113730.3.8.10.6" > > > ? > > > +/* This control has no data. */ > > > +#define OTP_REQUIRED_OID "1.2.3.4.5.6.7.8.9" > > > + > > > > Simo, can you assign a proper OID for OTP_REQUIRED_OID ? > > I have added the assigned OID now. > > > > ?bool otpctrl_present(Slapi_PBlock *pb, const char *oid); > > > ? > > > > > From ec1c3e3ef0e3b06c6fd93b3d4709b55f28e12873 Mon Sep 17 00:00:00 > > > 2001 > > > From: Nathaniel McCallum > > > Date: Thu, 12 May 2016 14:57:29 -0400 > > > Subject: [PATCH 1/5] Rename syncreq.[ch] to otpctrl.[ch] > > > > > > > ... > > > > > index > > > 98a97c4c9f6d2e6bf74f97fc93053b3aebbc7821..0b5cbc586118fe43b6e9ac8 > > > 23 > > > 179174a7b3ba91e 100644 > > > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h > > > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/otpctrl.h > > > @@ -37,9 +37,7 @@ > > > ? * All rights reserved. > > > ? * END COPYRIGHT BLOCK **/ > > > ? > > > - > > > -#ifndef SYNCREQ_H_ > > > -#define SYNCREQ_H_ > > > +#pragma once > > > ? > > > > I would prefer to keep the old way for now and discuss on the list > > if > > we > > should move to '#pragma once'. If we can get an agreement we can > > switch > > to '#pragma once' completely later. > > I have used guards in the latest patch. I now have another patch on > the > list to migrate all files from using guards to pragma. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 6254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Enable-authentication-indicators-for-OTP-and-RADIUS.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Return-password-only-preauth-if-passwords-are-allowe.patch Type: text/x-patch Size: 1676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Ensure-that-ipa-otpd-bind-auths-validate-an-OTP.patch Type: text/x-patch Size: 5556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rename-syncreq.-ch-to-otpctrl.-ch.patch Type: text/x-patch Size: 4960 bytes Desc: not available URL: From npmccallum at redhat.com Tue May 24 16:25:38 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 May 2016 12:25:38 -0400 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464102105.2783.16.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> <1464102105.2783.16.camel@redhat.com> Message-ID: <1464107138.2783.28.camel@redhat.com> On Tue, 2016-05-24 at 11:01 -0400, Nathaniel McCallum wrote: > On Tue, 2016-05-24 at 16:55 +0200, Martin Kosek wrote: > > On 05/24/2016 04:29 PM, Nathaniel McCallum wrote: > > > Using a pragma instead of guards is easier to write, less error > > > prone > > > and avoids name clashes (a source of very subtle bugs). This > > > pragma > > > is supported on almost all compilers, including all the compilers > > > we > > > care about: https://en.wikipedia.org/wiki/Pragma_once#Portability > > > . > > > > > > > > > > > > > Makes sense to me. I did not test, just saw a potential > > typo/omission: > > > > --- a/daemons/ipa-otpd/internal.h > > +++ b/daemons/ipa-otpd/internal.h > > @@ -20,9 +20,6 @@ > > ? * along with this program.??If not, see > se > > s/>. > > ? */ > > > > -#ifndef INTERNAL_H_ > > -#define INTERNAL_H_ > > - > > > > > > ... no pragma there. > > Fixed. Here is a new version with a slightly edited commit message (just to confirm that we don't edit the autogenerated files). -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Migrate-from-ifndef-guards-to-pragma-once.patch Type: text/x-patch Size: 10522 bytes Desc: not available URL: From mbasti at redhat.com Tue May 24 18:55:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 May 2016 20:55:08 +0200 Subject: [Freeipa-devel] [PATCH 0146-0147] Server Roles: basic infrastructure In-Reply-To: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> References: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> Message-ID: <86e9b59a-889a-b755-346a-29edfd324286@redhat.com> On 19.05.2016 16:59, Martin Babinsky wrote: > Patch 0146 implements lower-lever infrastructure for querying server > roles/attributes > > Patch 0147 are some basic tests slapped together for the `serverroles` > backend to ensure that it works as expected. > > The new/modified CLI commands specified in the design page [1] will be > coming soon. > > Also coming soon will be an interface to construct DNS records for > each role requested by Petr^2 and Martin^2 which I will start > implement when we agree on the backend implementation. > > https://fedorahosted.org/freeipa/ticket/5181 > > [1] https://www.freeipa.org/page/V4/Server_Roles#CLI > > > Hello, I have a few comments 0) I'm afraid that your docstrings contains docstest syntax and it may fail 1) IIRC the factory should return just one particular object, not dict of objects, should be these function called differently? +def role_factory(api_instance): + """ + return a dict of server role instances keyed by lower-cased role name + """ + + return {key: role_cls(api_instance) for key, role_cls in + role_registry.items()} + + +def attribute_factory(api_instance): + """ + return a dict of server attribute instances keyed by lower-cased attribute + name + """ + return {key: attr_cls(api_instance) for key, attr_cls in + attribute_registry.items()} 2) +class LDAPBasedProperty(object): .... + def __init__(self, api_instance): + self.api = api_instance + self.ldap_conn = self.api.Backend.ldap2 self.ldap_conn, this may bite us later, ldap2 may not exist when object is created an thus this may cause the AttributeErrors. IMO in method there should be used directly ldap = self.api.Backend.ldap2 ldap.search() Otherwise you will not be able to create objects without connected LDAP (just future thinking) we had simillar issue in DNS that in upgrade code it was failing 3) +class BaseServerAttribute(LDAPBasedProperty): ... + # pylint: disable=not-callable + self.role_instance = self.associated_role( + api_instance) + # pylint: enable=not-callable I don't like this, twice; don't disable pylint, do some check in constructor if associated_role was defined Something like if not isinstance(self.associated_role, ): raise TypeError(Define role) Or put as default ABCMetaclass (BaseServerRole), that should blow up 4) ipa_config_string_value = None IMO this should be empty list (in the same class) 5) associated_service_name = None IMO there should be check in constructor, that this variable is defined with something else than None, to avoid hard to not ot nice to debug errors 6) @property def providers(self): """ :returns: list of masters providing the attribute. In the case of singular attributes returns a list containing single object """ try: entries = self.search(self.search_base) except errors.EmptyResult: return set() I'm afraid this may break sometimes, because what exception is raised depends on implementation of search(), so IMO would be better to catch exception in search() and return set() from search method, or define new exception which should be used for this case and document it in search() method 7) class ServiceBasedRole(BaseServerRole): ... enabled = all( value in entry.get(attribute, []) for (attribute, value) in self.enabled_attrs_value.items() ) Here ipaConfigString is case insensitive, so I'm afraid that this may not work in cases that there is value 'enabledservice' instead of 'enabledService' But if you are sure that this cannot happen in IPA, we can leave it as is, otherwise you have to distinguish case sensitive and case insensitive attrs IMO in this case generalization may cause more harm than gain. IMO should be better to create extra method (maybe abstract) which will return state if service is enabled or not in LDAP. Or create default implementation that compares just ipaConfigScript and subclasses should call it via super() and add it owns check by super 8) class ServiceBasedRole(BaseServerRole): ... try: entries = self.search(search_base) services = [self._get_service(e) for e in entries] self._validate_component_services(services) return (ENABLED if self._are_services_enabled(services) else CONFIGURED) except errors.EmptyResult: return ABSENT Same as 6). IMO you can put there else statement as part of first try-except block 9) class ServiceBasedRole(BaseServerRole): ... @property def providers(self): There is no except catching EmptyResults (not needed if you reimplement it as I suggested above) 10) Nitpick alert for master in services_by_master: services = services_by_master[master] for master, services in services_by_master.items() (or using six) is IMO better 11) providers = [] for master in services_by_master: services = services_by_master[master] self._validate_component_services(services) if all(s.enabled for s in services): providers.append(master) I was quite puzzled with this code until I realized that you are actually finding just subset of services that belongs to a role, not all services on particular master, maybe comment may help or variable naming also please use _are_services_enabled() instead of copy-paste 12) def obj_pkey_from_hostname This is used just once and it just return param as result without any change, do you have any future plans with it? If not then please remove it. 13) ************* Module ipaserver.plugins.serverroles ipaserver/plugins/serverroles.py:579: [W0223(abstract-method), ADTrustBasedRole] Method 'fqdn_from_entry' is abstract in class 'MembershipBasedRole' but is not overridden) IMO there is unneeded inheritance, keep number of levels as low as possible, IMO ADTrustAgent can inherit directly from MembershipBasedRole and implement group_dn property, because ADTrustBasedRole is used just once. 14) I'm not sure if self.group_dn express the right thing, because class ADTrustBasedRole(MembershipBasedRole): @property def group_dn(self): return DN( ('cn', 'adtrust agents'), ('cn', 'sysaccounts'), ('cn', 'etc'), self.api.env.basedn) It is account not group, I'm not sure what get_dn should express 15) I'm not a big fan of MembershipBasedRole class, if this circus is done just because ADTrustAgent service is nonstandard, I would rather have single implementation of that magic instead of having baseclass that is never used for anything else and wasting time with implementation of a general solution. I don't like that in current implementation you mixed show commands, direct ldap searches, for the same thing, and also using 'api.env.container_*' does not look safe for me as we do not enforce the exact format and it may break in future or with different objects. 16) class serverroles(Backend): Please don't do any lower() operation with options here, it should be just obj_type="role" def _get_obj_store(self, obj_type="Role"): if obj_type.lower() == "role": this is internal API so in case that somebody does not meet the lower case just raise exception violently The rest tomorrow :) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Wed May 25 07:11:47 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 25 May 2016 09:11:47 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin In-Reply-To: <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> References: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> Message-ID: <0630f6c9-9d94-015b-f689-51ce0f3005d3@redhat.com> LGTM, could you please just add the ticket to the commit message? On 05/20/2016 04:28 PM, Martin Basti wrote: > > > > On 20.05.2016 15:03, Martin Basti wrote: >> The removed code is unused for long time. >> >> Patch attached. >> >> >> > https://fedorahosted.org/freeipa/attachment/ticket/5899/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Wed May 25 07:58:18 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 25 May 2016 09:58:18 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA In-Reply-To: References: Message-ID: <5d97feaa-80bc-0d85-8739-63197df58c7e@redhat.com> On 05/20/2016 03:00 PM, Martin Basti wrote: > > On 19.05.2016 13:34, Stanislav Laznicka wrote: >> >> Also, I tried to upgrade from 4.2.4 to 4.3.1 and it seems that it >> might be necessary to start the service even earlier in the upgrade >> logic. Attached is the trace that occurred during the upgrade. >> >> I sent the whole log earlier accidentally, hopefully it will not >> arrive here as well. >> >> On 05/19/2016 11:10 AM, Stanislav Laznicka wrote: >>> >>> NACK, see my comments below >>> >>> + # following upgrade steps require running CA >>> This is a nitpicky nitpick but could you please change this comment >>> for # the following ... >>> Took me a while to understand what you were trying to say here. >>> + if ca_running and not ca.is_running(): >>> + ca.stop('pki-tomcat') >>> + elif not ca_running and ca.is_running(): >>> + ca.start('pki-tomcat') >>> + >>> You should swap ca.stop and ca.start here, you're stopping the >>> service when it's stopped and starting it when it's already running. > Shame, shame, shame on me. > >>> >>> On 05/12/2016 04:34 PM, Martin Basti wrote: >>>> Patch attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5868 >>>> >>>> >>>> >>> >>> >>> >> > > I moved starting of CA to the earlier phase and swapped start/stop to > correct order. > > Patch attached. Seems to work as expected now. ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Wed May 25 08:03:09 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 25 May 2016 10:03:09 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: References: Message-ID: <20160525080309.GE29312@redhat.com> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: > > - I start working on a specific issue and decide to create a branch on my > git repository (on my laptop) > git clone git://git.fedorahosted.org/git/freeipa.git > git branch -b issue This likely needs to be git checkout -b issue > - When the tests are ok and I want to submit a patch, can I stay on the > branch "issue" to create the patch or should I merge first with the main > branch? If a merge is required, is it recommended to pull then merge or > merge then pull? As mentioned by Martin, you are looking for rebase, not merge. Rebase will re-create commits from the branch on top of other branch (master, most likely), omitting changes that got to master in the mean time, and giving you chance to resolve conflicts with whatever other changes might have gone to master, so that others have as clean experience as possible. If you look at FreeIPA's history (I like gitk for that), you will see that merge commits are very rarely used. The reason for keeping the history linear (and thus rebasing on master often) is that it forces the author to be explicit about the diffs, plus git tools for introspecting history often choke on parallel branches that get merged. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Wed May 25 09:46:03 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 May 2016 11:46:03 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: <20160525080309.GE29312@redhat.com> References: <20160525080309.GE29312@redhat.com> Message-ID: <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> On 05/25/2016 10:03 AM, Jan Pazdziora wrote: > On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: >> >> - I start working on a specific issue and decide to create a branch on my >> git repository (on my laptop) >> git clone git://git.fedorahosted.org/git/freeipa.git >> git branch -b issue > > This likely needs to be > > git checkout -b issue > >> - When the tests are ok and I want to submit a patch, can I stay on the >> branch "issue" to create the patch or should I merge first with the main >> branch? If a merge is required, is it recommended to pull then merge or >> merge then pull? > > As mentioned by Martin, you are looking for rebase, not merge. Rebase > will re-create commits from the branch on top of other branch (master, > most likely), omitting changes that got to master in the mean time, > and giving you chance to resolve conflicts with whatever other changes > might have gone to master, so that others have as clean experience as > possible. > > If you look at FreeIPA's history (I like gitk for that), you will see > that merge commits are very rarely used. The reason for keeping the > history linear (and thus rebasing on master often) is that it forces > the author to be explicit about the diffs, plus git tools for > introspecting history often choke on parallel branches that get > merged. +1, we want to keep that. For example, even though we already had some discussions about adopting github workflow (pull reuqests) as the main vehicle for patch reviews, we would still prefer to avoid merging and keep rebasing - the history is much cleaner that way. From cheimes at redhat.com Wed May 25 09:55:08 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 25 May 2016 11:55:08 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> References: <20160525080309.GE29312@redhat.com> <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> Message-ID: On 2016-05-25 11:46, Martin Kosek wrote: > On 05/25/2016 10:03 AM, Jan Pazdziora wrote: >> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: >>> >>> - I start working on a specific issue and decide to create a branch on my >>> git repository (on my laptop) >>> git clone git://git.fedorahosted.org/git/freeipa.git >>> git branch -b issue >> >> This likely needs to be >> >> git checkout -b issue >> >>> - When the tests are ok and I want to submit a patch, can I stay on the >>> branch "issue" to create the patch or should I merge first with the main >>> branch? If a merge is required, is it recommended to pull then merge or >>> merge then pull? >> >> As mentioned by Martin, you are looking for rebase, not merge. Rebase >> will re-create commits from the branch on top of other branch (master, >> most likely), omitting changes that got to master in the mean time, >> and giving you chance to resolve conflicts with whatever other changes >> might have gone to master, so that others have as clean experience as >> possible. >> >> If you look at FreeIPA's history (I like gitk for that), you will see >> that merge commits are very rarely used. The reason for keeping the >> history linear (and thus rebasing on master often) is that it forces >> the author to be explicit about the diffs, plus git tools for >> introspecting history often choke on parallel branches that get >> merged. > > +1, we want to keep that. For example, even though we already had some > discussions about adopting github workflow (pull reuqests) as the main vehicle > for patch reviews, we would still prefer to avoid merging and keep rebasing - > the history is much cleaner that way. +1 against merge commits A couple of months ago github introduced a new option. The green merge button can be configured to either do a merge commit, squash all commits in the branch or both. https://help.github.com/articles/about-pull-request-merge-squashing/ I guess we can use squashed merges for the majority of simple PRs. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Wed May 25 10:00:10 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 May 2016 12:00:10 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: References: <20160525080309.GE29312@redhat.com> <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> Message-ID: On 05/25/2016 11:55 AM, Christian Heimes wrote: > On 2016-05-25 11:46, Martin Kosek wrote: >> On 05/25/2016 10:03 AM, Jan Pazdziora wrote: >>> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: >>>> >>>> - I start working on a specific issue and decide to create a branch on my >>>> git repository (on my laptop) >>>> git clone git://git.fedorahosted.org/git/freeipa.git >>>> git branch -b issue >>> >>> This likely needs to be >>> >>> git checkout -b issue >>> >>>> - When the tests are ok and I want to submit a patch, can I stay on the >>>> branch "issue" to create the patch or should I merge first with the main >>>> branch? If a merge is required, is it recommended to pull then merge or >>>> merge then pull? >>> >>> As mentioned by Martin, you are looking for rebase, not merge. Rebase >>> will re-create commits from the branch on top of other branch (master, >>> most likely), omitting changes that got to master in the mean time, >>> and giving you chance to resolve conflicts with whatever other changes >>> might have gone to master, so that others have as clean experience as >>> possible. >>> >>> If you look at FreeIPA's history (I like gitk for that), you will see >>> that merge commits are very rarely used. The reason for keeping the >>> history linear (and thus rebasing on master often) is that it forces >>> the author to be explicit about the diffs, plus git tools for >>> introspecting history often choke on parallel branches that get >>> merged. >> >> +1, we want to keep that. For example, even though we already had some >> discussions about adopting github workflow (pull reuqests) as the main vehicle >> for patch reviews, we would still prefer to avoid merging and keep rebasing - >> the history is much cleaner that way. > > +1 against merge commits > > A couple of months ago github introduced a new option. The green merge > button can be configured to either do a merge commit, squash all commits > in the branch or both. > https://help.github.com/articles/about-pull-request-merge-squashing/ Interesting. Do you know why github forces the squashing? It would be better if we can simply have the commits rebased and applied to master branch. > I guess we can use squashed merges for the majority of simple PRs. I expect we will anyway end up with extending "ipatool push" command to do some magic with github API, Trac and Bugzilla as we are used now. Except that it won't accept list of patches in file, but rathe a link/PR number. But this is of course up to dicsussion. Martin From cheimes at redhat.com Wed May 25 10:17:18 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 25 May 2016 12:17:18 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: References: <20160525080309.GE29312@redhat.com> <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> Message-ID: <073f4d99-9c05-2e62-8d55-ab1818de09ed@redhat.com> On 2016-05-25 12:00, Martin Kosek wrote: > On 05/25/2016 11:55 AM, Christian Heimes wrote: >> On 2016-05-25 11:46, Martin Kosek wrote: >>> On 05/25/2016 10:03 AM, Jan Pazdziora wrote: >>>> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote: >>>>> >>>>> - I start working on a specific issue and decide to create a branch on my >>>>> git repository (on my laptop) >>>>> git clone git://git.fedorahosted.org/git/freeipa.git >>>>> git branch -b issue >>>> >>>> This likely needs to be >>>> >>>> git checkout -b issue >>>> >>>>> - When the tests are ok and I want to submit a patch, can I stay on the >>>>> branch "issue" to create the patch or should I merge first with the main >>>>> branch? If a merge is required, is it recommended to pull then merge or >>>>> merge then pull? >>>> >>>> As mentioned by Martin, you are looking for rebase, not merge. Rebase >>>> will re-create commits from the branch on top of other branch (master, >>>> most likely), omitting changes that got to master in the mean time, >>>> and giving you chance to resolve conflicts with whatever other changes >>>> might have gone to master, so that others have as clean experience as >>>> possible. >>>> >>>> If you look at FreeIPA's history (I like gitk for that), you will see >>>> that merge commits are very rarely used. The reason for keeping the >>>> history linear (and thus rebasing on master often) is that it forces >>>> the author to be explicit about the diffs, plus git tools for >>>> introspecting history often choke on parallel branches that get >>>> merged. >>> >>> +1, we want to keep that. For example, even though we already had some >>> discussions about adopting github workflow (pull reuqests) as the main vehicle >>> for patch reviews, we would still prefer to avoid merging and keep rebasing - >>> the history is much cleaner that way. >> >> +1 against merge commits >> >> A couple of months ago github introduced a new option. The green merge >> button can be configured to either do a merge commit, squash all commits >> in the branch or both. >> https://help.github.com/articles/about-pull-request-merge-squashing/ > > Interesting. Do you know why github forces the squashing? It would be better if > we can simply have the commits rebased and applied to master branch. I don't know why github either forces merge commits or a single squashed commit. If I would have to guess, I would assume it has philosophical reasons. It took many years to get github to add an alternative to merge commits. A single commit of a squashed branch is rather similar to a merge commit. >> I guess we can use squashed merges for the majority of simple PRs. > > I expect we will anyway end up with extending "ipatool push" command to do some > magic with github API, Trac and Bugzilla as we are used now. Except that it > won't accept list of patches in file, but rathe a link/PR number. But this is > of course up to dicsussion. That makes sense. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Wed May 25 10:30:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 12:30:06 +0200 Subject: [Freeipa-devel] [PATCH 0110] DNS: Warn if forwarding policy conflicts with automatic empty zone In-Reply-To: <44b60702-e8cb-364f-39bc-114404349972@redhat.com> References: <44b60702-e8cb-364f-39bc-114404349972@redhat.com> Message-ID: On 04.05.2016 10:43, Petr Spacek wrote: > Hello, > > DNS: Warn if forwarding policy conflicts with automatic empty zones > > Forwarding policy "first" or "none" may conflicts with some automatic empty > zones. Queries for zones specified by RFC 6303 will ignore > forwarding and recursion and always result in NXDOMAIN answers. > > This is not detected and warned about. Global forwarding is equivalent > to forward zone ".". > > Example: > Forward zone 1.10.in-addr.arpa with policy "first" > will not forward anything because BIND will automatically prefer > automatic empty zone "10.in-addr.arpa." which is authoritative. > > https://fedorahosted.org/freeipa/ticket/5710 > > > This is last patch in the series so the ticket can be closed when all relevant > patches are pushed. > > > You forgot to update tests _____________________________________________________________________ test_dns.test_command[0087: dnsconfig_mod: Update global DNS settings] ______________________________________________________________________ self = , index = 87 declarative_test_definition = {'command': ('dnsconfig_mod', [], {'idnsforwarders': ['172.16.31.80'], 'version': '2.166'}), 'desc': 'Update global DN...arders': ['172.16.31.80']}, 'summary': None, 'value': None}, 'nice': '0087: dnsconfig_mod: Update global DNS settings'} def test_command(self, index, declarative_test_definition): """Run an individual test The arguments are provided by the pytest plugin. """ if callable(declarative_test_definition): declarative_test_definition(self) else: > self.check(**declarative_test_definition) test_xmlrpc/xmlrpc_test.py:313: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ test_xmlrpc/xmlrpc_test.py:325: in check self.check_output(nice, cmd, args, options, expected, extra_check) test_xmlrpc/xmlrpc_test.py:368: in check_output assert_deepequal(expected, got, nice) util.py:361: in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ expected = [{'code': 13006, 'message': at 0x7fcef426c758>, 'name': 'DNSServerValidationWarning', 'type': 'warning'}] got = [{'code': 13021, 'message': "Forwarding policy conflicts with some automatic empty zones. Queries for zones specified ...': The DNS operation timed out after 10.0008428097 seconds.", 'name': 'DNSServerValidationWarning', 'type': 'warning'}] doc = '0087: dnsconfig_mod: Update global DNS settings', stack = ('messages',) def assert_deepequal(expected, got, doc='', stack=tuple()): """ Recursively check for type and equality. If a value in expected is callable then it will used as a callback to test for equality on the got value. The callback is passed the got value and returns True if equal, False otherwise. If the tests fails, it will raise an ``AssertionError`` with detailed information, including the path to the offending value. For example: >>> expected = [u'Hello', dict(world=u'how are you?')] >>> got = [u'Hello', dict(world='how are you?')] >>> expected == got True >>> assert_deepequal(expected, got, doc='Testing my nested data') Traceback (most recent call last): ... AssertionError: assert_deepequal: type(expected) is not type(got). Testing my nested data type(expected) = type(got) = expected = u'how are you?' got = 'how are you?' path = (0, 'world') Note that lists and tuples are considered equivalent, and the order of their elements does not matter. """ if isinstance(expected, tuple): expected = list(expected) if isinstance(got, tuple): got = list(got) if isinstance(expected, DN): if isinstance(got, six.string_types): got = DN(got) if not (isinstance(expected, Fuzzy) or callable(expected) or type(expected) is type(got)): raise AssertionError( TYPE % (doc, type(expected), type(got), expected, got, stack) ) if isinstance(expected, (list, tuple)): if len(expected) != len(got): raise AssertionError( > LEN % (doc, len(expected), len(got), expected, got, stack) ) E AssertionError: assert_deepequal: list length mismatch. E 0087: dnsconfig_mod: Update global DNS settings E len(expected) = 1 E len(got) = 2 E expected = [{u'message': at 0x7fcef426c758>, u'code': 13006, u'type': u'warning', u'name': u'DNSServerValidationWarning'}] E got = [{u'message': u"Forwarding policy conflicts with some automatic empty zones. Queries for zones specified by RFC 6303 will ignore forwarding and recursion and always result in NXDOMAIN answers. To override this behavior use forward policy 'only'.", u'code': 13021, u'type': u'warning', u'name': u'DNSForwardPolicyConflictWithEmptyZone'}, {u'message': u"DNS server 172.16.31.80: query '. SOA': The DNS operation timed out after 10.0008428097 seconds.", u'code': 13006, u'type': u'warning', u'name': u'DNSServerValidationWarning'}] E path = (u'messages',) util.py:332: AssertionError -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed May 25 10:50:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 12:50:22 +0200 Subject: [Freeipa-devel] [PATCH 0104-0109] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> Message-ID: <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> On 20.05.2016 12:19, Petr Spacek wrote: > On 11.5.2016 12:08, Martin Basti wrote: >> >> On 03.05.2016 14:59, Petr Spacek wrote: >>> Hello, >>> >>> DNS upgrade: change forwarding policy to "only" if private IPs are used. >>> >>> https://fedorahosted.org/freeipa/ticket/5710 >>> >>> This is the upgrade part. I will add one more patch to print a warning in >>> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >>> yet. >>> >>> >>> >> 1) >> Upgrade failed with 'BindInstance' object has no attribute >> 'named_conf_get_directive' >> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command >> ipa-server-upgrade manually. >> ('IPA upgrade failed.', 1) >> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more >> information >> >> 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no >> attribute 'named_conf_get_directive' >> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >> 213, in __upgrade >> self.modified = (ld.update(self.files) or self.modified) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >> line 917, in update >> self._run_updates(all_updates) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >> line 889, in _run_updates >> self._run_update_plugin(update['plugin']) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >> line 862, in _run_update_plugin >> restart_ds, updates = self.api.Updater[plugin_name]() >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1418, in >> __call__ >> return self.execute(**options) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >> line 547, in execute >> self.update_global_named_conf_forwarder(bind) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >> line 508, in update_global_named_conf_forwarder >> if bind.named_conf_get_directive( >> AttributeError: 'BindInstance' object has no attribute 'named_conf_get_directive' >> >> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 447, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 437, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >> 221, in __upgrade >> raise RuntimeError(e) >> RuntimeError: 'BindInstance' object has no attribute 'named_conf_get_directive' >> >> PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new attribute * >> 2) >> + Int('ipadnsversion?', >> + label=_('IPA DNS version'), >> + ), >> >> Shouldn't be this part of System: Read DNS Configuration permission? >> >> 3) >> - def postprocess_result(self, result): >> + def postprocess_result(self, result, show_version): >> if not any(param in result['result'] for param in self.params): >> result['summary'] = unicode(_('Global DNS configuration is empty')) >> >> show_version param was added but I don't see it used in this patch. >> >> 4) >> + Int('ipadnsversion?', >> + label=_('IPA DNS version'), >> + ), >> >> Could we add comment here that this option is accessible only from installers >> and upgrade? >> >> 5) >> + for config_option in container_entry.get("ipaConfigString", []): >> + matched = re.match("^DNSVersion\s+(?P\d+)$", >> + config_option, flags=re.I) >> + if matched: >> + version = int(matched.group("version")) >> >> Shouldn't we print error if version cannot be parsed? >> >> PATCH * DNS upgrade: separate backup logic to make it reusable * >> >> LGTM >> >> PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * >> >> 7) >> I'm curious why do you need to check superdomains? >> >> PATCH * DNS upgrade: change forwarding policy to = only for conflicting >> forward zones* >> >> 8) >> + self.log.debug('Zone %s was sucessfully modified to use ' >> + 'forward policy "only"', zone['idnsname'][0]) >> <---missing empty line----> >> + def execute(self, **options): >> >> PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if >> private IPs are used * >> 9) >> - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) >> + dnsutil.related_to_auto_empty_zone( >> + dnsutil.DNSName(zone.get('idnsname')[0])) >> >> Should be in previous commit >> >> 10) >> - return >> + return False, [] >> This should be fixed in the previous commit >> >> PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" >> if private IPs are used * >> 11) >> IMO this is an upgrade of configuration and this should be in >> ipaserver/install/server/upgrade.py, upgrade plugins are used only for >> updating of LDAP values >> >> Unless you really want to use this as precedence, but then it requires broader >> discussion. >> >> 12) >> >> bind.named_conf_get_directive >> should be >> bindinstance.named_conf_get_directive >> >> see 1) > This new patchset completely obsoletes the old one. I had to reshuffle few > things to to make the split between server config & LDAP upgrade possible. > > Hopefully I addressed all your comment. > commits * Move IP address resolution from ipaserver.install.installutils to ipapython.dnsutil * and * Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil * cause regression in case that dns.python resolver returns NoNameservers exception, it is handled as 'Internal server error' In original code every exception was caught and transformed to DNSNotARecordError. So we have following options: * keep the old behavior in 'resolve_rrsets' and catch all exceptions there * or catch all DNS errors in 'verify_host_resolvable' and raise it as new PublicError (DNSGenericError (doesn't exist) for example) E InternalError: an internal error has occurred ../ipalib/rpc.py:1100: InternalError test_forwardzone_delegation_warnings.test_command[0017: dnsrecord_mod: Delete (using dnsrecord-mod) NS record which delegates zone u'fw.sub2.sub.dnszone.test.' from zone u'dnszone.test' (expected warning for u'fw.sub2.sub.dnszone.test.')] [Wed May 25 12:17:00.172143 2016] [wsgi:error] [pid 62789] Traceback (most recent call last): [Wed May 25 12:17:00.172152 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in wsgi_execute [Wed May 25 12:17:00.172158 2016] [wsgi:error] [pid 62789] result = self.Command[name](*args, **options) [Wed May 25 12:17:00.172164 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 434, in __call__ [Wed May 25 12:17:00.172168 2016] [wsgi:error] [pid 62789] return self.__do_call(*args, **options) [Wed May 25 12:17:00.172173 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 460, in __do_call [Wed May 25 12:17:00.172178 2016] [wsgi:error] [pid 62789] ret = self.run(*args, **options) [Wed May 25 12:17:00.172183 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 777, in run [Wed May 25 12:17:00.172189 2016] [wsgi:error] [pid 62789] return self.execute(*args, **options) [Wed May 25 12:17:00.172194 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3774, in execute [Wed May 25 12:17:00.172199 2016] [wsgi:error] [pid 62789] result = super(dnsrecord_add, self).execute(*keys, **options) [Wed May 25 12:17:00.172204 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1230, in execute [Wed May 25 12:17:00.172209 2016] [wsgi:error] [pid 62789] *keys, **options) [Wed May 25 12:17:00.172213 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3719, in pre_callback [Wed May 25 12:17:00.172229 2016] [wsgi:error] [pid 62789] self.obj.run_precallback_validators(dn, entry_attrs, *keys, **options) [Wed May 25 12:17:00.172237 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3135, in run_precallback_validators [Wed May 25 12:17:00.172242 2016] [wsgi:error] [pid 62789] rtype_cb(ldap, dn, entry_attrs, *keys, **options) [Wed May 25 12:17:00.172247 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3057, in _nsrecord_pre_callback [Wed May 25 12:17:00.172252 2016] [wsgi:error] [pid 62789] check_ns_rec_resolvable(keys[0], DNSName(nsrecord), self.log) [Wed May 25 12:17:00.172256 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1577, in check_ns_rec_resolvable [Wed May 25 12:17:00.172261 2016] [wsgi:error] [pid 62789] verify_host_resolvable(name) [Wed May 25 12:17:00.172265 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 70, in verify_host_resolvable [Wed May 25 12:17:00.172270 2016] [wsgi:error] [pid 62789] if not resolve_ip_addresses(fqdn): [Wed May 25 12:17:00.172274 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 328, in resolve_ip_addresses [Wed May 25 12:17:00.172278 2016] [wsgi:error] [pid 62789] rrsets = resolve_rrsets(fqdn, ['A', 'AAAA']) [Wed May 25 12:17:00.172282 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 305, in resolve_rrsets [Wed May 25 12:17:00.172287 2016] [wsgi:error] [pid 62789] answer = dns.resolver.query(fqdn, rdtype) [Wed May 25 12:17:00.172292 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/dns/resolver.py", line 1029, in query [Wed May 25 12:17:00.172296 2016] [wsgi:error] [pid 62789] raise_on_no_answer, source_port) [Wed May 25 12:17:00.172301 2016] [wsgi:error] [pid 62789] File "/usr/lib/python2.7/site-packages/dns/resolver.py", line 856, in query [Wed May 25 12:17:00.172328 2016] [wsgi:error] [pid 62789] raise NoNameservers(request=request, errors=errors) From sbose at redhat.com Wed May 25 11:32:11 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 25 May 2016 13:32:11 +0200 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <1464106903.2783.27.camel@redhat.com> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> <1464106108.2783.25.camel@redhat.com> <1464106903.2783.27.camel@redhat.com> Message-ID: <20160525113211.GK29502@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, May 24, 2016 at 12:21:43PM -0400, Nathaniel McCallum wrote: > New versions again. This time I just removed the stray "TODO: assign > OID" line in the commit as it no longer applies. ACK to patches 1-4. Patch 5 can be committed independently and needs some additional discussion, see below. bye, Sumit > > On Tue, 2016-05-24 at 12:08 -0400, Nathaniel McCallum wrote: > > I have attached new versions of the patches. Comments below. > > > > On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > > > On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote: > > > > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > > > > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum > > > > > wrote: ... > > > > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 > > > > 2001 > > > > From: Nathaniel McCallum > > > > Date: Wed, 4 May 2016 17:08:45 -0400 > > > > Subject: [PATCH 5/5] Enable service authentication indicator > > > > management > > > > > > > > > > For me the patch looks good, but it would be nice if someone more > > > used > > > to our usage of python can have a short look to see if all > > > conventioens > > > are met. ACK for the functionality. > > > > I would like for us to merge the first four patches first and then > > concentrate on this one. > > > > In particular, the following issue needs to be discussed. We > > currently > > only have two, hard-coded indicator values: otp and radius. Thus, we > > use a StrEnum for this property. However, in the long-term, I'd like > > to > > have more flexibility; such as per-token indicators. This implies > > String. > > > > Is there some way to do StrEnum now and easily migrate to String > > later? > > I think this will break API. Thoughts? > > From jpazdziora at redhat.com Wed May 25 11:34:17 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 25 May 2016 13:34:17 +0200 Subject: [Freeipa-devel] Questions on git In-Reply-To: <073f4d99-9c05-2e62-8d55-ab1818de09ed@redhat.com> References: <20160525080309.GE29312@redhat.com> <590c332f-eadb-5fcc-b531-98c1162d994d@redhat.com> <073f4d99-9c05-2e62-8d55-ab1818de09ed@redhat.com> Message-ID: <20160525113417.GG29312@redhat.com> On Wed, May 25, 2016 at 12:17:18PM +0200, Christian Heimes wrote: > > I don't know why github either forces merge commits or a single squashed > commit. If I would have to guess, I would assume it has philosophical > reasons. It took many years to get github to add an alternative to merge The reason I was given when discussing it with a GitHub person was that it's a performance issue. They are worried that people would use it for multi-hundred-commit branches and the WebUI would not be able to provide the same fast response as for single diff/commit. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From dkupka at redhat.com Wed May 25 13:03:36 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 25 May 2016 15:03:36 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> Message-ID: On 18/05/16 08:01, Jan Cholasta wrote: > On 16.5.2016 16:35, Martin Basti wrote: >> >> >> On 09.05.2016 14:07, Jan Cholasta wrote: >>> On 6.5.2016 14:32, Martin Basti wrote: >>>> >>>> >>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> I have pushed my thin client WIP branch to GitHub: >>>>> . >>>>> >>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>> imports" should be good for review. The rest is subject to change >>>>> (WARNING: I will force push into this branch). >>>>> >>>>> Honza >>>>> >>>> I did not test it yet, I just checked the code >>>> >>>> * automount: do not inherit automountlocation_tofiles from LDAPQuery * >>>> LGTM >>>> >>>> * dns: move all dnsrecord code called on client to a single class * >>>> LGTM >>>> >>>> * dns: do not rely on server data structures in code called on client * >>>> 1) >>>> you forgot to increment VERSION >>> >>> This was deliberate, as it will no longer be necessary to bump VERSION >>> for backward compatible changes after this whole patchset is merged. >>> But we're not there yet, so fixed. >>> >> How we should handle VERSION after your patches? >>>> >>>> Otherwise LGTM >>>> >>>> * otptoken: fix import of DN * >>>> ACK >>>> >>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>> 1) >>>> you forgot to increment VERSION >>> >>> Fixed. >>> >>>> >>>> 2) >>>> Did you find out why this was issue? >>>> - del answer['value'] # Why does this cause an error if >>>> omitted? >>>> - del answer['summary'] # Why does this cause an error if >>>> omitted? >>> >>> The command definition was not complete, it was missing has_output. >>> >>>> >>>> Otherwise LGTM >>>> >>>> * vault: move client-side code to the module level * >>>> LGTM >>>> >>>> * vault: copy arguments of client commands from server counterparts * >>>> 1) >>>> you forgot to increment Version >>> >>> Fixed. >>> >>>> >>>> * ipalib: use relative imports for cross-plugin imports * >>>> 1) Missing explanation for future generations why this change is needed >>>> in commit message >>> >>> Fixed. >>> >>>> >>>> The other commits I will check later. >>>> Martin^2 >>>> >>> >>> Okay. Thanks. >>> >> >> * frontend: remove the unused Command.soft_validate method >> LGTM >> >> * frontend: perform argument value validation only on server >> LGTM >> >> * frontend: do not forward argument defaults to server >> I'm not a fan of returning None in promt_param function, but I havent >> found anything better to use. > > It always returned None for unset params. > >> LGTM >> >> * ipalib: optimize API.txt >> this contains a lot of black magic, but because this is mainly copy of >> current to proper places, LGTM > > It's actually mostly cut-n-paste. > >> >> * makeaci: load additional plugins using API.add_module >> Looks good, but I miss explanation why is this change needed > > The next change would be impossible without this. > >> >> * plugable: replace API.import_plugins with new API.add_package >> LGTM >> >> >> * ipalib, ipaserver: migrate all plugins to Registry-based registration >> ACK >> >> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >> LGTM >> >> >> * plugable: remove the unused deprecated API.register method >> LGTM >> >> >> * plugable: switch API to Registry-based plugin discovery >> LGTM >> >> * frontend: merge baseldap.CallbackRegistry into Command >> LGTM >> >> *frontend: move the interactive_prompt callback type to Command >> LGTM >> >> Martin^2 >> >> > > Hello, first batch of 30 patches from Honza's trac-4739 branch (https://github.com/jcholast/freeipa/commits/trac-4739) is ready to be pushed into master. All upto "frontend: allow commands to have an argument named `name`" got over numerous test&fix cycles in last week+ and is working as expected now, ACK. Honzo, please rebase and push them, thanks! -- David Kupka From jcholast at redhat.com Wed May 25 14:07:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 May 2016 16:07:21 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> Message-ID: On 25.5.2016 15:03, David Kupka wrote: > On 18/05/16 08:01, Jan Cholasta wrote: >> On 16.5.2016 16:35, Martin Basti wrote: >>> >>> >>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>> >>>>> >>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>> . >>>>>> >>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>> imports" should be good for review. The rest is subject to change >>>>>> (WARNING: I will force push into this branch). >>>>>> >>>>>> Honza >>>>>> >>>>> I did not test it yet, I just checked the code >>>>> >>>>> * automount: do not inherit automountlocation_tofiles from LDAPQuery * >>>>> LGTM >>>>> >>>>> * dns: move all dnsrecord code called on client to a single class * >>>>> LGTM >>>>> >>>>> * dns: do not rely on server data structures in code called on >>>>> client * >>>>> 1) >>>>> you forgot to increment VERSION >>>> >>>> This was deliberate, as it will no longer be necessary to bump VERSION >>>> for backward compatible changes after this whole patchset is merged. >>>> But we're not there yet, so fixed. >>>> >>> How we should handle VERSION after your patches? >>>>> >>>>> Otherwise LGTM >>>>> >>>>> * otptoken: fix import of DN * >>>>> ACK >>>>> >>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>> 1) >>>>> you forgot to increment VERSION >>>> >>>> Fixed. >>>> >>>>> >>>>> 2) >>>>> Did you find out why this was issue? >>>>> - del answer['value'] # Why does this cause an error if >>>>> omitted? >>>>> - del answer['summary'] # Why does this cause an error if >>>>> omitted? >>>> >>>> The command definition was not complete, it was missing has_output. >>>> >>>>> >>>>> Otherwise LGTM >>>>> >>>>> * vault: move client-side code to the module level * >>>>> LGTM >>>>> >>>>> * vault: copy arguments of client commands from server counterparts * >>>>> 1) >>>>> you forgot to increment Version >>>> >>>> Fixed. >>>> >>>>> >>>>> * ipalib: use relative imports for cross-plugin imports * >>>>> 1) Missing explanation for future generations why this change is >>>>> needed >>>>> in commit message >>>> >>>> Fixed. >>>> >>>>> >>>>> The other commits I will check later. >>>>> Martin^2 >>>>> >>>> >>>> Okay. Thanks. >>>> >>> >>> * frontend: remove the unused Command.soft_validate method >>> LGTM >>> >>> * frontend: perform argument value validation only on server >>> LGTM >>> >>> * frontend: do not forward argument defaults to server >>> I'm not a fan of returning None in promt_param function, but I havent >>> found anything better to use. >> >> It always returned None for unset params. >> >>> LGTM >>> >>> * ipalib: optimize API.txt >>> this contains a lot of black magic, but because this is mainly copy of >>> current to proper places, LGTM >> >> It's actually mostly cut-n-paste. >> >>> >>> * makeaci: load additional plugins using API.add_module >>> Looks good, but I miss explanation why is this change needed >> >> The next change would be impossible without this. >> >>> >>> * plugable: replace API.import_plugins with new API.add_package >>> LGTM >>> >>> >>> * ipalib, ipaserver: migrate all plugins to Registry-based registration >>> ACK >>> >>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>> LGTM >>> >>> >>> * plugable: remove the unused deprecated API.register method >>> LGTM >>> >>> >>> * plugable: switch API to Registry-based plugin discovery >>> LGTM >>> >>> * frontend: merge baseldap.CallbackRegistry into Command >>> LGTM >>> >>> *frontend: move the interactive_prompt callback type to Command >>> LGTM >>> >>> Martin^2 >>> >>> >> >> > > Hello, > first batch of 30 patches from Honza's trac-4739 branch > (https://github.com/jcholast/freeipa/commits/trac-4739) is ready to be > pushed into master. > All upto "frontend: allow commands to have an argument named `name`" got > over numerous test&fix cycles in last week+ and is working as expected > now, ACK. Thanks for the review. > > Honzo, please rebase and push them, thanks! > Attaching the patches for reference. Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-558-rpc-do-not-crash-when-unable-to-parse-JSON.patch Type: text/x-patch Size: 888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-559-parameters-remove-unused-ConversionError-and-Validat.patch Type: text/x-patch Size: 16976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-560-rpc-include-structured-error-information-in-response.patch Type: text/x-patch Size: 30569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-561-frontend-re-raise-remote-RequirementError-using-CLI-.patch Type: text/x-patch Size: 13209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-562-frontend-remove-the-unused-Command.soft_validate-met.patch Type: text/x-patch Size: 3251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-563-frontend-perform-argument-value-validation-only-on-s.patch Type: text/x-patch Size: 3996 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-564-batch-do-not-crash-when-no-argument-is-specified.patch Type: text/x-patch Size: 761 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-565-ipalib-make-optional-positional-command-arguments-ac.patch Type: text/x-patch Size: 11978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-566-frontend-do-not-forward-unspecified-positional-argum.patch Type: text/x-patch Size: 1306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-567-user-do-not-assume-the-preserve-flags-have-value-in-.patch Type: text/x-patch Size: 1412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-568-frontend-do-not-forward-argument-defaults-to-server.patch Type: text/x-patch Size: 1991 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-569-makeapi-optimize-API.txt.patch Type: text/x-patch Size: 703969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-570-ipalib-remove-the-unused-csv-argument-of-Param.patch Type: text/x-patch Size: 19532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-571-makeaci-load-additional-plugins-using-API.add_module.patch Type: text/x-patch Size: 1068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-572-plugable-replace-API.import_plugins-with-new-API.add.patch Type: text/x-patch Size: 5047 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-573-ipalib-ipaserver-migrate-all-plugins-to-Registry-bas.patch Type: text/x-patch Size: 21431 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-574-ipalib-ipaserver-fix-incorrect-API.register-calls-in.patch Type: text/x-patch Size: 8638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-575-plugable-remove-the-unused-deprecated-API.register-m.patch Type: text/x-patch Size: 1559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-576-plugable-switch-API-to-Registry-based-plugin-discove.patch Type: text/x-patch Size: 8307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-577-frontend-merge-baseldap.CallbackRegistry-into-Comman.patch Type: text/x-patch Size: 7860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-578-frontend-move-the-interactive_prompt-callback-type-t.patch Type: text/x-patch Size: 5584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-579-automount-do-not-inherit-automountlocation_import-fr.patch Type: text/x-patch Size: 1701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-580-dns-move-code-called-on-client-to-the-module-level.patch Type: text/x-patch Size: 13787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-581-dns-do-not-rely-on-server-data-structures-in-code-ca.patch Type: text/x-patch Size: 16085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-582-otptoken-fix-import-of-DN.patch Type: text/x-patch Size: 1416 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-583-otptoken_yubikey-fix-otptoken_add_yubikey-arguments.patch Type: text/x-patch Size: 5750 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-584-vault-move-client-side-code-to-the-module-level.patch Type: text/x-patch Size: 10198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-585-vault-copy-arguments-of-client-commands-from-server-.patch Type: text/x-patch Size: 11398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-586-ipalib-use-relative-imports-for-cross-plugin-imports.patch Type: text/x-patch Size: 29683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-587-frontend-allow-commands-to-have-an-argument-named-na.patch Type: text/x-patch Size: 1296 bytes Desc: not available URL: From ofayans at redhat.com Wed May 25 14:14:25 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 25 May 2016 16:14:25 +0200 Subject: [Freeipa-devel] [Testplan Review] Server Roles Message-ID: <5745B341.1090808@redhat.com> Hi guys. Here is a rather schematic (as neither the feature not the design document is not complete) of the server roles testplan. Could you please review it and tell me what is missing? http://www.freeipa.org/page/V4/Server_Roles/Test_Plan -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed May 25 15:21:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 17:21:07 +0200 Subject: [Freeipa-devel] [PATCH 0477] upgrade: always start CA In-Reply-To: <5d97feaa-80bc-0d85-8739-63197df58c7e@redhat.com> References: <5d97feaa-80bc-0d85-8739-63197df58c7e@redhat.com> Message-ID: On 25.05.2016 09:58, Stanislav Laznicka wrote: > On 05/20/2016 03:00 PM, Martin Basti wrote: >> >> On 19.05.2016 13:34, Stanislav Laznicka wrote: >>> >>> Also, I tried to upgrade from 4.2.4 to 4.3.1 and it seems that it >>> might be necessary to start the service even earlier in the upgrade >>> logic. Attached is the trace that occurred during the upgrade. >>> >>> I sent the whole log earlier accidentally, hopefully it will not >>> arrive here as well. >>> >>> On 05/19/2016 11:10 AM, Stanislav Laznicka wrote: >>>> >>>> NACK, see my comments below >>>> >>>> + # following upgrade steps require running CA >>>> This is a nitpicky nitpick but could you please change this comment >>>> for # the following ... >>>> Took me a while to understand what you were trying to say here. >>>> + if ca_running and not ca.is_running(): >>>> + ca.stop('pki-tomcat') >>>> + elif not ca_running and ca.is_running(): >>>> + ca.start('pki-tomcat') >>>> + >>>> You should swap ca.stop and ca.start here, you're stopping the >>>> service when it's stopped and starting it when it's already running. >> Shame, shame, shame on me. >> >>>> >>>> On 05/12/2016 04:34 PM, Martin Basti wrote: >>>>> Patch attached. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5868 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> I moved starting of CA to the earlier phase and swapped start/stop to >> correct order. >> >> Patch attached. > Seems to work as expected now. ACK. Pushed to: master: 0576a6827e9273979bc7a0c9c04bf91342c55282 ipa-4-3: 4bec0f10265252eee133ee3bcfc5ee2ca6196c65 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed May 25 16:17:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 18:17:13 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> Message-ID: <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> On 25.05.2016 16:07, Jan Cholasta wrote: > On 25.5.2016 15:03, David Kupka wrote: >> On 18/05/16 08:01, Jan Cholasta wrote: >>> On 16.5.2016 16:35, Martin Basti wrote: >>>> >>>> >>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>> . >>>>>>> >>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>> imports" should be good for review. The rest is subject to change >>>>>>> (WARNING: I will force push into this branch). >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> I did not test it yet, I just checked the code >>>>>> >>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>> LDAPQuery * >>>>>> LGTM >>>>>> >>>>>> * dns: move all dnsrecord code called on client to a single class * >>>>>> LGTM >>>>>> >>>>>> * dns: do not rely on server data structures in code called on >>>>>> client * >>>>>> 1) >>>>>> you forgot to increment VERSION >>>>> >>>>> This was deliberate, as it will no longer be necessary to bump >>>>> VERSION >>>>> for backward compatible changes after this whole patchset is merged. >>>>> But we're not there yet, so fixed. >>>>> >>>> How we should handle VERSION after your patches? >>>>>> >>>>>> Otherwise LGTM >>>>>> >>>>>> * otptoken: fix import of DN * >>>>>> ACK >>>>>> >>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>> 1) >>>>>> you forgot to increment VERSION >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 2) >>>>>> Did you find out why this was issue? >>>>>> - del answer['value'] # Why does this cause an error if >>>>>> omitted? >>>>>> - del answer['summary'] # Why does this cause an error if >>>>>> omitted? >>>>> >>>>> The command definition was not complete, it was missing has_output. >>>>> >>>>>> >>>>>> Otherwise LGTM >>>>>> >>>>>> * vault: move client-side code to the module level * >>>>>> LGTM >>>>>> >>>>>> * vault: copy arguments of client commands from server >>>>>> counterparts * >>>>>> 1) >>>>>> you forgot to increment Version >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>> 1) Missing explanation for future generations why this change is >>>>>> needed >>>>>> in commit message >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> The other commits I will check later. >>>>>> Martin^2 >>>>>> >>>>> >>>>> Okay. Thanks. >>>>> >>>> >>>> * frontend: remove the unused Command.soft_validate method >>>> LGTM >>>> >>>> * frontend: perform argument value validation only on server >>>> LGTM >>>> >>>> * frontend: do not forward argument defaults to server >>>> I'm not a fan of returning None in promt_param function, but I havent >>>> found anything better to use. >>> >>> It always returned None for unset params. >>> >>>> LGTM >>>> >>>> * ipalib: optimize API.txt >>>> this contains a lot of black magic, but because this is mainly copy of >>>> current to proper places, LGTM >>> >>> It's actually mostly cut-n-paste. >>> >>>> >>>> * makeaci: load additional plugins using API.add_module >>>> Looks good, but I miss explanation why is this change needed >>> >>> The next change would be impossible without this. >>> >>>> >>>> * plugable: replace API.import_plugins with new API.add_package >>>> LGTM >>>> >>>> >>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>> registration >>>> ACK >>>> >>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>> LGTM >>>> >>>> >>>> * plugable: remove the unused deprecated API.register method >>>> LGTM >>>> >>>> >>>> * plugable: switch API to Registry-based plugin discovery >>>> LGTM >>>> >>>> * frontend: merge baseldap.CallbackRegistry into Command >>>> LGTM >>>> >>>> *frontend: move the interactive_prompt callback type to Command >>>> LGTM >>>> >>>> Martin^2 >>>> >>>> >>> >>> >> >> Hello, >> first batch of 30 patches from Honza's trac-4739 branch >> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready to be >> pushed into master. >> All upto "frontend: allow commands to have an argument named `name`" got >> over numerous test&fix cycles in last week+ and is working as expected >> now, ACK. > > Thanks for the review. > >> >> Honzo, please rebase and push them, thanks! >> > > Attaching the patches for reference. > > Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 > Guys, you forgot to test it with newer pylint. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0485-fix-pylint-false-positive-errors-related-to-thin-cli.patch Type: text/x-patch Size: 1022 bytes Desc: not available URL: From mbasti at redhat.com Wed May 25 16:21:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 18:21:45 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin In-Reply-To: <0630f6c9-9d94-015b-f689-51ce0f3005d3@redhat.com> References: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> <0630f6c9-9d94-015b-f689-51ce0f3005d3@redhat.com> Message-ID: On 25.05.2016 09:11, Stanislav Laznicka wrote: > > LGTM, could you please just add the ticket to the commit message? > > > On 05/20/2016 04:28 PM, Martin Basti wrote: >> >> >> >> On 20.05.2016 15:03, Martin Basti wrote: >>> The removed code is unused for long time. >>> >>> Patch attached. >>> >>> >>> >> https://fedorahosted.org/freeipa/attachment/ticket/5899/ >> >> > updated patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0484.2-Remove-unused-variables-in-automount-plugin.patch Type: text/x-patch Size: 2203 bytes Desc: not available URL: From mbasti at redhat.com Wed May 25 16:28:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 May 2016 18:28:14 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <6a678451-e4ec-fb49-5050-a863693e2a5c@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> <6a678451-e4ec-fb49-5050-a863693e2a5c@redhat.com> Message-ID: <5c0558b4-9980-c6be-5dfe-4fa38ecf84e2@redhat.com> On 24.05.2016 12:10, Martin Basti wrote: > > > On 23.05.2016 07:44, Jan Cholasta wrote: >> On 20.5.2016 15:32, Martin Basti wrote: >>> >>> >>> On 20.05.2016 12:30, Petr Spacek wrote: >>>> On 18.5.2016 12:43, Martin Basti wrote: >>>>> >>>>> On 12.05.2016 16:16, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 12.05.2016 11:01, Martin Basti wrote: >>>>>>> >>>>>>> On 11.05.2016 09:41, Martin Basti wrote: >>>>>>>> >>>>>>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>>>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon >>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS >>>>>>>>>>>>>>> related >>>>>>>>>>>>>>> privileges >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DNS privileges are important for handling DNS locations >>>>>>>>>>>>>>> which can be >>>>>>>>>>>>>>> created without DNS servers in IPA topology. We will also >>>>>>>>>>>>>>> need this >>>>>>>>>>>>>>> privileges presented for future feature 'External DNS >>>>>>>>>>>>>>> support' >>>>>>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon >>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>>>>>> objectclasses >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>>>>>>>> index >>>>>>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>>>>>> booleanMatch >>>>>>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN >>>>>>>>>>>>>>> 'IPA v4.1' ) >>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch >>>>>>>>>>>>>>> SINGLE-VALUE SYNTAX >>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>>>>>>>> 'ipaLocation' DESC >>>>>>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>>>>>>>> SYNTAX >>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY >>>>>>>>>>>>>>> integerMatch SYNTAX >>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>>>>>>>> 'idnsRecord' >>>>>>>>>>>>>>> DESC 'dns >>>>>>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName >>>>>>>>>>>>>>> MAY ( cn $ >>>>>>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ >>>>>>>>>>>>>>> aAAARecord $ >>>>>>>>>>>>>>> a6Record $ >>>>>>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ >>>>>>>>>>>>>>> tXTRecord $ >>>>>>>>>>>>>>> mXRecord $ >>>>>>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ >>>>>>>>>>>>>>> SigRecord $ >>>>>>>>>>>>>>> KeyRecord >>>>>>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ >>>>>>>>>>>>>>> certRecord $ >>>>>>>>>>>>>>> dNameRecord >>>>>>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ >>>>>>>>>>>>>>> DLVRecord $ >>>>>>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>>>>>>>> IPSECKEYRecord $ >>>>>>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME >>>>>>>>>>>>>>> 'idnsZone' DESC >>>>>>>>>>>>>>> 'Zone >>>>>>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ >>>>>>>>>>>>>>> idnsSOAretry $ >>>>>>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>>>>>> idnsForwarders $ >>>>>>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( >>>>>>>>>>>>>>> idnsForwardPolicy $ >>>>>>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>>>>>>>> 'ipaDNSZone' >>>>>>>>>>>>>>> SUP top >>>>>>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>>>>>>>> 'idnsSecKey' >>>>>>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>>>>>>>> idnsSecKeyCreated $ >>>>>>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ >>>>>>>>>>>>>>> idnsSecKeyActivate $ >>>>>>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>>>>>>>> idnsName >>>>>>>>>>>>>>> ) MAY ( >>>>>>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>>>>>>>> there >>>>>>>>>>>>>> will not be >>>>>>>>>>>>>> any other object class on the location object (at least not >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> beginning). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( >>>>>>>>>>>>>>> ipaLocation $ >>>>>>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon >>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command >>>>>>>>>>>>>>> are just >>>>>>>>>>>>>>> prototypes and does not provide any information about >>>>>>>>>>>>>>> server (will be >>>>>>>>>>>>>>> done later) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>>>>>> API.txt | 59 >>>>>>>>>>>>>>> ++++++++++++++ >>>>>>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>>>>>> index >>>>>>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>> --- a/VERSION >>>>>>>>>>>>>>> +++ b/VERSION >>>>>>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value >>>>>>>>>>>>>>> to 255 >>>>>>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>>>>>> Needs rebase. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>> index >>>>>>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>>>>>> objectClass: top >>>>>>>>>>>>>>> cn: etc >>>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>>> +changetype: add >>>>>>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>>>>>> +objectClass: top >>>>>>>>>>>>>>> +cn: locations >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>>>>>> changetype: add >>>>>>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>>>>>> index >>>>>>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>>>>>> +default: objectClass: top >>>>>>>>>>>>>>> +default: cn: locations >>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>>>>>>>> index >>>>>>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>>>>>> +IPA locations >>>>>>>>>>>>>>> +""") + _(""" >>>>>>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>> + IPA locations >>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>>>>>> + managed_permissions = { >>>>>>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>>> + 'description', >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>>>>>>>> IMHO >>>>>>>>>>>>>> this is >>>>>>>>>>>>>> okay. >>>>>>>>>>>>>> Less renames we support the better. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + takes_params = ( >>>>>>>>>>>>>>> + DNSNameParam( >>>>>>>>>>>>>>> + 'idnsname', >>>>>>>>>>>>>>> + cli_name='name', >>>>>>>>>>>>>>> + primary_key=True, >>>>>>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>>>>>> + # dns name must be relative, we will put it >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> middle of >>>>>>>>>>>>>>> + # location domain name for location records >>>>>>>>>>>>>>> + only_relative=True, >>>>>>>>>>>>>>> + ), >>>>>>>>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>>>>>>>> labels >>>>>>>>>>>>>> work - >>>>>>>>>>>>>> but >>>>>>>>>>>>>> this should automagically work as long as we are handling >>>>>>>>>>>>>> DNS names >>>>>>>>>>>>>> using >>>>>>>>>>>>>> proper data types (not as strings). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> + Str( >>>>>>>>>>>>>>> + 'description?', >>>>>>>>>>>>>>> + label=_('Description'), >>>>>>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>>>>>> + ), >>>>>>>>>>>>>> After discussion with Honza we will keep description as >>>>>>>>>>>>>> single-value >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> IPA framework and ignore that description attribute is >>>>>>>>>>>>>> multi-value >>>>>>>>>>>>>> in LDAP. >>>>>>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>>>>>> + __doc__ = _('Modify information about an IPA >>>>>>>>>>>>>>> location .') >>>>>>>>>>>>>> This should say 'Modify description' because nothing else >>>>>>>>>>>>>> can be >>>>>>>>>>>>>> modified. >>>>>>>>>>>>>> More specific text would hopefully stop some people from >>>>>>>>>>>>>> looking for >>>>>>>>>>>>>> rename >>>>>>>>>>>>>> options. >>>>>>>>>>>>> I disagree, this is general description about the modify >>>>>>>>>>>>> command, see >>>>>>>>>>>>> privilege-add it is the same as I made. I can see in future >>>>>>>>>>>>> that we will >>>>>>>>>>>>> forgot to update description of command if we add something >>>>>>>>>>>>> new there. >>>>>>>>>>>> This is really an invalid argument. >>>>>>>>>>>> >>>>>>>>>>>> "We must not touch XYZ because its documentation might become >>>>>>>>>>>> obsolete in >>>>>>>>>>>> future if we forget to update it!" :-) >>>>>>>>>>>> >>>>>>>>>>> How about inconsistency with description of older commands? I >>>>>>>>>>> don't >>>>>>>>>>> think that >>>>>>>>>>> command description should describe attributes that are allowed >>>>>>>>>>> to change. >>>>>>>>>>> Allowed attributes are shown in --help output >>>>>>>>>> I do not agree but push whatever variant you like, it costed too >>>>>>>>>> much >>>>>>>>>> already. >>>>>>>>> NACK anyway. ipa-dns-install screams if you install a server >>>>>>>>> without DNS and >>>>>>>>> run ipa-dns-install later on: >>>>>>>>> >>>>>>>>> The log contains this: >>>>>>>>> >>>>>>>>> add objectClass: >>>>>>>>> top >>>>>>>>> groupofnames >>>>>>>>> nestedgroup >>>>>>>>> add cn: >>>>>>>>> DNS Administrators >>>>>>>>> add description: >>>>>>>>> DNS Administrators >>>>>>>>> adding new entry "cn=DNS >>>>>>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>>>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ) >>>>>>>>> SASL/EXTERNAL authentication started >>>>>>>>> SASL username: >>>>>>>>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>>>>>> SASL SSF: 0 >>>>>>>>> ldap_add: Already exists (68) >>>>>>>>> >>>>>>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>>>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>>>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>>>>>>>> >>>>>>>>> -Y >>>>>>>>> >>>>>>>>> EXTERNAL' returned non-zero exit status 68 >>>>>>>>> >>>>>>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>>>>>> >>>>>>> Updated patches attached >>>>>>> >>>>>>> I found that IDNA did not work with previous version, fixed + IDNA >>>>>>> tests added >>>>>>> >>>>>>> >>>>>> Fixed here, I sent wrong patches before >>>>>> >>>>>> >>>>>> >>>>>> >>>>> More patches added, all patches are available here: >>>>> https://github.com/bastiak/freeipa/tree/DNS-locations >>>> Functional NACK >>>> >>>> location-show returns incorrect location weight for servers >>>> >>>> # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all >>>> dn: >>>> cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>>> >>>> >>>> Server name: vm-046.abc.idm.lab.eng.brq.redhat.com >>>> Managed suffixes: domain >>>> Min domain level: 0 >>>> Max domain level: 1 >>>> Location: l2 >>>> Location weight: 200 >>>> objectclass: ipalocationmember, ipaReplTopoManagedServer, top, >>>> ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig >>>> >>>> # ipa location-show l2 >>>> Location name: l2 >>>> Description: Loc 2 >>>> Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) >>>> >>>> - Did you forget --all somewhere? >>> Nope, I forgot to put it to default attributes, nice catch, I will add >>> test for it. >>>> >>>> Other than that I have only nitpick regarding error message: >>>> ipa: ERROR: l2 cannot be deleted because IPA Server(s) >>>> vm-046.abc.idm.lab.eng.brq.redhat.com requires it >>>> >>>> - Please unify singular/plural. >>> This is how the exception is generated, so you can choose just >>> label, so >>> which label is the right? {'IPA server', 'IPA servers', 'IPA >>> server(s)'} >>> (I think server should be with lower cased 's') >>> raise DependentEntry( >>> label=_('IPA Server(s)'), >>> key=keys[-1], >>> dependent=location_members >>> ) >> >> Use ngettext here to handle singular/plural correctly. > It will fix only half of sentence, I put there just singular. > >> >>>> >>>> I did not require the code because Honza will surely look into >>>> details. >> >> "Allow to use non-Str attributes as keys for members": >> >> There is no actual API change, so don't bump VERSION. > Bump version removed > >> >> >> "Remove CSV from from member params": >> >> Again, no actual API change, don't bump VERSION. >> >> CSV params should be removed completely. I have a patch in my drawer >> which does exactly that, should I post it? >> > Removed > > Please post it. > >> >> "DNS Locations: extend server-* command with locations": >> >> I don't think ipalocationweight should be in server-find. Searching >> for servers by exact weight does not strike me as something useful. >> Or is it? > I agree, it will even not work with default location weight > >> >> In server.normalize_location(), don't call location.get_dn() with >> **options, as it contains server options, not location options. Also >> you are calling kw.pop('ipalocation_location') twice, which is most >> likely a bug. > Fixed. > It is not twice, it was called in different if-else branches, but I > rewrote the code it should looks better now. > >> >> In server_mod.pre_callback(), don't raise NotFound manually, but >> rather use self.api.Object.location.handle_not_found(). >> > Changed >> >> Honza >> > > Updated patches attached. > > Rebased patches attached -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0473.5-DNS-Locations-Always-create-DNS-related-privileges.patch Type: text/x-patch Size: 4774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0474.5-DNS-Locations-add-new-attributes-and-objectclasses.patch Type: text/x-patch Size: 4065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0475.5-DNS-Locations-location-commands.patch Type: text/x-patch Size: 12827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0476.5-DNS-Locations-API-tests.patch Type: text/x-patch Size: 9331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0478.5-Allow-to-use-non-Str-attributes-as-keys-for-members.patch Type: text/x-patch Size: 2147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0479.5-DNS-Locations-extend-server-command-with-locations.patch Type: text/x-patch Size: 9388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0480.5-DNS-Location-location-show-return-list-of-servers-in.patch Type: text/x-patch Size: 5186 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0481.5-DNS-Locations-prevent-to-remove-used-locations.patch Type: text/x-patch Size: 3872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0482.5-DNS-Locations-extend-tests-with-server-commands.patch Type: text/x-patch Size: 11837 bytes Desc: not available URL: From tbordaz at redhat.com Wed May 25 18:35:55 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 25 May 2016 20:35:55 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <57358DC7.9030905@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> Message-ID: <5745F08B.6040401@redhat.com> Hello, Thanks for all the feedbacks. I updated the design accordingly and with additional tests results (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) Several improvements can be done, in particular in DS plugins (memberof, retroCL), but for "easy" benefit provisioning will be done with memberof disabled followed by fixup. It remains some aspects that are not clear to me: * For best performance, DS tuning and provisioning/fixup would preferably be done under 'directory manager' That means prompting DM password and writing it into temporary file. Is that a concern ? * Fixup requires that we know the filters matching the provisioned entries. For example : o (objectClass=inetorgperson) o (objectClass=ipausergroup) o (objectClass=ipahost) o (objectClass=ipahostgroup) o (objectClass=ipasudorule) o (objectClass=ipahbacrule) The set of objectclass could be hardcode or provided in the provisioning CLI option What to do if an entry in in the provision file does not match any of those filter ? Should it stop without starting the provisioning ? * The CLI doing the provisioning could be something like 'ipa provision ' or should it be a separated command e.g. ipa-bulk-load ? thanks thierry On 05/13/2016 10:18 AM, Ludwig Krispenz wrote: > > On 05/13/2016 09:42 AM, Petr Spacek wrote: >> On 13.5.2016 09:26, Martin Kosek wrote: >>> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >>>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I have been doing some tests/measures using >>>>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>>>> >>>>>>>>> >>>>>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>>>>> import with a >>>>>>>>> ldapadd. >>>>>>>>> >>>>>>>>> I wrote down some finding in >>>>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I still have to do some cleanup around the performance >>>>>>>>> but the >>>>>>>>> basic of a >>>>>>>>> possible improvement is to do provisioning in several >>>>>>>>> steps >>>>>>>>> (disabling >>>>>>>>> plugins, provisioning, enabling plugin, running fixup >>>>>>>>> tasks). >>>>>>>>> >>>>>>>>> Before going further in the design I wanted to share >>>>>>>>> those ideas >>>>>>>>> and know if >>>>>>>>> it raise any concern. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>>> >>>>>>>> Hi Thierry, >>>>>>>> >>>>>>>> Thanks for the analysis. Very nice. >>>>>>>> >>>>>>>> Knowing this will help us suggesting workarounds also for old >>>>>>>> releases. >>>>>>>> >>>>>>>> Couple questions: >>>>>>>> >>>>>>>> Have you tested retrCL disabled with memberOf enabled. It seems >>>>>>>> that it >>>>>>>> would eliminate 550K adds and 0.8M searches. What would be the >>>>>>>> time >>>>>>>> improvement? >>>>>>>> >>>>>>>> Do you know what is the time when memberof is enabled but >>>>>>>> slapi-nis and >>>>>>>> retroCL are disabled? >>>>>>> The culprit of the performance issue is very likely related to SRCH >>>>>>> (internal) triggered by memberof. >>>>>>> >>>>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled >>>>>>> #SRCH is >>>>>>> 14.8 >>>>>>> When all of them are enabled the #SRCH is 15M. >>>>>>> >>>>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>>>> significant effect on the duration. >>>>>> ok, thanks for the analysis >>>>>> >>>>>>> Regarding the duration of the provisioning, values are not >>>>>>> really stable >>>>>>> as performance of VM fluctuates. But as soon as memberof is >>>>>>> enabled the >>>>>>> provisioning lasts > 4hours where the same provisioning lasts >>>>>>> 6mins as >>>>>>> soon as memberof is disabled. >>>>>>> >>>>>>> I need to confirm the average time for internal searches but >>>>>>> assuming >>>>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>>>> >>>>>>> >>>>>>>> From the text it was not clear to me, if you find or >>>>>>>> investigate >>>>>>>> possible improvements in memberof plugin which would improve the >>>>>>>> performance without stopping and starting DS. >>>>>> As was discussed at mtg, have you tried if the DS restart is really >>>>>> necessary? >>>>> memberof plugin can be enabled and disabled while the server is >>>>> running, BUT >>>>> to achieve this the "enable-dynamic-plugins" feature has to be >>>>> turned on. And >>>>> then any enable/disable of a plugin would try to do it dynamically >>>>> an dnot >>>>> wait for the restart. >>>>> And I think not all plugins are able to handle this, TomasB was >>>>> once working >>>>> on it for IPA plugins, but it was not completed as far as I know >>>> but enabling dynamic plugins can be done without restart, so what >>>> can be done is. >>>> - enable dynamic plugins >>>> - disable memberof >>>> - do some work >>>> - enable memberof >>>> - disable dynamic plugins >>> Please see >>> https://fedorahosted.org/freeipa/ticket/4203#comment:9 >>> I do not think this will be that easy. We would first need to invest >>> into >>> updating FreeIPA plugins to work with dynamic plugins setting and >>> then we could >>> do things alike above. >>> >>> It looks like that for FreeIPA 4.4, we will need to live with DS >>> restart unless >>> there is some workaround... > couldn't the scenario I outline above with enabling dynamic plugins > only temporary work, are there any attempts to enable/disable plugins > during provisioning ? If that would be the case that would also > require a restart >> One more thing: >> >> How does it affect topologies with replicas? >> >> I might be wrong, but if memberOf is always computed locally then we >> have to >> disable it on *all* replicas. >> >> If we disabled it only on one replica and not others, the chosen >> replica would >> be way faster than rest of the topology and I'm not sure what would >> happen >> later on. > good point. we exclude memberof from replication as it is regenerated > on every server, so each replica would suffer from the performance > problem >> >> Thierry, Ludwig, can you comment on this? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 25 18:49:09 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 May 2016 14:49:09 -0400 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5745F08B.6040401@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> Message-ID: <5745F3A5.5030501@redhat.com> thierry bordaz wrote: > > Hello, > > Thanks for all the feedbacks. I updated the design accordingly and with > additional tests results > (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) > Several improvements can be done, in particular in DS plugins (memberof, > retroCL), but for "easy" benefit provisioning will be done with memberof > disabled followed by fixup. > > It remains some aspects that are not clear to me: > > * For best performance, DS tuning and provisioning/fixup would > preferably be done under 'directory manager' > That means prompting DM password and writing it into temporary file. > Is that a concern ? > * Fixup requires that we know the filters matching the provisioned > entries. For example : > o (objectClass=inetorgperson) > o (objectClass=ipausergroup) > o (objectClass=ipahost) > o (objectClass=ipahostgroup) > o (objectClass=ipasudorule) > o (objectClass=ipahbacrule) > > The set of objectclass could be hardcode or provided in the > provisioning CLI option > What to do if an entry in in the provision file does not match > any of those filter ? Should it stop without starting the > provisioning ? > * The CLI doing the provisioning could be something like 'ipa > provision ' or should it be a separated command e.g. > ipa-bulk-load ? It depends. There is a migration command now, ipa migrate-ds, that adds records and is impacted by this. There is also the possibility of looping calls to ipa [user|group|etc]-add. Would it be reasonable to require bulk import to be done on an IPA master so we can leverage the ldapi socket? rob > > thanks > thierry > > On 05/13/2016 10:18 AM, Ludwig Krispenz wrote: >> >> On 05/13/2016 09:42 AM, Petr Spacek wrote: >>> On 13.5.2016 09:26, Martin Kosek wrote: >>>> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >>>>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>>>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>>>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I have been doing some tests/measures using >>>>>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The tool creates a set of typical users/hosts/groups... to >>>>>>>>>> import with a >>>>>>>>>> ldapadd. >>>>>>>>>> >>>>>>>>>> I wrote down some finding in >>>>>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I still have to do some cleanup around the performance >>>>>>>>>> but the >>>>>>>>>> basic of a >>>>>>>>>> possible improvement is to do provisioning in several >>>>>>>>>> steps >>>>>>>>>> (disabling >>>>>>>>>> plugins, provisioning, enabling plugin, running fixup >>>>>>>>>> tasks). >>>>>>>>>> >>>>>>>>>> Before going further in the design I wanted to share >>>>>>>>>> those ideas >>>>>>>>>> and know if >>>>>>>>>> it raise any concern. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> thierry >>>>>>>>>> >>>>>>>>> Hi Thierry, >>>>>>>>> >>>>>>>>> Thanks for the analysis. Very nice. >>>>>>>>> >>>>>>>>> Knowing this will help us suggesting workarounds also for old >>>>>>>>> releases. >>>>>>>>> >>>>>>>>> Couple questions: >>>>>>>>> >>>>>>>>> Have you tested retrCL disabled with memberOf enabled. It seems >>>>>>>>> that it >>>>>>>>> would eliminate 550K adds and 0.8M searches. What would be the >>>>>>>>> time >>>>>>>>> improvement? >>>>>>>>> >>>>>>>>> Do you know what is the time when memberof is enabled but >>>>>>>>> slapi-nis and >>>>>>>>> retroCL are disabled? >>>>>>>> The culprit of the performance issue is very likely related to SRCH >>>>>>>> (internal) triggered by memberof. >>>>>>>> >>>>>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled >>>>>>>> #SRCH is >>>>>>>> 14.8 >>>>>>>> When all of them are enabled the #SRCH is 15M. >>>>>>>> >>>>>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>>>>> significant effect on the duration. >>>>>>> ok, thanks for the analysis >>>>>>> >>>>>>>> Regarding the duration of the provisioning, values are not >>>>>>>> really stable >>>>>>>> as performance of VM fluctuates. But as soon as memberof is >>>>>>>> enabled the >>>>>>>> provisioning lasts > 4hours where the same provisioning lasts >>>>>>>> 6mins as >>>>>>>> soon as memberof is disabled. >>>>>>>> >>>>>>>> I need to confirm the average time for internal searches but >>>>>>>> assuming >>>>>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>>>>> >>>>>>>> >>>>>>>>> From the text it was not clear to me, if you find or >>>>>>>>> investigate >>>>>>>>> possible improvements in memberof plugin which would improve the >>>>>>>>> performance without stopping and starting DS. >>>>>>> As was discussed at mtg, have you tried if the DS restart is really >>>>>>> necessary? >>>>>> memberof plugin can be enabled and disabled while the server is >>>>>> running, BUT >>>>>> to achieve this the "enable-dynamic-plugins" feature has to be >>>>>> turned on. And >>>>>> then any enable/disable of a plugin would try to do it dynamically >>>>>> an dnot >>>>>> wait for the restart. >>>>>> And I think not all plugins are able to handle this, TomasB was >>>>>> once working >>>>>> on it for IPA plugins, but it was not completed as far as I know >>>>> but enabling dynamic plugins can be done without restart, so what >>>>> can be done is. >>>>> - enable dynamic plugins >>>>> - disable memberof >>>>> - do some work >>>>> - enable memberof >>>>> - disable dynamic plugins >>>> Please see >>>> https://fedorahosted.org/freeipa/ticket/4203#comment:9 >>>> I do not think this will be that easy. We would first need to invest >>>> into >>>> updating FreeIPA plugins to work with dynamic plugins setting and >>>> then we could >>>> do things alike above. >>>> >>>> It looks like that for FreeIPA 4.4, we will need to live with DS >>>> restart unless >>>> there is some workaround... >> couldn't the scenario I outline above with enabling dynamic plugins >> only temporary work, are there any attempts to enable/disable plugins >> during provisioning ? If that would be the case that would also >> require a restart >>> One more thing: >>> >>> How does it affect topologies with replicas? >>> >>> I might be wrong, but if memberOf is always computed locally then we >>> have to >>> disable it on *all* replicas. >>> >>> If we disabled it only on one replica and not others, the chosen >>> replica would >>> be way faster than rest of the topology and I'm not sure what would >>> happen >>> later on. >> good point. we exclude memberof from replication as it is regenerated >> on every server, so each replica would suffer from the performance >> problem >>> >>> Thierry, Ludwig, can you comment on this? >>> >> > > > From tbordaz at redhat.com Wed May 25 19:25:20 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 25 May 2016 21:25:20 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5745F3A5.5030501@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> Message-ID: <5745FC20.2050508@redhat.com> On 05/25/2016 08:49 PM, Rob Crittenden wrote: > thierry bordaz wrote: >> >> Hello, >> >> Thanks for all the feedbacks. I updated the design accordingly and with >> additional tests results >> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >> >> Several improvements can be done, in particular in DS plugins (memberof, >> retroCL), but for "easy" benefit provisioning will be done with memberof >> disabled followed by fixup. >> >> It remains some aspects that are not clear to me: >> >> * For best performance, DS tuning and provisioning/fixup would >> preferably be done under 'directory manager' >> That means prompting DM password and writing it into temporary file. >> Is that a concern ? >> * Fixup requires that we know the filters matching the provisioned >> entries. For example : >> o (objectClass=inetorgperson) >> o (objectClass=ipausergroup) >> o (objectClass=ipahost) >> o (objectClass=ipahostgroup) >> o (objectClass=ipasudorule) >> o (objectClass=ipahbacrule) >> >> The set of objectclass could be hardcode or provided in the >> provisioning CLI option >> What to do if an entry in in the provision file does not match >> any of those filter ? Should it stop without starting the >> provisioning ? >> * The CLI doing the provisioning could be something like 'ipa >> provision ' or should it be a separated command e.g. >> ipa-bulk-load ? > > It depends. There is a migration command now, ipa migrate-ds, that > adds records and is impacted by this. There is also the possibility of > looping calls to ipa [user|group|etc]-add. I agree that migration and bulk load can be linked. If migration dump/update a set of entries before filling them into a new instance it could use bulk load. For set loop of ipa -add, I think they add many others direct operations (mainly SRCH) before doing the ADD in order to check coherency. bulk load looks more straightforward. > > Would it be reasonable to require bulk import to be done on an IPA > master so we can leverage the ldapi socket? Do you mean using ldapi to reduce network latency or automember or something else ? thanks theirry > > rob > >> >> thanks >> thierry >> >> On 05/13/2016 10:18 AM, Ludwig Krispenz wrote: >>> >>> On 05/13/2016 09:42 AM, Petr Spacek wrote: >>>> On 13.5.2016 09:26, Martin Kosek wrote: >>>>> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote: >>>>>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote: >>>>>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote: >>>>>>>> On 05/10/2016 05:50 PM, thierry bordaz wrote: >>>>>>>>> On 05/05/2016 03:44 PM, Petr Vobornik wrote: >>>>>>>>>> On 05/04/2016 02:20 PM, thierry bordaz wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I have been doing some tests/measures using >>>>>>>>>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The tool creates a set of typical >>>>>>>>>>> users/hosts/groups... to >>>>>>>>>>> import with a >>>>>>>>>>> ldapadd. >>>>>>>>>>> >>>>>>>>>>> I wrote down some finding in >>>>>>>>>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I still have to do some cleanup around the performance >>>>>>>>>>> but the >>>>>>>>>>> basic of a >>>>>>>>>>> possible improvement is to do provisioning in several >>>>>>>>>>> steps >>>>>>>>>>> (disabling >>>>>>>>>>> plugins, provisioning, enabling plugin, running fixup >>>>>>>>>>> tasks). >>>>>>>>>>> >>>>>>>>>>> Before going further in the design I wanted to share >>>>>>>>>>> those ideas >>>>>>>>>>> and know if >>>>>>>>>>> it raise any concern. >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> thierry >>>>>>>>>>> >>>>>>>>>> Hi Thierry, >>>>>>>>>> >>>>>>>>>> Thanks for the analysis. Very nice. >>>>>>>>>> >>>>>>>>>> Knowing this will help us suggesting workarounds also for old >>>>>>>>>> releases. >>>>>>>>>> >>>>>>>>>> Couple questions: >>>>>>>>>> >>>>>>>>>> Have you tested retrCL disabled with memberOf enabled. It seems >>>>>>>>>> that it >>>>>>>>>> would eliminate 550K adds and 0.8M searches. What would be the >>>>>>>>>> time >>>>>>>>>> improvement? >>>>>>>>>> >>>>>>>>>> Do you know what is the time when memberof is enabled but >>>>>>>>>> slapi-nis and >>>>>>>>>> retroCL are disabled? >>>>>>>>> The culprit of the performance issue is very likely related to >>>>>>>>> SRCH >>>>>>>>> (internal) triggered by memberof. >>>>>>>>> >>>>>>>>> If retroCL is disabled and memberof enabled, #SRCH is 13.8M. >>>>>>>>> If retroCL is disabled, slapi-nis disabled and memberof enabled >>>>>>>>> #SRCH is >>>>>>>>> 14.8 >>>>>>>>> When all of them are enabled the #SRCH is 15M. >>>>>>>>> >>>>>>>>> You are right if retroCL is disabled the #ADD drops but it has no >>>>>>>>> significant effect on the duration. >>>>>>>> ok, thanks for the analysis >>>>>>>> >>>>>>>>> Regarding the duration of the provisioning, values are not >>>>>>>>> really stable >>>>>>>>> as performance of VM fluctuates. But as soon as memberof is >>>>>>>>> enabled the >>>>>>>>> provisioning lasts > 4hours where the same provisioning lasts >>>>>>>>> 6mins as >>>>>>>>> soon as memberof is disabled. >>>>>>>>> >>>>>>>>> I need to confirm the average time for internal searches but >>>>>>>>> assuming >>>>>>>>> 1ms per SRCH it consumes >90% of the provisioning. >>>>>>>>> >>>>>>>>> >>>>>>>>>> From the text it was not clear to me, if you find or >>>>>>>>>> investigate >>>>>>>>>> possible improvements in memberof plugin which would improve the >>>>>>>>>> performance without stopping and starting DS. >>>>>>>> As was discussed at mtg, have you tried if the DS restart is >>>>>>>> really >>>>>>>> necessary? >>>>>>> memberof plugin can be enabled and disabled while the server is >>>>>>> running, BUT >>>>>>> to achieve this the "enable-dynamic-plugins" feature has to be >>>>>>> turned on. And >>>>>>> then any enable/disable of a plugin would try to do it dynamically >>>>>>> an dnot >>>>>>> wait for the restart. >>>>>>> And I think not all plugins are able to handle this, TomasB was >>>>>>> once working >>>>>>> on it for IPA plugins, but it was not completed as far as I know >>>>>> but enabling dynamic plugins can be done without restart, so what >>>>>> can be done is. >>>>>> - enable dynamic plugins >>>>>> - disable memberof >>>>>> - do some work >>>>>> - enable memberof >>>>>> - disable dynamic plugins >>>>> Please see >>>>> https://fedorahosted.org/freeipa/ticket/4203#comment:9 >>>>> I do not think this will be that easy. We would first need to invest >>>>> into >>>>> updating FreeIPA plugins to work with dynamic plugins setting and >>>>> then we could >>>>> do things alike above. >>>>> >>>>> It looks like that for FreeIPA 4.4, we will need to live with DS >>>>> restart unless >>>>> there is some workaround... >>> couldn't the scenario I outline above with enabling dynamic plugins >>> only temporary work, are there any attempts to enable/disable plugins >>> during provisioning ? If that would be the case that would also >>> require a restart >>>> One more thing: >>>> >>>> How does it affect topologies with replicas? >>>> >>>> I might be wrong, but if memberOf is always computed locally then we >>>> have to >>>> disable it on *all* replicas. >>>> >>>> If we disabled it only on one replica and not others, the chosen >>>> replica would >>>> be way faster than rest of the topology and I'm not sure what would >>>> happen >>>> later on. >>> good point. we exclude memberof from replication as it is regenerated >>> on every server, so each replica would suffer from the performance >>> problem >>>> >>>> Thierry, Ludwig, can you comment on this? >>>> >>> >> >> >> > From rcritten at redhat.com Wed May 25 19:31:21 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 May 2016 15:31:21 -0400 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5745FC20.2050508@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> Message-ID: <5745FD89.3070601@redhat.com> thierry bordaz wrote: > > > On 05/25/2016 08:49 PM, Rob Crittenden wrote: >> thierry bordaz wrote: >>> >>> Hello, >>> >>> Thanks for all the feedbacks. I updated the design accordingly and with >>> additional tests results >>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>> >>> Several improvements can be done, in particular in DS plugins (memberof, >>> retroCL), but for "easy" benefit provisioning will be done with memberof >>> disabled followed by fixup. >>> >>> It remains some aspects that are not clear to me: >>> >>> * For best performance, DS tuning and provisioning/fixup would >>> preferably be done under 'directory manager' >>> That means prompting DM password and writing it into temporary file. >>> Is that a concern ? >>> * Fixup requires that we know the filters matching the provisioned >>> entries. For example : >>> o (objectClass=inetorgperson) >>> o (objectClass=ipausergroup) >>> o (objectClass=ipahost) >>> o (objectClass=ipahostgroup) >>> o (objectClass=ipasudorule) >>> o (objectClass=ipahbacrule) >>> >>> The set of objectclass could be hardcode or provided in the >>> provisioning CLI option >>> What to do if an entry in in the provision file does not match >>> any of those filter ? Should it stop without starting the >>> provisioning ? >>> * The CLI doing the provisioning could be something like 'ipa >>> provision ' or should it be a separated command e.g. >>> ipa-bulk-load ? >> >> It depends. There is a migration command now, ipa migrate-ds, that >> adds records and is impacted by this. There is also the possibility of >> looping calls to ipa [user|group|etc]-add. > > I agree that migration and bulk load can be linked. If migration > dump/update a set of entries before filling them into a new instance it > could use bulk load. > For set loop of ipa -add, I think they add many others direct > operations (mainly SRCH) before doing the ADD in order to check > coherency. bulk load looks more straightforward. I just wonder if some (all) of this could be done manually. Document how to turn off memberof, do the import whatever way is appropriate, then run the fixup? I'm not sure what you had in mind. I don't want to think small but do we expect to be importing a slew of hosts, sudorules, etc? I guess the potential is there but would it be on the same scale as users? If you focus only on users/groups does that change the use case at all? >> Would it be reasonable to require bulk import to be done on an IPA >> master so we can leverage the ldapi socket? > Do you mean using ldapi to reduce network latency or automember or > something else ? To avoid the DM password issues. ldapi autobinds to DM when the id is root. rob From jcholast at redhat.com Thu May 26 05:15:11 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 May 2016 07:15:11 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> Message-ID: <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> On 25.5.2016 18:17, Martin Basti wrote: > > > On 25.05.2016 16:07, Jan Cholasta wrote: >> On 25.5.2016 15:03, David Kupka wrote: >>> On 18/05/16 08:01, Jan Cholasta wrote: >>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>> >>>>> >>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>> . >>>>>>>> >>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>> imports" should be good for review. The rest is subject to change >>>>>>>> (WARNING: I will force push into this branch). >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> I did not test it yet, I just checked the code >>>>>>> >>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>> LDAPQuery * >>>>>>> LGTM >>>>>>> >>>>>>> * dns: move all dnsrecord code called on client to a single class * >>>>>>> LGTM >>>>>>> >>>>>>> * dns: do not rely on server data structures in code called on >>>>>>> client * >>>>>>> 1) >>>>>>> you forgot to increment VERSION >>>>>> >>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>> VERSION >>>>>> for backward compatible changes after this whole patchset is merged. >>>>>> But we're not there yet, so fixed. >>>>>> >>>>> How we should handle VERSION after your patches? >>>>>>> >>>>>>> Otherwise LGTM >>>>>>> >>>>>>> * otptoken: fix import of DN * >>>>>>> ACK >>>>>>> >>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>> 1) >>>>>>> you forgot to increment VERSION >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 2) >>>>>>> Did you find out why this was issue? >>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>> omitted? >>>>>>> - del answer['summary'] # Why does this cause an error if >>>>>>> omitted? >>>>>> >>>>>> The command definition was not complete, it was missing has_output. >>>>>> >>>>>>> >>>>>>> Otherwise LGTM >>>>>>> >>>>>>> * vault: move client-side code to the module level * >>>>>>> LGTM >>>>>>> >>>>>>> * vault: copy arguments of client commands from server >>>>>>> counterparts * >>>>>>> 1) >>>>>>> you forgot to increment Version >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>> 1) Missing explanation for future generations why this change is >>>>>>> needed >>>>>>> in commit message >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> The other commits I will check later. >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>>> Okay. Thanks. >>>>>> >>>>> >>>>> * frontend: remove the unused Command.soft_validate method >>>>> LGTM >>>>> >>>>> * frontend: perform argument value validation only on server >>>>> LGTM >>>>> >>>>> * frontend: do not forward argument defaults to server >>>>> I'm not a fan of returning None in promt_param function, but I havent >>>>> found anything better to use. >>>> >>>> It always returned None for unset params. >>>> >>>>> LGTM >>>>> >>>>> * ipalib: optimize API.txt >>>>> this contains a lot of black magic, but because this is mainly copy of >>>>> current to proper places, LGTM >>>> >>>> It's actually mostly cut-n-paste. >>>> >>>>> >>>>> * makeaci: load additional plugins using API.add_module >>>>> Looks good, but I miss explanation why is this change needed >>>> >>>> The next change would be impossible without this. >>>> >>>>> >>>>> * plugable: replace API.import_plugins with new API.add_package >>>>> LGTM >>>>> >>>>> >>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>> registration >>>>> ACK >>>>> >>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>> LGTM >>>>> >>>>> >>>>> * plugable: remove the unused deprecated API.register method >>>>> LGTM >>>>> >>>>> >>>>> * plugable: switch API to Registry-based plugin discovery >>>>> LGTM >>>>> >>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>> LGTM >>>>> >>>>> *frontend: move the interactive_prompt callback type to Command >>>>> LGTM >>>>> >>>>> Martin^2 >>>>> >>>>> >>>> >>>> >>> >>> Hello, >>> first batch of 30 patches from Honza's trac-4739 branch >>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready to be >>> pushed into master. >>> All upto "frontend: allow commands to have an argument named `name`" got >>> over numerous test&fix cycles in last week+ and is working as expected >>> now, ACK. >> >> Thanks for the review. >> >>> >>> Honzo, please rebase and push them, thanks! >>> >> >> Attaching the patches for reference. >> >> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >> > > Guys, you forgot to test it with newer pylint. I don't see any "BuildRequires: newer pylint" in the spec file. > > Patch attached. LGTM, although the commit message is wrong - this is not related to thin client at all, PublicError and PublicMessage had .kw since forever. -- Jan Cholasta From jcholast at redhat.com Thu May 26 05:25:47 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 May 2016 07:25:47 +0200 Subject: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue In-Reply-To: <5c0558b4-9980-c6be-5dfe-4fa38ecf84e2@redhat.com> References: <33126f9b-0e0a-111c-8ca5-b1fc86d86cb7@redhat.com> <9eb51025-62e4-add4-5d54-c7d01c0e4310@redhat.com> <5136f7ac-7e72-bad9-121e-230351057734@redhat.com> <60948047-fcd6-2221-c220-8cf53b2bfdde@redhat.com> <7bc96540-1300-56dc-140e-8fd8c624bc57@redhat.com> <3a2dd3ab-c323-15f8-ef63-4492c63333ad@redhat.com> <643bf3a9-b802-9283-e185-63e81a8cbb37@redhat.com> <262dd078-9791-43aa-71e0-39d9b8da2691@redhat.com> <6a678451-e4ec-fb49-5050-a863693e2a5c@redhat.com> <5c0558b4-9980-c6be-5dfe-4fa38ecf84e2@redhat.com> Message-ID: <36048dce-31c2-3516-4785-95abcb1f5bb3@redhat.com> On 25.5.2016 18:28, Martin Basti wrote: > > > On 24.05.2016 12:10, Martin Basti wrote: >> >> >> On 23.05.2016 07:44, Jan Cholasta wrote: >>> On 20.5.2016 15:32, Martin Basti wrote: >>>> >>>> >>>> On 20.05.2016 12:30, Petr Spacek wrote: >>>>> On 18.5.2016 12:43, Martin Basti wrote: >>>>>> >>>>>> On 12.05.2016 16:16, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 12.05.2016 11:01, Martin Basti wrote: >>>>>>>> >>>>>>>> On 11.05.2016 09:41, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 10.05.2016 18:56, Petr Spacek wrote: >>>>>>>>>> On 10.5.2016 15:38, Petr Spacek wrote: >>>>>>>>>>> On 10.5.2016 15:26, Martin Basti wrote: >>>>>>>>>>>> On 10.05.2016 15:23, Petr Spacek wrote: >>>>>>>>>>>>> On 10.5.2016 14:44, Martin Basti wrote: >>>>>>>>>>>>>> On 10.05.2016 14:33, Petr Spacek wrote: >>>>>>>>>>>>>>> On 6.5.2016 10:20, Martin Basti wrote: >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon >>>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>>> Date: Wed, 4 May 2016 17:33:52 +0200 >>>>>>>>>>>>>>>> Subject: [PATCH 1/4] DNS Locations: Always create DNS >>>>>>>>>>>>>>>> related >>>>>>>>>>>>>>>> privileges >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> DNS privileges are important for handling DNS locations >>>>>>>>>>>>>>>> which can be >>>>>>>>>>>>>>>> created without DNS servers in IPA topology. We will also >>>>>>>>>>>>>>>> need this >>>>>>>>>>>>>>>> privileges presented for future feature 'External DNS >>>>>>>>>>>>>>>> support' >>>>>>>>>>>>>>> Seems reasonable, ACK. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon >>>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:12:00 +0200 >>>>>>>>>>>>>>>> Subject: [PATCH 2/4] DNS Locations: add new attributes and >>>>>>>>>>>>>>>> objectclasses >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> install/share/60ipadns.ldif | 4 ++++ >>>>>>>>>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git a/install/share/60ipadns.ldif >>>>>>>>>>>>>>>> b/install/share/60ipadns.ldif >>>>>>>>>>>>>>>> index >>>>>>>>>>>>>>>> e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>>> --- a/install/share/60ipadns.ldif >>>>>>>>>>>>>>>> +++ b/install/share/60ipadns.ldif >>>>>>>>>>>>>>>> @@ -70,9 +70,13 @@ attributeTypes: ( >>>>>>>>>>>>>>>> 2.16.840.1.113730.3.8.5.25 NAME >>>>>>>>>>>>>>>> 'idnsSecKeyRevoke' DESC 'DNSKE >>>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME >>>>>>>>>>>>>>>> 'idnsSecKeySep' DESC >>>>>>>>>>>>>>>> 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY >>>>>>>>>>>>>>>> booleanMatch >>>>>>>>>>>>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN >>>>>>>>>>>>>>>> 'IPA v4.1' ) >>>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME >>>>>>>>>>>>>>>> 'idnsSecAlgorithm' DESC >>>>>>>>>>>>>>>> 'DNSKEY algorithm: string used as mnemonic' EQUALITY >>>>>>>>>>>>>>>> caseIgnoreIA5Match >>>>>>>>>>>>>>>> SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX >>>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.26 >>>>>>>>>>>>>>>> SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>>> attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME >>>>>>>>>>>>>>>> 'idnsSecKeyRef' DESC >>>>>>>>>>>>>>>> 'PKCS#11 URI of the key' EQUALITY caseExactMatch >>>>>>>>>>>>>>>> SINGLE-VALUE SYNTAX >>>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME >>>>>>>>>>>>>>>> 'ipaLocation' DESC >>>>>>>>>>>>>>>> 'Reference to IPA location' EQUALITY distinguishedNameMatch >>>>>>>>>>>>>>>> SYNTAX >>>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>>>> +attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME >>>>>>>>>>>>>>>> 'ipaLocationWeight' DESC >>>>>>>>>>>>>>>> 'Weight for the server in IPA location' EQUALITY >>>>>>>>>>>>>>>> integerMatch SYNTAX >>>>>>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA >>>>>>>>>>>>>>>> v4.4' ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME >>>>>>>>>>>>>>>> 'idnsRecord' >>>>>>>>>>>>>>>> DESC 'dns >>>>>>>>>>>>>>>> Record, usually a host' SUP top STRUCTURAL MUST idnsName >>>>>>>>>>>>>>>> MAY ( cn $ >>>>>>>>>>>>>>>> idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ >>>>>>>>>>>>>>>> aAAARecord $ >>>>>>>>>>>>>>>> a6Record $ >>>>>>>>>>>>>>>> nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ >>>>>>>>>>>>>>>> tXTRecord $ >>>>>>>>>>>>>>>> mXRecord $ >>>>>>>>>>>>>>>> mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ >>>>>>>>>>>>>>>> SigRecord $ >>>>>>>>>>>>>>>> KeyRecord >>>>>>>>>>>>>>>> $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ >>>>>>>>>>>>>>>> certRecord $ >>>>>>>>>>>>>>>> dNameRecord >>>>>>>>>>>>>>>> $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ >>>>>>>>>>>>>>>> DLVRecord $ >>>>>>>>>>>>>>>> TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ >>>>>>>>>>>>>>>> IPSECKEYRecord $ >>>>>>>>>>>>>>>> DHCIDRecord $ HIPRecord $ SPFRecord ) ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME >>>>>>>>>>>>>>>> 'idnsZone' DESC >>>>>>>>>>>>>>>> 'Zone >>>>>>>>>>>>>>>> class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ >>>>>>>>>>>>>>>> idnsSOAmName $ >>>>>>>>>>>>>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ >>>>>>>>>>>>>>>> idnsSOAretry $ >>>>>>>>>>>>>>>> idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ >>>>>>>>>>>>>>>> idnsAllowQuery $ >>>>>>>>>>>>>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ >>>>>>>>>>>>>>>> idnsForwarders $ >>>>>>>>>>>>>>>> idnsSecInlineSigning $ nSEC3PARAMRecord ) ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME >>>>>>>>>>>>>>>> 'idnsConfigObject' DESC >>>>>>>>>>>>>>>> 'DNS global config options' STRUCTURAL MAY ( >>>>>>>>>>>>>>>> idnsForwardPolicy $ >>>>>>>>>>>>>>>> idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ >>>>>>>>>>>>>>>> idnsPersistentSearch ) ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME >>>>>>>>>>>>>>>> 'ipaDNSZone' >>>>>>>>>>>>>>>> SUP top >>>>>>>>>>>>>>>> AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME >>>>>>>>>>>>>>>> 'idnsForwardZone' DESC >>>>>>>>>>>>>>>> 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ >>>>>>>>>>>>>>>> idnsZoneActive ) >>>>>>>>>>>>>>>> MAY ( idnsForwarders $ idnsForwardPolicy ) ) >>>>>>>>>>>>>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME >>>>>>>>>>>>>>>> 'idnsSecKey' >>>>>>>>>>>>>>>> DESC 'DNSSEC >>>>>>>>>>>>>>>> key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ >>>>>>>>>>>>>>>> idnsSecKeyCreated $ >>>>>>>>>>>>>>>> idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ >>>>>>>>>>>>>>>> idnsSecKeyActivate $ >>>>>>>>>>>>>>>> idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ >>>>>>>>>>>>>>>> idnsSecKeyRevoke $ >>>>>>>>>>>>>>>> idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' ) >>>>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME >>>>>>>>>>>>>>>> 'ipaLocationObject' DESC >>>>>>>>>>>>>>>> 'Object for storing IPA server location' AUXILIARY MUST ( >>>>>>>>>>>>>>>> idnsName >>>>>>>>>>>>>>>> ) MAY ( >>>>>>>>>>>>>>>> description ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>>>> Why is it AUXILIARY? AFAIK it should be STRUCTURAL because >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> will not be >>>>>>>>>>>>>>> any other object class on the location object (at least not >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> beginning). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME >>>>>>>>>>>>>>>> 'ipaLocationMember' DESC >>>>>>>>>>>>>>>> 'Member object of IPA location' AUXILIARY MAY ( >>>>>>>>>>>>>>>> ipaLocation $ >>>>>>>>>>>>>>>> ipaLocationWeight ) X-ORIGIN 'IPA v4.4' ) >>>>>>>>>>>>>>> Conditional ACK if you fix ipaLocationObject. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> freeipa-mbasti-0475-DNS-Locations-Add-location-commands.patch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From 407b935ecd6df0ed98c6df6d45a575229ef3cd09 Mon >>>>>>>>>>>>>>>> Sep 17 >>>>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>>>> From: Martin Basti >>>>>>>>>>>>>>>> Date: Thu, 5 May 2016 11:13:07 +0200 >>>>>>>>>>>>>>>> Subject: [PATCH 3/4] DNS Locations: Add location-* commands >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Added location-{add,mod,del,find,show} commands. Command >>>>>>>>>>>>>>>> are just >>>>>>>>>>>>>>>> prototypes and does not provide any information about >>>>>>>>>>>>>>>> server (will be >>>>>>>>>>>>>>>> done later) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2008 >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> ACI.txt | 8 ++ >>>>>>>>>>>>>>>> API.txt | 59 >>>>>>>>>>>>>>>> ++++++++++++++ >>>>>>>>>>>>>>>> VERSION | 4 +- >>>>>>>>>>>>>>>> install/share/bootstrap-template.ldif | 6 ++ >>>>>>>>>>>>>>>> install/updates/37-locations.update | 4 + >>>>>>>>>>>>>>>> install/updates/Makefile.am | 1 + >>>>>>>>>>>>>>>> ipalib/constants.py | 1 + >>>>>>>>>>>>>>>> ipalib/plugins/location.py | 142 >>>>>>>>>>>>>>>> +++++++++++++++++++++++++++++++++- >>>>>>>>>>>>>>>> 8 files changed, 222 insertions(+), 3 deletions(-) >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git a/VERSION b/VERSION >>>>>>>>>>>>>>>> index >>>>>>>>>>>>>>>> aedebd185821d42fa48608f4c5fdf9ff510ace3f..7e3def151e9986454509a580515b9d34dc220a60 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>>> --- a/VERSION >>>>>>>>>>>>>>>> +++ b/VERSION >>>>>>>>>>>>>>>> @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 >>>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>>> -IPA_API_VERSION_MINOR=165 >>>>>>>>>>>>>>>> -# Last change: mbasti - limit ipamaxusernamelength value >>>>>>>>>>>>>>>> to 255 >>>>>>>>>>>>>>>> +IPA_API_VERSION_MINOR=166 >>>>>>>>>>>>>>>> +# Last change: mbasti - location-* commands >>>>>>>>>>>>>>> Needs rebase. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>>> b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>>> index >>>>>>>>>>>>>>>> 628a8e2e0f5483b9f6f565b0c7d11eb000a5912d..83be4399508a905f8eae7e2f59140a6b4051b661 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>>> --- a/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>>> +++ b/install/share/bootstrap-template.ldif >>>>>>>>>>>>>>>> @@ -119,6 +119,12 @@ objectClass: nsContainer >>>>>>>>>>>>>>>> objectClass: top >>>>>>>>>>>>>>>> cn: etc >>>>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>>>> +changetype: add >>>>>>>>>>>>>>>> +objectClass: nsContainer >>>>>>>>>>>>>>>> +objectClass: top >>>>>>>>>>>>>>>> +cn: locations >>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>> dn: cn=sysaccounts,cn=etc,$SUFFIX >>>>>>>>>>>>>>>> changetype: add >>>>>>>>>>>>>>>> objectClass: nsContainer >>>>>>>>>>>>>>>> diff --git a/install/updates/37-locations.update >>>>>>>>>>>>>>>> b/install/updates/37-locations.update >>>>>>>>>>>>>>>> index >>>>>>>>>>>>>>>> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf47e6d6296af830a76aad2c9b9f5a6ea5d9f3a1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>>> --- a/install/updates/37-locations.update >>>>>>>>>>>>>>>> +++ b/install/updates/37-locations.update >>>>>>>>>>>>>>>> @@ -0,0 +1,4 @@ >>>>>>>>>>>>>>>> +dn: cn=locations,cn=etc,$SUFFIX >>>>>>>>>>>>>>>> +default: objectClass: nsContainer >>>>>>>>>>>>>>>> +default: objectClass: top >>>>>>>>>>>>>>>> +default: cn: locations >>>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git a/ipalib/plugins/location.py >>>>>>>>>>>>>>>> b/ipalib/plugins/location.py >>>>>>>>>>>>>>>> index >>>>>>>>>>>>>>>> 8090bb1637c4d826b9a746a82b98ece903e321cc..d52d2baeb8bfb2fddeac40b281268622d47c6aeb >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 100644 >>>>>>>>>>>>>>>> --- a/ipalib/plugins/location.py >>>>>>>>>>>>>>>> +++ b/ipalib/plugins/location.py >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>> +__doc__ = _(""" >>>>>>>>>>>>>>>> +IPA locations >>>>>>>>>>>>>>>> +""") + _(""" >>>>>>>>>>>>>>>> +Manipulate with DNS locations >>>>>>>>>>>>>>> IMHO "with" should be omited. [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>>>> +class location(LDAPObject): >>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>> + IPA locations >>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + permission_filter_objectclasses = ['ipaLocationObject'] >>>>>>>>>>>>>>>> + managed_permissions = { >>>>>>>>>>>>>>>> + 'System: Read IPA Locations': { >>>>>>>>>>>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>>>> + 'objectclass', 'idnsname', 'description', >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + 'System: Add IPA Locations': { >>>>>>>>>>>>>>>> + 'ipapermright': {'add'}, >>>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + 'System: Remove IPA Locations': { >>>>>>>>>>>>>>>> + 'ipapermright': {'delete'}, >>>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + 'System: Modify IPA Locations': { >>>>>>>>>>>>>>>> + 'ipapermright': {'write'}, >>>>>>>>>>>>>>>> + 'ipapermdefaultattr': { >>>>>>>>>>>>>>>> + 'description', >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + 'default_privileges': {'DNS Administrators'}, >>>>>>>>>>>>>>>> + }, >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> Sounds reasonable. ACI does not allow renaming location but >>>>>>>>>>>>>>> IMHO >>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>> okay. >>>>>>>>>>>>>>> Less renames we support the better. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>> + takes_params = ( >>>>>>>>>>>>>>>> + DNSNameParam( >>>>>>>>>>>>>>>> + 'idnsname', >>>>>>>>>>>>>>>> + cli_name='name', >>>>>>>>>>>>>>>> + primary_key=True, >>>>>>>>>>>>>>>> + label=_('Location name'), >>>>>>>>>>>>>>>> + doc=_('IPA location name'), >>>>>>>>>>>>>>>> + # dns name must be relative, we will put it >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> middle of >>>>>>>>>>>>>>>> + # location domain name for location records >>>>>>>>>>>>>>>> + only_relative=True, >>>>>>>>>>>>>>>> + ), >>>>>>>>>>>>>>> Okay. We need to make sure that relative names with multiple >>>>>>>>>>>>>>> labels >>>>>>>>>>>>>>> work - >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> this should automagically work as long as we are handling >>>>>>>>>>>>>>> DNS names >>>>>>>>>>>>>>> using >>>>>>>>>>>>>>> proper data types (not as strings). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + Str( >>>>>>>>>>>>>>>> + 'description?', >>>>>>>>>>>>>>>> + label=_('Description'), >>>>>>>>>>>>>>>> + doc=_('IPA Location description'), >>>>>>>>>>>>>>>> + ), >>>>>>>>>>>>>>> After discussion with Honza we will keep description as >>>>>>>>>>>>>>> single-value >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> IPA framework and ignore that description attribute is >>>>>>>>>>>>>>> multi-value >>>>>>>>>>>>>>> in LDAP. >>>>>>>>>>>>>>> This is done for consitency with mistakes from the past. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + at register() >>>>>>>>>>>>>>>> +class location_mod(LDAPUpdate): >>>>>>>>>>>>>>>> + __doc__ = _('Modify information about an IPA >>>>>>>>>>>>>>>> location .') >>>>>>>>>>>>>>> This should say 'Modify description' because nothing else >>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>> modified. >>>>>>>>>>>>>>> More specific text would hopefully stop some people from >>>>>>>>>>>>>>> looking for >>>>>>>>>>>>>>> rename >>>>>>>>>>>>>>> options. >>>>>>>>>>>>>> I disagree, this is general description about the modify >>>>>>>>>>>>>> command, see >>>>>>>>>>>>>> privilege-add it is the same as I made. I can see in future >>>>>>>>>>>>>> that we will >>>>>>>>>>>>>> forgot to update description of command if we add something >>>>>>>>>>>>>> new there. >>>>>>>>>>>>> This is really an invalid argument. >>>>>>>>>>>>> >>>>>>>>>>>>> "We must not touch XYZ because its documentation might become >>>>>>>>>>>>> obsolete in >>>>>>>>>>>>> future if we forget to update it!" :-) >>>>>>>>>>>>> >>>>>>>>>>>> How about inconsistency with description of older commands? I >>>>>>>>>>>> don't >>>>>>>>>>>> think that >>>>>>>>>>>> command description should describe attributes that are allowed >>>>>>>>>>>> to change. >>>>>>>>>>>> Allowed attributes are shown in --help output >>>>>>>>>>> I do not agree but push whatever variant you like, it costed too >>>>>>>>>>> much >>>>>>>>>>> already. >>>>>>>>>> NACK anyway. ipa-dns-install screams if you install a server >>>>>>>>>> without DNS and >>>>>>>>>> run ipa-dns-install later on: >>>>>>>>>> >>>>>>>>>> The log contains this: >>>>>>>>>> >>>>>>>>>> add objectClass: >>>>>>>>>> top >>>>>>>>>> groupofnames >>>>>>>>>> nestedgroup >>>>>>>>>> add cn: >>>>>>>>>> DNS Administrators >>>>>>>>>> add description: >>>>>>>>>> DNS Administrators >>>>>>>>>> adding new entry "cn=DNS >>>>>>>>>> Administrators,cn=privileges,cn=pbac,dc=dom-033,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016-05-10T16:53:05Z DEBUG stderr=ldap_initialize( >>>>>>>>>> ldapi://%2Fvar%2Frun%2Fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket/??base >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ) >>>>>>>>>> SASL/EXTERNAL authentication started >>>>>>>>>> SASL username: >>>>>>>>>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>>>>>>>> SASL SSF: 0 >>>>>>>>>> ldap_add: Already exists (68) >>>>>>>>>> >>>>>>>>>> 2016-05-10T16:53:05Z CRITICAL Failed to load dns.ldif: Command >>>>>>>>>> '/usr/bin/ldapmodify -v -f /tmp/tmpMvWMaT -H >>>>>>>>>> ldapi://%2fvar%2frun%2fslapd-DOM-033-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >>>>>>>>>> >>>>>>>>>> -Y >>>>>>>>>> >>>>>>>>>> EXTERNAL' returned non-zero exit status 68 >>>>>>>>>> >>>>>>>>> Well I cannot reproduce it, this should be resolved by patch 473 >>>>>>>>> >>>>>>>> Updated patches attached >>>>>>>> >>>>>>>> I found that IDNA did not work with previous version, fixed + IDNA >>>>>>>> tests added >>>>>>>> >>>>>>>> >>>>>>> Fixed here, I sent wrong patches before >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> More patches added, all patches are available here: >>>>>> https://github.com/bastiak/freeipa/tree/DNS-locations >>>>> Functional NACK >>>>> >>>>> location-show returns incorrect location weight for servers >>>>> >>>>> # ipa server-show vm-046.abc.idm.lab.eng.brq.redhat.com --all >>>>> dn: >>>>> cn=vm-046.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=dom-058-082,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>>>> >>>>> >>>>> Server name: vm-046.abc.idm.lab.eng.brq.redhat.com >>>>> Managed suffixes: domain >>>>> Min domain level: 0 >>>>> Max domain level: 1 >>>>> Location: l2 >>>>> Location weight: 200 >>>>> objectclass: ipalocationmember, ipaReplTopoManagedServer, top, >>>>> ipaConfigObject, nsContainer, ipaSupportedDomainLevelConfig >>>>> >>>>> # ipa location-show l2 >>>>> Location name: l2 >>>>> Description: Loc 2 >>>>> Servers: vm-046.abc.idm.lab.eng.brq.redhat.com (weight: 100) >>>>> >>>>> - Did you forget --all somewhere? >>>> Nope, I forgot to put it to default attributes, nice catch, I will add >>>> test for it. >>>>> >>>>> Other than that I have only nitpick regarding error message: >>>>> ipa: ERROR: l2 cannot be deleted because IPA Server(s) >>>>> vm-046.abc.idm.lab.eng.brq.redhat.com requires it >>>>> >>>>> - Please unify singular/plural. >>>> This is how the exception is generated, so you can choose just >>>> label, so >>>> which label is the right? {'IPA server', 'IPA servers', 'IPA >>>> server(s)'} >>>> (I think server should be with lower cased 's') >>>> raise DependentEntry( >>>> label=_('IPA Server(s)'), >>>> key=keys[-1], >>>> dependent=location_members >>>> ) >>> >>> Use ngettext here to handle singular/plural correctly. >> It will fix only half of sentence, I put there just singular. >> >>> >>>>> >>>>> I did not require the code because Honza will surely look into >>>>> details. >>> >>> "Allow to use non-Str attributes as keys for members": >>> >>> There is no actual API change, so don't bump VERSION. >> Bump version removed >> >>> >>> >>> "Remove CSV from from member params": >>> >>> Again, no actual API change, don't bump VERSION. >>> >>> CSV params should be removed completely. I have a patch in my drawer >>> which does exactly that, should I post it? >>> >> Removed >> >> Please post it. >> >>> >>> "DNS Locations: extend server-* command with locations": >>> >>> I don't think ipalocationweight should be in server-find. Searching >>> for servers by exact weight does not strike me as something useful. >>> Or is it? >> I agree, it will even not work with default location weight >> >>> >>> In server.normalize_location(), don't call location.get_dn() with >>> **options, as it contains server options, not location options. Also >>> you are calling kw.pop('ipalocation_location') twice, which is most >>> likely a bug. >> Fixed. >> It is not twice, it was called in different if-else branches, but I >> rewrote the code it should looks better now. >> >>> >>> In server_mod.pre_callback(), don't raise NotFound manually, but >>> rather use self.api.Object.location.handle_not_found(). >>> >> Changed >>> >>> Honza >>> >> >> Updated patches attached. >> >> > Rebased patches attached "DNS Location: location-show: return list of servers in location": The list of servers should be returned only without --raw. Otherwise LGTM. -- Jan Cholasta From slaznick at redhat.com Thu May 26 06:13:56 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 26 May 2016 08:13:56 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin In-Reply-To: References: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> <0630f6c9-9d94-015b-f689-51ce0f3005d3@redhat.com> Message-ID: <98555b78-a869-ce89-e319-a575e6050a28@redhat.com> On 05/25/2016 06:21 PM, Martin Basti wrote: > > On 25.05.2016 09:11, Stanislav Laznicka wrote: >> >> LGTM, could you please just add the ticket to the commit message? >> >> >> On 05/20/2016 04:28 PM, Martin Basti wrote: >>> >>> >>> >>> On 20.05.2016 15:03, Martin Basti wrote: >>>> The removed code is unused for long time. >>>> >>>> Patch attached. >>>> >>>> >>>> >>> https://fedorahosted.org/freeipa/attachment/ticket/5899/ >>> >>> >> > updated patch attached. ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu May 26 07:32:17 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 May 2016 10:32:17 +0300 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5745FD89.3070601@redhat.com> References: <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> Message-ID: <20160526073217.dyxqosmkpb4hzira@redhat.com> On Wed, 25 May 2016, Rob Crittenden wrote: >thierry bordaz wrote: >> >> >>On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>thierry bordaz wrote: >>>> >>>>Hello, >>>> >>>>Thanks for all the feedbacks. I updated the design accordingly and with >>>>additional tests results >>>>(http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>> >>>>Several improvements can be done, in particular in DS plugins (memberof, >>>>retroCL), but for "easy" benefit provisioning will be done with memberof >>>>disabled followed by fixup. >>>> >>>>It remains some aspects that are not clear to me: >>>> >>>> * For best performance, DS tuning and provisioning/fixup would >>>> preferably be done under 'directory manager' >>>> That means prompting DM password and writing it into temporary file. >>>> Is that a concern ? >>>> * Fixup requires that we know the filters matching the provisioned >>>> entries. For example : >>>> o (objectClass=inetorgperson) >>>> o (objectClass=ipausergroup) >>>> o (objectClass=ipahost) >>>> o (objectClass=ipahostgroup) >>>> o (objectClass=ipasudorule) >>>> o (objectClass=ipahbacrule) >>>> >>>> The set of objectclass could be hardcode or provided in the >>>> provisioning CLI option >>>> What to do if an entry in in the provision file does not match >>>> any of those filter ? Should it stop without starting the >>>> provisioning ? >>>> * The CLI doing the provisioning could be something like 'ipa >>>> provision ' or should it be a separated command e.g. >>>> ipa-bulk-load ? >>> >>>It depends. There is a migration command now, ipa migrate-ds, that >>>adds records and is impacted by this. There is also the possibility of >>>looping calls to ipa [user|group|etc]-add. >> >>I agree that migration and bulk load can be linked. If migration >>dump/update a set of entries before filling them into a new instance it >>could use bulk load. >>For set loop of ipa -add, I think they add many others direct >>operations (mainly SRCH) before doing the ADD in order to check >>coherency. bulk load looks more straightforward. > >I just wonder if some (all) of this could be done manually. Document >how to turn off memberof, do the import whatever way is appropriate, >then run the fixup? I'm not sure what you had in mind. > >I don't want to think small but do we expect to be importing a slew of >hosts, sudorules, etc? I guess the potential is there but would it be >on the same scale as users? If you focus only on users/groups does >that change the use case at all? I tend to agree with Rob on this. Maybe we should have a simple script/update file that does preparatory work and another one that returns configuration into the right state and document how to use them. -- / Alexander Bokovoy From tbordaz at redhat.com Thu May 26 08:35:05 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 26 May 2016 10:35:05 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5745FD89.3070601@redhat.com> References: <5729E929.6010307@redhat.com> <5732034E.5080405@redhat.com> <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> Message-ID: <5746B539.5060300@redhat.com> On 05/25/2016 09:31 PM, Rob Crittenden wrote: > thierry bordaz wrote: >> >> >> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>> thierry bordaz wrote: >>>> >>>> Hello, >>>> >>>> Thanks for all the feedbacks. I updated the design accordingly and >>>> with >>>> additional tests results >>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>> >>>> >>>> Several improvements can be done, in particular in DS plugins >>>> (memberof, >>>> retroCL), but for "easy" benefit provisioning will be done with >>>> memberof >>>> disabled followed by fixup. >>>> >>>> It remains some aspects that are not clear to me: >>>> >>>> * For best performance, DS tuning and provisioning/fixup would >>>> preferably be done under 'directory manager' >>>> That means prompting DM password and writing it into temporary >>>> file. >>>> Is that a concern ? >>>> * Fixup requires that we know the filters matching the provisioned >>>> entries. For example : >>>> o (objectClass=inetorgperson) >>>> o (objectClass=ipausergroup) >>>> o (objectClass=ipahost) >>>> o (objectClass=ipahostgroup) >>>> o (objectClass=ipasudorule) >>>> o (objectClass=ipahbacrule) >>>> >>>> The set of objectclass could be hardcode or provided in the >>>> provisioning CLI option >>>> What to do if an entry in in the provision file does not match >>>> any of those filter ? Should it stop without starting the >>>> provisioning ? >>>> * The CLI doing the provisioning could be something like 'ipa >>>> provision ' or should it be a separated command e.g. >>>> ipa-bulk-load ? >>> >>> It depends. There is a migration command now, ipa migrate-ds, that >>> adds records and is impacted by this. There is also the possibility of >>> looping calls to ipa [user|group|etc]-add. >> >> I agree that migration and bulk load can be linked. If migration >> dump/update a set of entries before filling them into a new instance it >> could use bulk load. >> For set loop of ipa -add, I think they add many others direct >> operations (mainly SRCH) before doing the ADD in order to check >> coherency. bulk load looks more straightforward. > > I just wonder if some (all) of this could be done manually. Document > how to turn off memberof, do the import whatever way is appropriate, > then run the fixup? I'm not sure what you had in mind. > > I don't want to think small but do we expect to be importing a slew of > hosts, sudorules, etc? I guess the potential is there but would it be > on the same scale as users? If you focus only on users/groups does > that change the use case at all? > In fact, I am using such small scripts to prepare and run/monitor the provisioning. If providing a set of scripts and document a procedure is enough I am fine with this. >>> Would it be reasonable to require bulk import to be done on an IPA >>> master so we can leverage the ldapi socket? >> Do you mean using ldapi to reduce network latency or automember or >> something else ? > > To avoid the DM password issues. ldapi autobinds to DM when the id is > root. Yes I said automember but was thinking to autobind. That is nice idea to avoid prompting DM password. In addition, slapi-nis participating to slowing down the provisioning if it is using ldapi/DM slapi-nis will be offline by itself. The limitation would be to run the provisioning on IPA master. During provisioning, membership attribute will be invalid (memberof not computed). Is it acceptable that IPA master contains invalid membership for some time ? > > rob > From tbordaz at redhat.com Thu May 26 08:57:37 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 26 May 2016 10:57:37 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <20160526073217.dyxqosmkpb4hzira@redhat.com> References: <167721f0-c2c6-0e99-1b2b-eb4a96aa1697@redhat.com> <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <20160526073217.dyxqosmkpb4hzira@redhat.com> Message-ID: <5746BA81.3060807@redhat.com> On 05/26/2016 09:32 AM, Alexander Bokovoy wrote: > On Wed, 25 May 2016, Rob Crittenden wrote: >> thierry bordaz wrote: >>> >>> >>> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>> thierry bordaz wrote: >>>>> >>>>> Hello, >>>>> >>>>> Thanks for all the feedbacks. I updated the design accordingly and >>>>> with >>>>> additional tests results >>>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>> >>>>> >>>>> Several improvements can be done, in particular in DS plugins >>>>> (memberof, >>>>> retroCL), but for "easy" benefit provisioning will be done with >>>>> memberof >>>>> disabled followed by fixup. >>>>> >>>>> It remains some aspects that are not clear to me: >>>>> >>>>> * For best performance, DS tuning and provisioning/fixup would >>>>> preferably be done under 'directory manager' >>>>> That means prompting DM password and writing it into temporary >>>>> file. >>>>> Is that a concern ? >>>>> * Fixup requires that we know the filters matching the provisioned >>>>> entries. For example : >>>>> o (objectClass=inetorgperson) >>>>> o (objectClass=ipausergroup) >>>>> o (objectClass=ipahost) >>>>> o (objectClass=ipahostgroup) >>>>> o (objectClass=ipasudorule) >>>>> o (objectClass=ipahbacrule) >>>>> >>>>> The set of objectclass could be hardcode or provided in the >>>>> provisioning CLI option >>>>> What to do if an entry in in the provision file does not match >>>>> any of those filter ? Should it stop without starting the >>>>> provisioning ? >>>>> * The CLI doing the provisioning could be something like 'ipa >>>>> provision ' or should it be a separated command e.g. >>>>> ipa-bulk-load ? >>>> >>>> It depends. There is a migration command now, ipa migrate-ds, that >>>> adds records and is impacted by this. There is also the possibility of >>>> looping calls to ipa [user|group|etc]-add. >>> >>> I agree that migration and bulk load can be linked. If migration >>> dump/update a set of entries before filling them into a new instance it >>> could use bulk load. >>> For set loop of ipa -add, I think they add many others direct >>> operations (mainly SRCH) before doing the ADD in order to check >>> coherency. bulk load looks more straightforward. >> >> I just wonder if some (all) of this could be done manually. Document >> how to turn off memberof, do the import whatever way is appropriate, >> then run the fixup? I'm not sure what you had in mind. >> >> I don't want to think small but do we expect to be importing a slew >> of hosts, sudorules, etc? I guess the potential is there but would it >> be on the same scale as users? If you focus only on users/groups does >> that change the use case at all? > I tend to agree with Rob on this. Maybe we should have a simple > script/update file that does preparatory work and another one that > returns configuration into the right state and document how to use them. Ok. rereading the thread I realize we are talking of user/usergroups/host/hostgroup. Provisioning such entries is not that bad. For example 5Kusers/hosts are provisioned in 5min without memberof and 19min with memberof The real problem is provisioning sudorules and hbacrules where the impact of memberof is very important. For example 100 sudorules are provisioned in 30s without memberof and 2h with memberof. Do you think provisioning should also considere sudorules/hbac or only user/usergroups/host/hostgroup ? From abokovoy at redhat.com Thu May 26 09:11:01 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 May 2016 12:11:01 +0300 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5746BA81.3060807@redhat.com> References: <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <20160526073217.dyxqosmkpb4hzira@redhat.com> <5746BA81.3060807@redhat.com> Message-ID: <20160526091100.vp42rmqppvktssyu@redhat.com> On Thu, 26 May 2016, thierry bordaz wrote: > > >On 05/26/2016 09:32 AM, Alexander Bokovoy wrote: >>On Wed, 25 May 2016, Rob Crittenden wrote: >>>thierry bordaz wrote: >>>> >>>> >>>>On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>>thierry bordaz wrote: >>>>>> >>>>>>Hello, >>>>>> >>>>>>Thanks for all the feedbacks. I updated the design >>>>>>accordingly and with >>>>>>additional tests results >>>>>>(http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>>> >>>>>> >>>>>>Several improvements can be done, in particular in DS >>>>>>plugins (memberof, >>>>>>retroCL), but for "easy" benefit provisioning will be done >>>>>>with memberof >>>>>>disabled followed by fixup. >>>>>> >>>>>>It remains some aspects that are not clear to me: >>>>>> >>>>>> * For best performance, DS tuning and provisioning/fixup would >>>>>> preferably be done under 'directory manager' >>>>>> That means prompting DM password and writing it into >>>>>>temporary file. >>>>>> Is that a concern ? >>>>>> * Fixup requires that we know the filters matching the provisioned >>>>>> entries. For example : >>>>>> o (objectClass=inetorgperson) >>>>>> o (objectClass=ipausergroup) >>>>>> o (objectClass=ipahost) >>>>>> o (objectClass=ipahostgroup) >>>>>> o (objectClass=ipasudorule) >>>>>> o (objectClass=ipahbacrule) >>>>>> >>>>>> The set of objectclass could be hardcode or provided in the >>>>>> provisioning CLI option >>>>>> What to do if an entry in in the provision file does not match >>>>>> any of those filter ? Should it stop without starting the >>>>>> provisioning ? >>>>>> * The CLI doing the provisioning could be something like 'ipa >>>>>> provision ' or should it be a separated command e.g. >>>>>> ipa-bulk-load ? >>>>> >>>>>It depends. There is a migration command now, ipa migrate-ds, that >>>>>adds records and is impacted by this. There is also the possibility of >>>>>looping calls to ipa [user|group|etc]-add. >>>> >>>>I agree that migration and bulk load can be linked. If migration >>>>dump/update a set of entries before filling them into a new instance it >>>>could use bulk load. >>>>For set loop of ipa -add, I think they add many others direct >>>>operations (mainly SRCH) before doing the ADD in order to check >>>>coherency. bulk load looks more straightforward. >>> >>>I just wonder if some (all) of this could be done manually. >>>Document how to turn off memberof, do the import whatever way is >>>appropriate, then run the fixup? I'm not sure what you had in >>>mind. >>> >>>I don't want to think small but do we expect to be importing a >>>slew of hosts, sudorules, etc? I guess the potential is there but >>>would it be on the same scale as users? If you focus only on >>>users/groups does that change the use case at all? >>I tend to agree with Rob on this. Maybe we should have a simple >>script/update file that does preparatory work and another one that >>returns configuration into the right state and document how to use them. > >Ok. >rereading the thread I realize we are talking of >user/usergroups/host/hostgroup. > >Provisioning such entries is not that bad. >For example 5Kusers/hosts are provisioned in 5min without memberof and >19min with memberof > >The real problem is provisioning sudorules and hbacrules where the >impact of memberof is very important. >For example 100 sudorules are provisioned in 30s without memberof and >2h with memberof. > >Do you think provisioning should also considere sudorules/hbac or only >user/usergroups/host/hostgroup ? I think it should consider all objects we support in the default configuration. -- / Alexander Bokovoy From abokovoy at redhat.com Thu May 26 09:12:53 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 May 2016 12:12:53 +0300 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5746B539.5060300@redhat.com> References: <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> Message-ID: <20160526091253.mpcky4rlqvn7pa5c@redhat.com> On Thu, 26 May 2016, thierry bordaz wrote: > > >On 05/25/2016 09:31 PM, Rob Crittenden wrote: >>thierry bordaz wrote: >>> >>> >>>On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>thierry bordaz wrote: >>>>> >>>>>Hello, >>>>> >>>>>Thanks for all the feedbacks. I updated the design accordingly >>>>>and with >>>>>additional tests results >>>>>(http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>> >>>>> >>>>>Several improvements can be done, in particular in DS plugins >>>>>(memberof, >>>>>retroCL), but for "easy" benefit provisioning will be done >>>>>with memberof >>>>>disabled followed by fixup. >>>>> >>>>>It remains some aspects that are not clear to me: >>>>> >>>>> * For best performance, DS tuning and provisioning/fixup would >>>>> preferably be done under 'directory manager' >>>>> That means prompting DM password and writing it into >>>>>temporary file. >>>>> Is that a concern ? >>>>> * Fixup requires that we know the filters matching the provisioned >>>>> entries. For example : >>>>> o (objectClass=inetorgperson) >>>>> o (objectClass=ipausergroup) >>>>> o (objectClass=ipahost) >>>>> o (objectClass=ipahostgroup) >>>>> o (objectClass=ipasudorule) >>>>> o (objectClass=ipahbacrule) >>>>> >>>>> The set of objectclass could be hardcode or provided in the >>>>> provisioning CLI option >>>>> What to do if an entry in in the provision file does not match >>>>> any of those filter ? Should it stop without starting the >>>>> provisioning ? >>>>> * The CLI doing the provisioning could be something like 'ipa >>>>> provision ' or should it be a separated command e.g. >>>>> ipa-bulk-load ? >>>> >>>>It depends. There is a migration command now, ipa migrate-ds, that >>>>adds records and is impacted by this. There is also the possibility of >>>>looping calls to ipa [user|group|etc]-add. >>> >>>I agree that migration and bulk load can be linked. If migration >>>dump/update a set of entries before filling them into a new instance it >>>could use bulk load. >>>For set loop of ipa -add, I think they add many others direct >>>operations (mainly SRCH) before doing the ADD in order to check >>>coherency. bulk load looks more straightforward. >> >>I just wonder if some (all) of this could be done manually. Document >>how to turn off memberof, do the import whatever way is appropriate, >>then run the fixup? I'm not sure what you had in mind. >> >>I don't want to think small but do we expect to be importing a slew >>of hosts, sudorules, etc? I guess the potential is there but would >>it be on the same scale as users? If you focus only on users/groups >>does that change the use case at all? >> >In fact, I am using such small scripts to prepare and run/monitor the >provisioning. >If providing a set of scripts and document a procedure is enough I am >fine with this. > >>>>Would it be reasonable to require bulk import to be done on an IPA >>>>master so we can leverage the ldapi socket? >>>Do you mean using ldapi to reduce network latency or automember or >>>something else ? >> >>To avoid the DM password issues. ldapi autobinds to DM when the id >>is root. > >Yes I said automember but was thinking to autobind. >That is nice idea to avoid prompting DM password. >In addition, slapi-nis participating to slowing down the provisioning >if it is using ldapi/DM slapi-nis will be offline by itself. > >The limitation would be to run the provisioning on IPA master. During >provisioning, membership attribute will be invalid (memberof not >computed). Is it acceptable that IPA master contains invalid >membership for some time ? Consider provisioning to be at the same level as running ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is the only interface enabled which implies there would be no problem if we set expectations right: provisioning mode is offline. -- / Alexander Bokovoy From mbasti at redhat.com Thu May 26 09:21:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 11:21:13 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> Message-ID: On 26.05.2016 07:15, Jan Cholasta wrote: > On 25.5.2016 18:17, Martin Basti wrote: >> >> >> On 25.05.2016 16:07, Jan Cholasta wrote: >>> On 25.5.2016 15:03, David Kupka wrote: >>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>> . >>>>>>>>> >>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>> imports" should be good for review. The rest is subject to change >>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> I did not test it yet, I just checked the code >>>>>>>> >>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>> LDAPQuery * >>>>>>>> LGTM >>>>>>>> >>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>> class * >>>>>>>> LGTM >>>>>>>> >>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>> client * >>>>>>>> 1) >>>>>>>> you forgot to increment VERSION >>>>>>> >>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>> VERSION >>>>>>> for backward compatible changes after this whole patchset is >>>>>>> merged. >>>>>>> But we're not there yet, so fixed. >>>>>>> >>>>>> How we should handle VERSION after your patches? >>>>>>>> >>>>>>>> Otherwise LGTM >>>>>>>> >>>>>>>> * otptoken: fix import of DN * >>>>>>>> ACK >>>>>>>> >>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>> 1) >>>>>>>> you forgot to increment VERSION >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> Did you find out why this was issue? >>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>> omitted? >>>>>>>> - del answer['summary'] # Why does this cause an error if >>>>>>>> omitted? >>>>>>> >>>>>>> The command definition was not complete, it was missing has_output. >>>>>>> >>>>>>>> >>>>>>>> Otherwise LGTM >>>>>>>> >>>>>>>> * vault: move client-side code to the module level * >>>>>>>> LGTM >>>>>>>> >>>>>>>> * vault: copy arguments of client commands from server >>>>>>>> counterparts * >>>>>>>> 1) >>>>>>>> you forgot to increment Version >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>> needed >>>>>>>> in commit message >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> The other commits I will check later. >>>>>>>> Martin^2 >>>>>>>> >>>>>>> >>>>>>> Okay. Thanks. >>>>>>> >>>>>> >>>>>> * frontend: remove the unused Command.soft_validate method >>>>>> LGTM >>>>>> >>>>>> * frontend: perform argument value validation only on server >>>>>> LGTM >>>>>> >>>>>> * frontend: do not forward argument defaults to server >>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>> havent >>>>>> found anything better to use. >>>>> >>>>> It always returned None for unset params. >>>>> >>>>>> LGTM >>>>>> >>>>>> * ipalib: optimize API.txt >>>>>> this contains a lot of black magic, but because this is mainly >>>>>> copy of >>>>>> current to proper places, LGTM >>>>> >>>>> It's actually mostly cut-n-paste. >>>>> >>>>>> >>>>>> * makeaci: load additional plugins using API.add_module >>>>>> Looks good, but I miss explanation why is this change needed >>>>> >>>>> The next change would be impossible without this. >>>>> >>>>>> >>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>> LGTM >>>>>> >>>>>> >>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>> registration >>>>>> ACK >>>>>> >>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>> LGTM >>>>>> >>>>>> >>>>>> * plugable: remove the unused deprecated API.register method >>>>>> LGTM >>>>>> >>>>>> >>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>> LGTM >>>>>> >>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>> LGTM >>>>>> >>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>> LGTM >>>>>> >>>>>> Martin^2 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> Hello, >>>> first batch of 30 patches from Honza's trac-4739 branch >>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready to be >>>> pushed into master. >>>> All upto "frontend: allow commands to have an argument named >>>> `name`" got >>>> over numerous test&fix cycles in last week+ and is working as expected >>>> now, ACK. >>> >>> Thanks for the review. >>> >>>> >>>> Honzo, please rebase and push them, thanks! >>>> >>> >>> Attaching the patches for reference. >>> >>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>> >> >> Guys, you forgot to test it with newer pylint. > > I don't see any "BuildRequires: newer pylint" in the spec file. > >> >> Patch attached. > > LGTM, although the commit message is wrong - this is not related to > thin client at all, PublicError and PublicMessage had .kw since forever. > updated commit message -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0485.2-fix-pylint-false-positive-errors.patch Type: text/x-patch Size: 999 bytes Desc: not available URL: From mbasti at redhat.com Thu May 26 09:22:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 11:22:54 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <20160526091253.mpcky4rlqvn7pa5c@redhat.com> References: <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> Message-ID: <8dc7a0bc-1f6c-959e-830d-0700002412bd@redhat.com> On 26.05.2016 11:12, Alexander Bokovoy wrote: > On Thu, 26 May 2016, thierry bordaz wrote: >> >> >> On 05/25/2016 09:31 PM, Rob Crittenden wrote: >>> thierry bordaz wrote: >>>> >>>> >>>> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>> thierry bordaz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Thanks for all the feedbacks. I updated the design accordingly >>>>>> and with >>>>>> additional tests results >>>>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>>> >>>>>> >>>>>> >>>>>> Several improvements can be done, in particular in DS plugins >>>>>> (memberof, >>>>>> retroCL), but for "easy" benefit provisioning will be done with >>>>>> memberof >>>>>> disabled followed by fixup. >>>>>> >>>>>> It remains some aspects that are not clear to me: >>>>>> >>>>>> * For best performance, DS tuning and provisioning/fixup would >>>>>> preferably be done under 'directory manager' >>>>>> That means prompting DM password and writing it into temporary >>>>>> file. >>>>>> Is that a concern ? >>>>>> * Fixup requires that we know the filters matching the provisioned >>>>>> entries. For example : >>>>>> o (objectClass=inetorgperson) >>>>>> o (objectClass=ipausergroup) >>>>>> o (objectClass=ipahost) >>>>>> o (objectClass=ipahostgroup) >>>>>> o (objectClass=ipasudorule) >>>>>> o (objectClass=ipahbacrule) >>>>>> >>>>>> The set of objectclass could be hardcode or provided in the >>>>>> provisioning CLI option >>>>>> What to do if an entry in in the provision file does not >>>>>> match >>>>>> any of those filter ? Should it stop without starting the >>>>>> provisioning ? >>>>>> * The CLI doing the provisioning could be something like 'ipa >>>>>> provision ' or should it be a separated command e.g. >>>>>> ipa-bulk-load ? >>>>> >>>>> It depends. There is a migration command now, ipa migrate-ds, that >>>>> adds records and is impacted by this. There is also the >>>>> possibility of >>>>> looping calls to ipa [user|group|etc]-add. >>>> >>>> I agree that migration and bulk load can be linked. If migration >>>> dump/update a set of entries before filling them into a new >>>> instance it >>>> could use bulk load. >>>> For set loop of ipa -add, I think they add many others direct >>>> operations (mainly SRCH) before doing the ADD in order to check >>>> coherency. bulk load looks more straightforward. >>> >>> I just wonder if some (all) of this could be done manually. Document >>> how to turn off memberof, do the import whatever way is appropriate, >>> then run the fixup? I'm not sure what you had in mind. >>> >>> I don't want to think small but do we expect to be importing a slew >>> of hosts, sudorules, etc? I guess the potential is there but would >>> it be on the same scale as users? If you focus only on users/groups >>> does that change the use case at all? >>> >> In fact, I am using such small scripts to prepare and run/monitor the >> provisioning. >> If providing a set of scripts and document a procedure is enough I am >> fine with this. >> >>>>> Would it be reasonable to require bulk import to be done on an IPA >>>>> master so we can leverage the ldapi socket? >>>> Do you mean using ldapi to reduce network latency or automember or >>>> something else ? >>> >>> To avoid the DM password issues. ldapi autobinds to DM when the id >>> is root. >> >> Yes I said automember but was thinking to autobind. >> That is nice idea to avoid prompting DM password. >> In addition, slapi-nis participating to slowing down the provisioning >> if it is using ldapi/DM slapi-nis will be offline by itself. >> >> The limitation would be to run the provisioning on IPA master. During >> provisioning, membership attribute will be invalid (memberof not >> computed). Is it acceptable that IPA master contains invalid >> membership for some time ? > Consider provisioning to be at the same level as running > ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is > the only interface enabled which implies there would be no problem if we > set expectations right: provisioning mode is offline. I agree Martin^2 From tbordaz at redhat.com Thu May 26 09:24:01 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 26 May 2016 11:24:01 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <20160526091253.mpcky4rlqvn7pa5c@redhat.com> References: <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> Message-ID: <5746C0B1.7020004@redhat.com> On 05/26/2016 11:12 AM, Alexander Bokovoy wrote: > On Thu, 26 May 2016, thierry bordaz wrote: >> >> >> On 05/25/2016 09:31 PM, Rob Crittenden wrote: >>> thierry bordaz wrote: >>>> >>>> >>>> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>> thierry bordaz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Thanks for all the feedbacks. I updated the design accordingly >>>>>> and with >>>>>> additional tests results >>>>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>>> >>>>>> >>>>>> >>>>>> Several improvements can be done, in particular in DS plugins >>>>>> (memberof, >>>>>> retroCL), but for "easy" benefit provisioning will be done with >>>>>> memberof >>>>>> disabled followed by fixup. >>>>>> >>>>>> It remains some aspects that are not clear to me: >>>>>> >>>>>> * For best performance, DS tuning and provisioning/fixup would >>>>>> preferably be done under 'directory manager' >>>>>> That means prompting DM password and writing it into temporary >>>>>> file. >>>>>> Is that a concern ? >>>>>> * Fixup requires that we know the filters matching the provisioned >>>>>> entries. For example : >>>>>> o (objectClass=inetorgperson) >>>>>> o (objectClass=ipausergroup) >>>>>> o (objectClass=ipahost) >>>>>> o (objectClass=ipahostgroup) >>>>>> o (objectClass=ipasudorule) >>>>>> o (objectClass=ipahbacrule) >>>>>> >>>>>> The set of objectclass could be hardcode or provided in the >>>>>> provisioning CLI option >>>>>> What to do if an entry in in the provision file does not >>>>>> match >>>>>> any of those filter ? Should it stop without starting the >>>>>> provisioning ? >>>>>> * The CLI doing the provisioning could be something like 'ipa >>>>>> provision ' or should it be a separated command e.g. >>>>>> ipa-bulk-load ? >>>>> >>>>> It depends. There is a migration command now, ipa migrate-ds, that >>>>> adds records and is impacted by this. There is also the >>>>> possibility of >>>>> looping calls to ipa [user|group|etc]-add. >>>> >>>> I agree that migration and bulk load can be linked. If migration >>>> dump/update a set of entries before filling them into a new >>>> instance it >>>> could use bulk load. >>>> For set loop of ipa -add, I think they add many others direct >>>> operations (mainly SRCH) before doing the ADD in order to check >>>> coherency. bulk load looks more straightforward. >>> >>> I just wonder if some (all) of this could be done manually. Document >>> how to turn off memberof, do the import whatever way is appropriate, >>> then run the fixup? I'm not sure what you had in mind. >>> >>> I don't want to think small but do we expect to be importing a slew >>> of hosts, sudorules, etc? I guess the potential is there but would >>> it be on the same scale as users? If you focus only on users/groups >>> does that change the use case at all? >>> >> In fact, I am using such small scripts to prepare and run/monitor the >> provisioning. >> If providing a set of scripts and document a procedure is enough I am >> fine with this. >> >>>>> Would it be reasonable to require bulk import to be done on an IPA >>>>> master so we can leverage the ldapi socket? >>>> Do you mean using ldapi to reduce network latency or automember or >>>> something else ? >>> >>> To avoid the DM password issues. ldapi autobinds to DM when the id >>> is root. >> >> Yes I said automember but was thinking to autobind. >> That is nice idea to avoid prompting DM password. >> In addition, slapi-nis participating to slowing down the provisioning >> if it is using ldapi/DM slapi-nis will be offline by itself. >> >> The limitation would be to run the provisioning on IPA master. During >> provisioning, membership attribute will be invalid (memberof not >> computed). Is it acceptable that IPA master contains invalid >> membership for some time ? > Consider provisioning to be at the same level as running > ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is > the only interface enabled which implies there would be no problem if we > set expectations right: provisioning mode is offline. Yes I agree, provisioning mode is offline. My concern is about side effects on the rest of the topology if we are putting IPA master offline (is password update possible on replica ?). thierry From mbasti at redhat.com Thu May 26 09:26:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 11:26:47 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5746C0B1.7020004@redhat.com> References: <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> <5746C0B1.7020004@redhat.com> Message-ID: On 26.05.2016 11:24, thierry bordaz wrote: > > > On 05/26/2016 11:12 AM, Alexander Bokovoy wrote: >> On Thu, 26 May 2016, thierry bordaz wrote: >>> >>> >>> On 05/25/2016 09:31 PM, Rob Crittenden wrote: >>>> thierry bordaz wrote: >>>>> >>>>> >>>>> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>>> thierry bordaz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Thanks for all the feedbacks. I updated the design accordingly >>>>>>> and with >>>>>>> additional tests results >>>>>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Several improvements can be done, in particular in DS plugins >>>>>>> (memberof, >>>>>>> retroCL), but for "easy" benefit provisioning will be done with >>>>>>> memberof >>>>>>> disabled followed by fixup. >>>>>>> >>>>>>> It remains some aspects that are not clear to me: >>>>>>> >>>>>>> * For best performance, DS tuning and provisioning/fixup would >>>>>>> preferably be done under 'directory manager' >>>>>>> That means prompting DM password and writing it into >>>>>>> temporary file. >>>>>>> Is that a concern ? >>>>>>> * Fixup requires that we know the filters matching the provisioned >>>>>>> entries. For example : >>>>>>> o (objectClass=inetorgperson) >>>>>>> o (objectClass=ipausergroup) >>>>>>> o (objectClass=ipahost) >>>>>>> o (objectClass=ipahostgroup) >>>>>>> o (objectClass=ipasudorule) >>>>>>> o (objectClass=ipahbacrule) >>>>>>> >>>>>>> The set of objectclass could be hardcode or provided in the >>>>>>> provisioning CLI option >>>>>>> What to do if an entry in in the provision file does not >>>>>>> match >>>>>>> any of those filter ? Should it stop without starting the >>>>>>> provisioning ? >>>>>>> * The CLI doing the provisioning could be something like 'ipa >>>>>>> provision ' or should it be a separated command e.g. >>>>>>> ipa-bulk-load ? >>>>>> >>>>>> It depends. There is a migration command now, ipa migrate-ds, that >>>>>> adds records and is impacted by this. There is also the >>>>>> possibility of >>>>>> looping calls to ipa [user|group|etc]-add. >>>>> >>>>> I agree that migration and bulk load can be linked. If migration >>>>> dump/update a set of entries before filling them into a new >>>>> instance it >>>>> could use bulk load. >>>>> For set loop of ipa -add, I think they add many others direct >>>>> operations (mainly SRCH) before doing the ADD in order to check >>>>> coherency. bulk load looks more straightforward. >>>> >>>> I just wonder if some (all) of this could be done manually. >>>> Document how to turn off memberof, do the import whatever way is >>>> appropriate, then run the fixup? I'm not sure what you had in mind. >>>> >>>> I don't want to think small but do we expect to be importing a slew >>>> of hosts, sudorules, etc? I guess the potential is there but would >>>> it be on the same scale as users? If you focus only on users/groups >>>> does that change the use case at all? >>>> >>> In fact, I am using such small scripts to prepare and run/monitor >>> the provisioning. >>> If providing a set of scripts and document a procedure is enough I >>> am fine with this. >>> >>>>>> Would it be reasonable to require bulk import to be done on an IPA >>>>>> master so we can leverage the ldapi socket? >>>>> Do you mean using ldapi to reduce network latency or automember or >>>>> something else ? >>>> >>>> To avoid the DM password issues. ldapi autobinds to DM when the id >>>> is root. >>> >>> Yes I said automember but was thinking to autobind. >>> That is nice idea to avoid prompting DM password. >>> In addition, slapi-nis participating to slowing down the >>> provisioning if it is using ldapi/DM slapi-nis will be offline by >>> itself. >>> >>> The limitation would be to run the provisioning on IPA master. >>> During provisioning, membership attribute will be invalid (memberof >>> not computed). Is it acceptable that IPA master contains invalid >>> membership for some time ? >> Consider provisioning to be at the same level as running >> ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is >> the only interface enabled which implies there would be no problem if we >> set expectations right: provisioning mode is offline. > > Yes I agree, provisioning mode is offline. > My concern is about side effects on the rest of the topology if we are > putting IPA master offline (is password update possible on replica ?). > > > thierry > How long it takes until memberof data are recreated using replication? (IIRC and memberof attributes are not replicated) From slaznick at redhat.com Thu May 26 09:30:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 26 May 2016 11:30:05 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Add missing CA options to the manpage for ipa-replica-install In-Reply-To: References: Message-ID: Hello, Thank you for your first patch! It seems fine to me so ACK. Standa On 05/20/2016 12:52 PM, Florence Blanc-Renaud wrote: > > Hi all, > > this one will be my first patch submission, so apologies in advance if > I make mistakes... > > The man page for ipa-replica-install was missing some commands related > to CA-less installation, as well as --allow-zone-overlap and > --auto-reverse. I added them in the relevant sections (CERTIFICATE > SYSTEM OPTIONS and DNS OPTIONS). > > I also fixed a wrong short option for --realm (-r). > > Fixes: https://fedorahosted.org/freeipa/ticket/5835 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 26 09:33:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 11:33:01 +0200 Subject: [Freeipa-devel] [PATCH 0484] remove unused code from automount plugin In-Reply-To: <98555b78-a869-ce89-e319-a575e6050a28@redhat.com> References: <1637e4e0-7e07-cb6e-0018-684fa3c48254@redhat.com> <08f2c6aa-6b64-81d6-c236-e0699a060326@redhat.com> <0630f6c9-9d94-015b-f689-51ce0f3005d3@redhat.com> <98555b78-a869-ce89-e319-a575e6050a28@redhat.com> Message-ID: On 26.05.2016 08:13, Stanislav Laznicka wrote: > On 05/25/2016 06:21 PM, Martin Basti wrote: >> >> On 25.05.2016 09:11, Stanislav Laznicka wrote: >>> >>> LGTM, could you please just add the ticket to the commit message? >>> >>> >>> On 05/20/2016 04:28 PM, Martin Basti wrote: >>>> >>>> >>>> >>>> On 20.05.2016 15:03, Martin Basti wrote: >>>>> The removed code is unused for long time. >>>>> >>>>> Patch attached. >>>>> >>>>> >>>>> >>>> https://fedorahosted.org/freeipa/attachment/ticket/5899/ >>>> >>>> >>> >> updated patch attached. > ACK Pushed to master: 25eed1c6cb1808dfa05ce7be23aa7dea4ae0f466 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu May 26 09:33:37 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 26 May 2016 11:33:37 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: References: <573488E7.7030103@redhat.com> <5734904A.1090905@redhat.com> <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> <5746C0B1.7020004@redhat.com> Message-ID: <5746C2F1.7030901@redhat.com> On 05/26/2016 11:26 AM, Martin Basti wrote: > > > On 26.05.2016 11:24, thierry bordaz wrote: >> >> >> On 05/26/2016 11:12 AM, Alexander Bokovoy wrote: >>> On Thu, 26 May 2016, thierry bordaz wrote: >>>> >>>> >>>> On 05/25/2016 09:31 PM, Rob Crittenden wrote: >>>>> thierry bordaz wrote: >>>>>> >>>>>> >>>>>> On 05/25/2016 08:49 PM, Rob Crittenden wrote: >>>>>>> thierry bordaz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Thanks for all the feedbacks. I updated the design accordingly >>>>>>>> and with >>>>>>>> additional tests results >>>>>>>> (http://www.freeipa.org/page/V4/Performance_Improvements#Proposed_improvements) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Several improvements can be done, in particular in DS plugins >>>>>>>> (memberof, >>>>>>>> retroCL), but for "easy" benefit provisioning will be done with >>>>>>>> memberof >>>>>>>> disabled followed by fixup. >>>>>>>> >>>>>>>> It remains some aspects that are not clear to me: >>>>>>>> >>>>>>>> * For best performance, DS tuning and provisioning/fixup would >>>>>>>> preferably be done under 'directory manager' >>>>>>>> That means prompting DM password and writing it into >>>>>>>> temporary file. >>>>>>>> Is that a concern ? >>>>>>>> * Fixup requires that we know the filters matching the >>>>>>>> provisioned >>>>>>>> entries. For example : >>>>>>>> o (objectClass=inetorgperson) >>>>>>>> o (objectClass=ipausergroup) >>>>>>>> o (objectClass=ipahost) >>>>>>>> o (objectClass=ipahostgroup) >>>>>>>> o (objectClass=ipasudorule) >>>>>>>> o (objectClass=ipahbacrule) >>>>>>>> >>>>>>>> The set of objectclass could be hardcode or provided in the >>>>>>>> provisioning CLI option >>>>>>>> What to do if an entry in in the provision file does not >>>>>>>> match >>>>>>>> any of those filter ? Should it stop without starting the >>>>>>>> provisioning ? >>>>>>>> * The CLI doing the provisioning could be something like 'ipa >>>>>>>> provision ' or should it be a separated command e.g. >>>>>>>> ipa-bulk-load ? >>>>>>> >>>>>>> It depends. There is a migration command now, ipa migrate-ds, that >>>>>>> adds records and is impacted by this. There is also the >>>>>>> possibility of >>>>>>> looping calls to ipa [user|group|etc]-add. >>>>>> >>>>>> I agree that migration and bulk load can be linked. If migration >>>>>> dump/update a set of entries before filling them into a new >>>>>> instance it >>>>>> could use bulk load. >>>>>> For set loop of ipa -add, I think they add many others >>>>>> direct >>>>>> operations (mainly SRCH) before doing the ADD in order to check >>>>>> coherency. bulk load looks more straightforward. >>>>> >>>>> I just wonder if some (all) of this could be done manually. >>>>> Document how to turn off memberof, do the import whatever way is >>>>> appropriate, then run the fixup? I'm not sure what you had in mind. >>>>> >>>>> I don't want to think small but do we expect to be importing a >>>>> slew of hosts, sudorules, etc? I guess the potential is there but >>>>> would it be on the same scale as users? If you focus only on >>>>> users/groups does that change the use case at all? >>>>> >>>> In fact, I am using such small scripts to prepare and run/monitor >>>> the provisioning. >>>> If providing a set of scripts and document a procedure is enough I >>>> am fine with this. >>>> >>>>>>> Would it be reasonable to require bulk import to be done on an IPA >>>>>>> master so we can leverage the ldapi socket? >>>>>> Do you mean using ldapi to reduce network latency or automember or >>>>>> something else ? >>>>> >>>>> To avoid the DM password issues. ldapi autobinds to DM when the id >>>>> is root. >>>> >>>> Yes I said automember but was thinking to autobind. >>>> That is nice idea to avoid prompting DM password. >>>> In addition, slapi-nis participating to slowing down the >>>> provisioning if it is using ldapi/DM slapi-nis will be offline by >>>> itself. >>>> >>>> The limitation would be to run the provisioning on IPA master. >>>> During provisioning, membership attribute will be invalid (memberof >>>> not computed). Is it acceptable that IPA master contains invalid >>>> membership for some time ? >>> Consider provisioning to be at the same level as running >>> ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is >>> the only interface enabled which implies there would be no problem >>> if we >>> set expectations right: provisioning mode is offline. >> >> Yes I agree, provisioning mode is offline. >> My concern is about side effects on the rest of the topology if we >> are putting IPA master offline (is password update possible on >> replica ?). >> >> >> thierry >> > > How long it takes until memberof data are recreated using replication? > (IIRC and memberof attributes are not replicated) I have not precise data on what will be the replication latency. IMHO provisioning will be "fast" on the server where we run the provisioning. Then the entries will be replicated to replicas where memberof is enabled. replication latency of users/usergroups/host/hostgroup should also be quite low, let say few minutes behind. Now the replication latency for entries like sudorules/hbacrules would be important, probably several hours. thierry From abokovoy at redhat.com Thu May 26 10:23:43 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 May 2016 13:23:43 +0300 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5746C0B1.7020004@redhat.com> References: <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> <5746C0B1.7020004@redhat.com> Message-ID: <20160526102122.4gqnk5edxljgzna3@redhat.com> On Thu, 26 May 2016, thierry bordaz wrote: >>>The limitation would be to run the provisioning on IPA master. >>>During provisioning, membership attribute will be invalid >>>(memberof not computed). Is it acceptable that IPA master contains >>>invalid membership for some time ? >>Consider provisioning to be at the same level as running >>ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is >>the only interface enabled which implies there would be no problem if we >>set expectations right: provisioning mode is offline. > >Yes I agree, provisioning mode is offline. >My concern is about side effects on the rest of the topology if we are >putting IPA master offline (is password update possible on replica ?). Sure, update on replica would be queued in replication queue. Password changes are local anyway, they result in updates of few password attributes and that's all. These attributes replicated in the same way as anything else. -- / Alexander Bokovoy From tbordaz at redhat.com Thu May 26 11:56:57 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 26 May 2016 13:56:57 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <20160526102122.4gqnk5edxljgzna3@redhat.com> References: <57358DC7.9030905@redhat.com> <5745F08B.6040401@redhat.com> <5745F3A5.5030501@redhat.com> <5745FC20.2050508@redhat.com> <5745FD89.3070601@redhat.com> <5746B539.5060300@redhat.com> <20160526091253.mpcky4rlqvn7pa5c@redhat.com> <5746C0B1.7020004@redhat.com> <20160526102122.4gqnk5edxljgzna3@redhat.com> Message-ID: <5746E489.3020608@redhat.com> On 05/26/2016 12:23 PM, Alexander Bokovoy wrote: > On Thu, 26 May 2016, thierry bordaz wrote: >>>> The limitation would be to run the provisioning on IPA master. >>>> During provisioning, membership attribute will be invalid (memberof >>>> not computed). Is it acceptable that IPA master contains invalid >>>> membership for some time ? >>> Consider provisioning to be at the same level as running >>> ipa-server-upgrade -- access via 389/636 ports is not allowed, LDAPI is >>> the only interface enabled which implies there would be no problem >>> if we >>> set expectations right: provisioning mode is offline. >> >> Yes I agree, provisioning mode is offline. >> My concern is about side effects on the rest of the topology if we >> are putting IPA master offline (is password update possible on >> replica ?). > Sure, update on replica would be queued in replication queue. Password > changes are local anyway, they result in updates of few password > attributes and that's all. These attributes replicated in the same way > as anything else. Yes that is right. I remember a discussion about the master key that was only available on IPA master and I thought that IPA master had a specific role around krb attributes. But if provisioning can be done on IPA master, it is then a good idea to use root/ldapi to avoid getting DM password. thanks for all your feedback and help thierry From mbasti at redhat.com Thu May 26 13:51:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 15:51:47 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> Message-ID: <5c839907-fbea-118f-eaf4-eb106eccf4f4@redhat.com> On 16.05.2016 08:37, Martin Kosek wrote: > On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: >> ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek : >> >>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>>> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal : >>>> >>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>>>> >>>>>> Hello, >>>>>> >>>>>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat >>>>>> employee, which of course does not mean he cannot contribute to the FreeIPA >>>>>> project, but that he won't have as much time for contributions as >>>>>> previously. >>>>>> >>>>>> One of Tomas' responsibilities was taking care of FreeIPA translations >>>>>> (Translation Maintainer role). As far as I know, there 2 main tasks >>>>>> associated >>>>>> with the Translation Maintainer role: >>>>>> >>>>>> 1) Periodically uploading new upstream strings to the FreeIPA translation >>>>>> platform of choice, which is the Fedora Zanata instance: >>>>>> https://fedora.zanata.org/project/view/freeipa >>>>>> The upload should happen periodically, on the right occasions, so that the >>>>>> translators (especially the French and Ukrainian translations which have >>>>>> 100% >>>>>> translated) have sufficient time to translate strings for the next version >>>>>> and >>>>>> do not have to translate it all in couple days before release. (This was >>>>>> one of >>>>>> the feedback I heard recently). >>>>>> >>>>>> 2) Downloading translated strings, Tomas added a short HowTo to our >>>>>> Release page: >>>>>> http://www.freeipa.org/page/Release#Translations >>>>>> >>>>>> We will need a new volunteer who would help doing 1) and 2) for the planned >>>>>> releases and making sure this process runs. The first task would be >>>>>> uploading >>>>>> current strings in master as the next release is FreeIPA 4.4 planned for >>>>>> June, >>>>>> so it may be nice to already upload new strings we have in FreeIPA already >>>>>> to >>>>>> Zanata, so that they can be translated in sufficient time. >>>>>> >>>>>> Volunteer(s)? >>>>>> >>>>>> As part of the learning process, I think it would be useful to do more >>>>>> documentation of the steps taken in every translation life-cycle, current >>>>>> HowTo >>>>>> in Release page is rather vague. I for example did not find information >>>>>> how to >>>>>> work with translation versions that I saw defined in Zanata (branching may >>>>>> work >>>>>> similarly as in current FreeIPA git). >>>>> >>>>> ?Thanks to the two volunteers?! >>>>> >>>>> Looking forward to see this happen! >>>>> >>>>> To reiterate on Martin K. message on uploads, I'd really like to see >>>>> regular strings uploads to the master branch in Zanata, say once a week or >>>>> every two weeks, so that translators can work on smaller strings batches. >>>>> "Release early, release oftem" :) >>>>> >>>>> And strings that would be translated twice in a short time span wouldn't be >>>>> entirely lost because they may stay in the Zanata translation memory and >>>>> could help translators finalizing dot releases if the specific branches in >>>>> Zanata. >>>>> >>>>> ?And if ?we can see the upload to master soon, translators can start >>>>> working now before the branch for the 4.4 June release. >>>>> >>>>> ?Regards, >>>>> >>>>> J. >>>> Hi, >>>> >>>> Similar thoughts here. >>> Thanks for feedback! >>> >>>> Just a note on branches, I think that it is worth to keep the translation just >>>> for the current release because keeping several branches on Zanata (or any >>>> other translation platform) is proved to be not effective from both sides, >>>> developers and translators. >>> I see. My expectation would be that these branches would be only used if there >>> is a bug in the translation, not for active translation. The thing is, strings >>> in master may change or may be deleted, so they may no longer be applied to the >>> branched FreeIPA x.y.z releases. So practically, we would not be able to update >>> the translations for branched release once we branch. >>> >>> Do you see that expected and acceptable? >> Just two examples from the projects that I am involved (three polar examples). >> >> KDE (Desktop environment): >> 1. Developed translation infrastructure (dedicated server, >> specifically-tailored software (Lokalize)). >> >> 2. Four translation branches (stable and trunk for Qt4 and Qt5-based >> applications). >> >> 3. Automatic message extraction every 24 hours. >> >> 4. Inbuild translation integration for releases. >> >> All this needs attention and strict release rules to keep everything in sync. >> >> Inkscape (SVG editor): >> 1. No specific infrastructure. >> >> 2. Translation branches are not strict (translators should guess what and where >> they are translating). >> >> 3. Manual extraction from time to time. >> >> 4. No specific integration or QA. >> >> Medium attention paid from the Inkscape developers. >> >> GnuPG (encryption framework): >> 1. No specific infrastructure. >> >> 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be performed by >> translators manually). >> >> 3. Manual extraction. No strict release schedule. You are lucky if you send >> your translation in time. >> >> 4. Manual integration by Werner when he finds it necessary. ;) >> >> Minimum attention paid from the developer. >> >> I think that FreeIPA in the sense of translation handling should be something >> in between. For not wasting efforts of the developers (it is sensible, because >> of too few more or less complete translations), I propose to have just one >> branch (no switching, no problem of choice), but use it strictly when releasing. > Thanks for the overview! Based on what I see so far, it looks like there is not > an interest for the branched translations. So I am fine with not doing the > versions if we do not see a need for it. > > As for automated message upload, I guess it could be done, we would just need > to think if it fits in current Jenkins infrastructure. But I suspect it could > also be on any cron-powered PaaS, like OpenShift. > >> It is better to have a translation with several untranslated new messages in a >> branch, than have no update at all because of the release flaws (like it is in >> libvirt now). So it would be a good trade off for me if FreeIPA developers >> promise to integrate translations into each release, but do not promise to >> waste their time for having translation branches. ;) > Translations should indeed be integrated in the release process. I would let > the 2 volunteers to update the Release page with the proper process and > instructions :-) > >>> It is a matter of just two commands (one for extraction and "zanata >>>> push" for >>>> pushing the catalog to Zanata). So, personally, I'd like to see the updates as >>>> soon as possible (something close to continuous integration). This allows us, >>>> translators, to react on any glitches in the initial strings and make the >>>> releases perfect. >>> I think this can be done, there is just the risk that some strings would be >>> added during master development and changed later when the code is revisited, >>> but I assume this is expected by you - correct? >> Yes, that's the common translators risk. But we have an automated translation >> memory for this. ;) > Ok. > >>>> It would be good if each release preparation process is close to the >>>> libguestfs's one: >>>> >>>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >>>> >>>> Just my 2 cents. >>> Thanks for the tip! >>> >>> Martin >> Best regards, >> Yuri > Thanks! > Martin > Hello all, I pushed sources to zanata (it seems that nothing changed, because we didn't touch user side of freeIPA too much yet) I pushed sources to all branches but as we agreed, only master should be activelly translated, should I lock translations for IPA 4.2 and possibly for 4.3? Could it work if we push sources to zanata: * monthly for everything * weekly, month before major release * daily, week before major release ? Martin^2 From yurchor at ukr.net Thu May 26 14:15:10 2016 From: yurchor at ukr.net (Yuri Chornoivan) Date: Thu, 26 May 2016 17:15:10 +0300 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <5c839907-fbea-118f-eaf4-eb106eccf4f4@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> <5c839907-fbea-118f-eaf4-eb106eccf4f4@redhat.com> Message-ID: ???????? Thu, 26 May 2016 16:51:47 +0300, Martin Basti : > > > On 16.05.2016 08:37, Martin Kosek wrote: >> On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: >>> ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek >>> : >>> >>>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>>>> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal >>>>> : >>>>> >>>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> As you may or may not know, Tomas Babej left the FreeIPA team as a >>>>>>> Red Hat >>>>>>> employee, which of course does not mean he cannot contribute to >>>>>>> the FreeIPA >>>>>>> project, but that he won't have as much time for contributions as >>>>>>> previously. >>>>>>> >>>>>>> One of Tomas' responsibilities was taking care of FreeIPA >>>>>>> translations >>>>>>> (Translation Maintainer role). As far as I know, there 2 main tasks >>>>>>> associated >>>>>>> with the Translation Maintainer role: >>>>>>> >>>>>>> 1) Periodically uploading new upstream strings to the FreeIPA >>>>>>> translation >>>>>>> platform of choice, which is the Fedora Zanata instance: >>>>>>> https://fedora.zanata.org/project/view/freeipa >>>>>>> The upload should happen periodically, on the right occasions, so >>>>>>> that the >>>>>>> translators (especially the French and Ukrainian translations >>>>>>> which have >>>>>>> 100% >>>>>>> translated) have sufficient time to translate strings for the next >>>>>>> version >>>>>>> and >>>>>>> do not have to translate it all in couple days before release. >>>>>>> (This was >>>>>>> one of >>>>>>> the feedback I heard recently). >>>>>>> >>>>>>> 2) Downloading translated strings, Tomas added a short HowTo to our >>>>>>> Release page: >>>>>>> http://www.freeipa.org/page/Release#Translations >>>>>>> >>>>>>> We will need a new volunteer who would help doing 1) and 2) for >>>>>>> the planned >>>>>>> releases and making sure this process runs. The first task would be >>>>>>> uploading >>>>>>> current strings in master as the next release is FreeIPA 4.4 >>>>>>> planned for >>>>>>> June, >>>>>>> so it may be nice to already upload new strings we have in FreeIPA >>>>>>> already >>>>>>> to >>>>>>> Zanata, so that they can be translated in sufficient time. >>>>>>> >>>>>>> Volunteer(s)? >>>>>>> >>>>>>> As part of the learning process, I think it would be useful to do >>>>>>> more >>>>>>> documentation of the steps taken in every translation life-cycle, >>>>>>> current >>>>>>> HowTo >>>>>>> in Release page is rather vague. I for example did not find >>>>>>> information >>>>>>> how to >>>>>>> work with translation versions that I saw defined in Zanata >>>>>>> (branching may >>>>>>> work >>>>>>> similarly as in current FreeIPA git). >>>>>> >>>>>> ?Thanks to the two volunteers?! >>>>>> >>>>>> Looking forward to see this happen! >>>>>> >>>>>> To reiterate on Martin K. message on uploads, I'd really like to see >>>>>> regular strings uploads to the master branch in Zanata, say once a >>>>>> week or >>>>>> every two weeks, so that translators can work on smaller strings >>>>>> batches. >>>>>> "Release early, release oftem" :) >>>>>> >>>>>> And strings that would be translated twice in a short time span >>>>>> wouldn't be >>>>>> entirely lost because they may stay in the Zanata translation >>>>>> memory and >>>>>> could help translators finalizing dot releases if the specific >>>>>> branches in >>>>>> Zanata. >>>>>> >>>>>> ?And if ?we can see the upload to master soon, translators can start >>>>>> working now before the branch for the 4.4 June release. >>>>>> >>>>>> ?Regards, >>>>>> >>>>>> J. >>>>> Hi, >>>>> >>>>> Similar thoughts here. >>>> Thanks for feedback! >>>> >>>>> Just a note on branches, I think that it is worth to keep the >>>>> translation just >>>>> for the current release because keeping several branches on Zanata >>>>> (or any >>>>> other translation platform) is proved to be not effective from both >>>>> sides, >>>>> developers and translators. >>>> I see. My expectation would be that these branches would be only used >>>> if there >>>> is a bug in the translation, not for active translation. The thing >>>> is, strings >>>> in master may change or may be deleted, so they may no longer be >>>> applied to the >>>> branched FreeIPA x.y.z releases. So practically, we would not be able >>>> to update >>>> the translations for branched release once we branch. >>>> >>>> Do you see that expected and acceptable? >>> Just two examples from the projects that I am involved (three polar >>> examples). >>> >>> KDE (Desktop environment): >>> 1. Developed translation infrastructure (dedicated server, >>> specifically-tailored software (Lokalize)). >>> >>> 2. Four translation branches (stable and trunk for Qt4 and Qt5-based >>> applications). >>> >>> 3. Automatic message extraction every 24 hours. >>> >>> 4. Inbuild translation integration for releases. >>> >>> All this needs attention and strict release rules to keep everything >>> in sync. >>> >>> Inkscape (SVG editor): >>> 1. No specific infrastructure. >>> >>> 2. Translation branches are not strict (translators should guess what >>> and where >>> they are translating). >>> >>> 3. Manual extraction from time to time. >>> >>> 4. No specific integration or QA. >>> >>> Medium attention paid from the Inkscape developers. >>> >>> GnuPG (encryption framework): >>> 1. No specific infrastructure. >>> >>> 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be >>> performed by >>> translators manually). >>> >>> 3. Manual extraction. No strict release schedule. You are lucky if you >>> send >>> your translation in time. >>> >>> 4. Manual integration by Werner when he finds it necessary. ;) >>> >>> Minimum attention paid from the developer. >>> >>> I think that FreeIPA in the sense of translation handling should be >>> something >>> in between. For not wasting efforts of the developers (it is sensible, >>> because >>> of too few more or less complete translations), I propose to have just >>> one >>> branch (no switching, no problem of choice), but use it strictly when >>> releasing. >> Thanks for the overview! Based on what I see so far, it looks like >> there is not >> an interest for the branched translations. So I am fine with not doing >> the >> versions if we do not see a need for it. >> >> As for automated message upload, I guess it could be done, we would >> just need >> to think if it fits in current Jenkins infrastructure. But I suspect it >> could >> also be on any cron-powered PaaS, like OpenShift. >> >>> It is better to have a translation with several untranslated new >>> messages in a >>> branch, than have no update at all because of the release flaws (like >>> it is in >>> libvirt now). So it would be a good trade off for me if FreeIPA >>> developers >>> promise to integrate translations into each release, but do not >>> promise to >>> waste their time for having translation branches. ;) >> Translations should indeed be integrated in the release process. I >> would let >> the 2 volunteers to update the Release page with the proper process and >> instructions :-) >> >>>> It is a matter of just two commands (one for extraction and "zanata >>>>> push" for >>>>> pushing the catalog to Zanata). So, personally, I'd like to see the >>>>> updates as >>>>> soon as possible (something close to continuous integration). This >>>>> allows us, >>>>> translators, to react on any glitches in the initial strings and >>>>> make the >>>>> releases perfect. >>>> I think this can be done, there is just the risk that some strings >>>> would be >>>> added during master development and changed later when the code is >>>> revisited, >>>> but I assume this is expected by you - correct? >>> Yes, that's the common translators risk. But we have an automated >>> translation >>> memory for this. ;) >> Ok. >> >>>>> It would be good if each release preparation process is close to the >>>>> libguestfs's one: >>>>> >>>>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >>>>> >>>>> Just my 2 cents. >>>> Thanks for the tip! >>>> >>>> Martin >>> Best regards, >>> Yuri >> Thanks! >> Martin >> > > Hello all, > > I pushed sources to zanata (it seems that nothing changed, because we > didn't touch user side of freeIPA too much yet) Many thanks for your work. > I pushed sources to all branches but as we agreed, only master should be > activelly translated, should I lock translations for IPA 4.2 and > possibly for 4.3? > > Could it work if we push sources to zanata: > * monthly for everything My vote is for this case. > * weekly, month before major release > * daily, week before major release > ? > > > Martin^2 Best regards, Yuri From mbasti at redhat.com Thu May 26 14:21:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 16:21:16 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> <5c839907-fbea-118f-eaf4-eb106eccf4f4@redhat.com> Message-ID: <26effc56-f924-49d0-2c99-11acb960ce2b@redhat.com> On 26.05.2016 16:15, Yuri Chornoivan wrote: > ???????? Thu, 26 May 2016 16:51:47 +0300, Martin Basti > : > >> >> >> On 16.05.2016 08:37, Martin Kosek wrote: >>> On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: >>>> ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek >>>> : >>>> >>>>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>>>>> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal >>>>>> : >>>>>> >>>>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> As you may or may not know, Tomas Babej left the FreeIPA team >>>>>>>> as a Red Hat >>>>>>>> employee, which of course does not mean he cannot contribute to >>>>>>>> the FreeIPA >>>>>>>> project, but that he won't have as much time for contributions as >>>>>>>> previously. >>>>>>>> >>>>>>>> One of Tomas' responsibilities was taking care of FreeIPA >>>>>>>> translations >>>>>>>> (Translation Maintainer role). As far as I know, there 2 main >>>>>>>> tasks >>>>>>>> associated >>>>>>>> with the Translation Maintainer role: >>>>>>>> >>>>>>>> 1) Periodically uploading new upstream strings to the FreeIPA >>>>>>>> translation >>>>>>>> platform of choice, which is the Fedora Zanata instance: >>>>>>>> https://fedora.zanata.org/project/view/freeipa >>>>>>>> The upload should happen periodically, on the right occasions, >>>>>>>> so that the >>>>>>>> translators (especially the French and Ukrainian translations >>>>>>>> which have >>>>>>>> 100% >>>>>>>> translated) have sufficient time to translate strings for the >>>>>>>> next version >>>>>>>> and >>>>>>>> do not have to translate it all in couple days before release. >>>>>>>> (This was >>>>>>>> one of >>>>>>>> the feedback I heard recently). >>>>>>>> >>>>>>>> 2) Downloading translated strings, Tomas added a short HowTo to >>>>>>>> our >>>>>>>> Release page: >>>>>>>> http://www.freeipa.org/page/Release#Translations >>>>>>>> >>>>>>>> We will need a new volunteer who would help doing 1) and 2) for >>>>>>>> the planned >>>>>>>> releases and making sure this process runs. The first task >>>>>>>> would be >>>>>>>> uploading >>>>>>>> current strings in master as the next release is FreeIPA 4.4 >>>>>>>> planned for >>>>>>>> June, >>>>>>>> so it may be nice to already upload new strings we have in >>>>>>>> FreeIPA already >>>>>>>> to >>>>>>>> Zanata, so that they can be translated in sufficient time. >>>>>>>> >>>>>>>> Volunteer(s)? >>>>>>>> >>>>>>>> As part of the learning process, I think it would be useful to >>>>>>>> do more >>>>>>>> documentation of the steps taken in every translation >>>>>>>> life-cycle, current >>>>>>>> HowTo >>>>>>>> in Release page is rather vague. I for example did not find >>>>>>>> information >>>>>>>> how to >>>>>>>> work with translation versions that I saw defined in Zanata >>>>>>>> (branching may >>>>>>>> work >>>>>>>> similarly as in current FreeIPA git). >>>>>>> >>>>>>> ?Thanks to the two volunteers?! >>>>>>> >>>>>>> Looking forward to see this happen! >>>>>>> >>>>>>> To reiterate on Martin K. message on uploads, I'd really like to >>>>>>> see >>>>>>> regular strings uploads to the master branch in Zanata, say once >>>>>>> a week or >>>>>>> every two weeks, so that translators can work on smaller strings >>>>>>> batches. >>>>>>> "Release early, release oftem" :) >>>>>>> >>>>>>> And strings that would be translated twice in a short time span >>>>>>> wouldn't be >>>>>>> entirely lost because they may stay in the Zanata translation >>>>>>> memory and >>>>>>> could help translators finalizing dot releases if the specific >>>>>>> branches in >>>>>>> Zanata. >>>>>>> >>>>>>> ?And if ?we can see the upload to master soon, translators can >>>>>>> start >>>>>>> working now before the branch for the 4.4 June release. >>>>>>> >>>>>>> ?Regards, >>>>>>> >>>>>>> J. >>>>>> Hi, >>>>>> >>>>>> Similar thoughts here. >>>>> Thanks for feedback! >>>>> >>>>>> Just a note on branches, I think that it is worth to keep the >>>>>> translation just >>>>>> for the current release because keeping several branches on >>>>>> Zanata (or any >>>>>> other translation platform) is proved to be not effective from >>>>>> both sides, >>>>>> developers and translators. >>>>> I see. My expectation would be that these branches would be only >>>>> used if there >>>>> is a bug in the translation, not for active translation. The thing >>>>> is, strings >>>>> in master may change or may be deleted, so they may no longer be >>>>> applied to the >>>>> branched FreeIPA x.y.z releases. So practically, we would not be >>>>> able to update >>>>> the translations for branched release once we branch. >>>>> >>>>> Do you see that expected and acceptable? >>>> Just two examples from the projects that I am involved (three polar >>>> examples). >>>> >>>> KDE (Desktop environment): >>>> 1. Developed translation infrastructure (dedicated server, >>>> specifically-tailored software (Lokalize)). >>>> >>>> 2. Four translation branches (stable and trunk for Qt4 and Qt5-based >>>> applications). >>>> >>>> 3. Automatic message extraction every 24 hours. >>>> >>>> 4. Inbuild translation integration for releases. >>>> >>>> All this needs attention and strict release rules to keep >>>> everything in sync. >>>> >>>> Inkscape (SVG editor): >>>> 1. No specific infrastructure. >>>> >>>> 2. Translation branches are not strict (translators should guess >>>> what and where >>>> they are translating). >>>> >>>> 3. Manual extraction from time to time. >>>> >>>> 4. No specific integration or QA. >>>> >>>> Medium attention paid from the Inkscape developers. >>>> >>>> GnuPG (encryption framework): >>>> 1. No specific infrastructure. >>>> >>>> 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be >>>> performed by >>>> translators manually). >>>> >>>> 3. Manual extraction. No strict release schedule. You are lucky if >>>> you send >>>> your translation in time. >>>> >>>> 4. Manual integration by Werner when he finds it necessary. ;) >>>> >>>> Minimum attention paid from the developer. >>>> >>>> I think that FreeIPA in the sense of translation handling should be >>>> something >>>> in between. For not wasting efforts of the developers (it is >>>> sensible, because >>>> of too few more or less complete translations), I propose to have >>>> just one >>>> branch (no switching, no problem of choice), but use it strictly >>>> when releasing. >>> Thanks for the overview! Based on what I see so far, it looks like >>> there is not >>> an interest for the branched translations. So I am fine with not >>> doing the >>> versions if we do not see a need for it. >>> >>> As for automated message upload, I guess it could be done, we would >>> just need >>> to think if it fits in current Jenkins infrastructure. But I suspect >>> it could >>> also be on any cron-powered PaaS, like OpenShift. >>> >>>> It is better to have a translation with several untranslated new >>>> messages in a >>>> branch, than have no update at all because of the release flaws >>>> (like it is in >>>> libvirt now). So it would be a good trade off for me if FreeIPA >>>> developers >>>> promise to integrate translations into each release, but do not >>>> promise to >>>> waste their time for having translation branches. ;) >>> Translations should indeed be integrated in the release process. I >>> would let >>> the 2 volunteers to update the Release page with the proper process and >>> instructions :-) >>> >>>>> It is a matter of just two commands (one for extraction and "zanata >>>>>> push" for >>>>>> pushing the catalog to Zanata). So, personally, I'd like to see >>>>>> the updates as >>>>>> soon as possible (something close to continuous integration). >>>>>> This allows us, >>>>>> translators, to react on any glitches in the initial strings and >>>>>> make the >>>>>> releases perfect. >>>>> I think this can be done, there is just the risk that some strings >>>>> would be >>>>> added during master development and changed later when the code is >>>>> revisited, >>>>> but I assume this is expected by you - correct? >>>> Yes, that's the common translators risk. But we have an automated >>>> translation >>>> memory for this. ;) >>> Ok. >>> >>>>>> It would be good if each release preparation process is close to the >>>>>> libguestfs's one: >>>>>> >>>>>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >>>>>> >>>>>> Just my 2 cents. >>>>> Thanks for the tip! >>>>> >>>>> Martin >>>> Best regards, >>>> Yuri >>> Thanks! >>> Martin >>> >> >> Hello all, >> >> I pushed sources to zanata (it seems that nothing changed, because we >> didn't touch user side of freeIPA too much yet) > > Many thanks for your work. I'm not sure if it works, in history I see that just ipa-4-2 branch has been updated in zanata, and I tried to push master twice and there is no information about it in zanata web, I have to investigate more. > >> I pushed sources to all branches but as we agreed, only master should >> be activelly translated, should I lock translations for IPA 4.2 and >> possibly for 4.3? >> >> Could it work if we push sources to zanata: >> * monthly for everything > > My vote is for this case. I meant this as closer to release then more frequent pushes to zanata > >> * weekly, month before major release >> * daily, week before major release >> ? >> >> >> Martin^2 > > Best regards, > Yuri From mbasti at redhat.com Thu May 26 14:27:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 16:27:44 +0200 Subject: [Freeipa-devel] Reviving FreeIPA translations In-Reply-To: <26effc56-f924-49d0-2c99-11acb960ce2b@redhat.com> References: <24516707-5ad8-88df-180d-f996d957f36b@redhat.com> <136811ef-4b59-08f5-5cd8-2db2d8bf369f@redhat.com> <5c839907-fbea-118f-eaf4-eb106eccf4f4@redhat.com> <26effc56-f924-49d0-2c99-11acb960ce2b@redhat.com> Message-ID: <93ae4f00-616e-87d2-90a4-a040bb39447a@redhat.com> On 26.05.2016 16:21, Martin Basti wrote: > > > On 26.05.2016 16:15, Yuri Chornoivan wrote: >> ???????? Thu, 26 May 2016 16:51:47 +0300, Martin Basti >> : >> >>> >>> >>> On 16.05.2016 08:37, Martin Kosek wrote: >>>> On 05/15/2016 09:34 PM, Yuri Chornoivan wrote: >>>>> ???????? Sun, 15 May 2016 21:51:45 +0300, Martin Kosek >>>>> : >>>>> >>>>>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote: >>>>>>> ???????? Sat, 14 May 2016 12:57:13 +0300, J?r?me Fenal >>>>>>> : >>>>>>> >>>>>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek : >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> As you may or may not know, Tomas Babej left the FreeIPA team >>>>>>>>> as a Red Hat >>>>>>>>> employee, which of course does not mean he cannot contribute >>>>>>>>> to the FreeIPA >>>>>>>>> project, but that he won't have as much time for contributions as >>>>>>>>> previously. >>>>>>>>> >>>>>>>>> One of Tomas' responsibilities was taking care of FreeIPA >>>>>>>>> translations >>>>>>>>> (Translation Maintainer role). As far as I know, there 2 main >>>>>>>>> tasks >>>>>>>>> associated >>>>>>>>> with the Translation Maintainer role: >>>>>>>>> >>>>>>>>> 1) Periodically uploading new upstream strings to the FreeIPA >>>>>>>>> translation >>>>>>>>> platform of choice, which is the Fedora Zanata instance: >>>>>>>>> https://fedora.zanata.org/project/view/freeipa >>>>>>>>> The upload should happen periodically, on the right occasions, >>>>>>>>> so that the >>>>>>>>> translators (especially the French and Ukrainian translations >>>>>>>>> which have >>>>>>>>> 100% >>>>>>>>> translated) have sufficient time to translate strings for the >>>>>>>>> next version >>>>>>>>> and >>>>>>>>> do not have to translate it all in couple days before release. >>>>>>>>> (This was >>>>>>>>> one of >>>>>>>>> the feedback I heard recently). >>>>>>>>> >>>>>>>>> 2) Downloading translated strings, Tomas added a short HowTo >>>>>>>>> to our >>>>>>>>> Release page: >>>>>>>>> http://www.freeipa.org/page/Release#Translations >>>>>>>>> >>>>>>>>> We will need a new volunteer who would help doing 1) and 2) >>>>>>>>> for the planned >>>>>>>>> releases and making sure this process runs. The first task >>>>>>>>> would be >>>>>>>>> uploading >>>>>>>>> current strings in master as the next release is FreeIPA 4.4 >>>>>>>>> planned for >>>>>>>>> June, >>>>>>>>> so it may be nice to already upload new strings we have in >>>>>>>>> FreeIPA already >>>>>>>>> to >>>>>>>>> Zanata, so that they can be translated in sufficient time. >>>>>>>>> >>>>>>>>> Volunteer(s)? >>>>>>>>> >>>>>>>>> As part of the learning process, I think it would be useful to >>>>>>>>> do more >>>>>>>>> documentation of the steps taken in every translation >>>>>>>>> life-cycle, current >>>>>>>>> HowTo >>>>>>>>> in Release page is rather vague. I for example did not find >>>>>>>>> information >>>>>>>>> how to >>>>>>>>> work with translation versions that I saw defined in Zanata >>>>>>>>> (branching may >>>>>>>>> work >>>>>>>>> similarly as in current FreeIPA git). >>>>>>>> >>>>>>>> ?Thanks to the two volunteers?! >>>>>>>> >>>>>>>> Looking forward to see this happen! >>>>>>>> >>>>>>>> To reiterate on Martin K. message on uploads, I'd really like >>>>>>>> to see >>>>>>>> regular strings uploads to the master branch in Zanata, say >>>>>>>> once a week or >>>>>>>> every two weeks, so that translators can work on smaller >>>>>>>> strings batches. >>>>>>>> "Release early, release oftem" :) >>>>>>>> >>>>>>>> And strings that would be translated twice in a short time span >>>>>>>> wouldn't be >>>>>>>> entirely lost because they may stay in the Zanata translation >>>>>>>> memory and >>>>>>>> could help translators finalizing dot releases if the specific >>>>>>>> branches in >>>>>>>> Zanata. >>>>>>>> >>>>>>>> ?And if ?we can see the upload to master soon, translators can >>>>>>>> start >>>>>>>> working now before the branch for the 4.4 June release. >>>>>>>> >>>>>>>> ?Regards, >>>>>>>> >>>>>>>> J. >>>>>>> Hi, >>>>>>> >>>>>>> Similar thoughts here. >>>>>> Thanks for feedback! >>>>>> >>>>>>> Just a note on branches, I think that it is worth to keep the >>>>>>> translation just >>>>>>> for the current release because keeping several branches on >>>>>>> Zanata (or any >>>>>>> other translation platform) is proved to be not effective from >>>>>>> both sides, >>>>>>> developers and translators. >>>>>> I see. My expectation would be that these branches would be only >>>>>> used if there >>>>>> is a bug in the translation, not for active translation. The >>>>>> thing is, strings >>>>>> in master may change or may be deleted, so they may no longer be >>>>>> applied to the >>>>>> branched FreeIPA x.y.z releases. So practically, we would not be >>>>>> able to update >>>>>> the translations for branched release once we branch. >>>>>> >>>>>> Do you see that expected and acceptable? >>>>> Just two examples from the projects that I am involved (three >>>>> polar examples). >>>>> >>>>> KDE (Desktop environment): >>>>> 1. Developed translation infrastructure (dedicated server, >>>>> specifically-tailored software (Lokalize)). >>>>> >>>>> 2. Four translation branches (stable and trunk for Qt4 and Qt5-based >>>>> applications). >>>>> >>>>> 3. Automatic message extraction every 24 hours. >>>>> >>>>> 4. Inbuild translation integration for releases. >>>>> >>>>> All this needs attention and strict release rules to keep >>>>> everything in sync. >>>>> >>>>> Inkscape (SVG editor): >>>>> 1. No specific infrastructure. >>>>> >>>>> 2. Translation branches are not strict (translators should guess >>>>> what and where >>>>> they are translating). >>>>> >>>>> 3. Manual extraction from time to time. >>>>> >>>>> 4. No specific integration or QA. >>>>> >>>>> Medium attention paid from the Inkscape developers. >>>>> >>>>> GnuPG (encryption framework): >>>>> 1. No specific infrastructure. >>>>> >>>>> 2. Strict branches (1.4, 2.0 and 2.1) but no syncing (should be >>>>> performed by >>>>> translators manually). >>>>> >>>>> 3. Manual extraction. No strict release schedule. You are lucky if >>>>> you send >>>>> your translation in time. >>>>> >>>>> 4. Manual integration by Werner when he finds it necessary. ;) >>>>> >>>>> Minimum attention paid from the developer. >>>>> >>>>> I think that FreeIPA in the sense of translation handling should >>>>> be something >>>>> in between. For not wasting efforts of the developers (it is >>>>> sensible, because >>>>> of too few more or less complete translations), I propose to have >>>>> just one >>>>> branch (no switching, no problem of choice), but use it strictly >>>>> when releasing. >>>> Thanks for the overview! Based on what I see so far, it looks like >>>> there is not >>>> an interest for the branched translations. So I am fine with not >>>> doing the >>>> versions if we do not see a need for it. >>>> >>>> As for automated message upload, I guess it could be done, we would >>>> just need >>>> to think if it fits in current Jenkins infrastructure. But I >>>> suspect it could >>>> also be on any cron-powered PaaS, like OpenShift. >>>> >>>>> It is better to have a translation with several untranslated new >>>>> messages in a >>>>> branch, than have no update at all because of the release flaws >>>>> (like it is in >>>>> libvirt now). So it would be a good trade off for me if FreeIPA >>>>> developers >>>>> promise to integrate translations into each release, but do not >>>>> promise to >>>>> waste their time for having translation branches. ;) >>>> Translations should indeed be integrated in the release process. I >>>> would let >>>> the 2 volunteers to update the Release page with the proper process >>>> and >>>> instructions :-) >>>> >>>>>> It is a matter of just two commands (one for extraction and "zanata >>>>>>> push" for >>>>>>> pushing the catalog to Zanata). So, personally, I'd like to see >>>>>>> the updates as >>>>>>> soon as possible (something close to continuous integration). >>>>>>> This allows us, >>>>>>> translators, to react on any glitches in the initial strings and >>>>>>> make the >>>>>>> releases perfect. >>>>>> I think this can be done, there is just the risk that some >>>>>> strings would be >>>>>> added during master development and changed later when the code >>>>>> is revisited, >>>>>> but I assume this is expected by you - correct? >>>>> Yes, that's the common translators risk. But we have an automated >>>>> translation >>>>> memory for this. ;) >>>> Ok. >>>> >>>>>>> It would be good if each release preparation process is close to >>>>>>> the >>>>>>> libguestfs's one: >>>>>>> >>>>>>> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release >>>>>>> >>>>>>> >>>>>>> Just my 2 cents. >>>>>> Thanks for the tip! >>>>>> >>>>>> Martin >>>>> Best regards, >>>>> Yuri >>>> Thanks! >>>> Martin >>>> >>> >>> Hello all, >>> >>> I pushed sources to zanata (it seems that nothing changed, because >>> we didn't touch user side of freeIPA too much yet) >> >> Many thanks for your work. > > I'm not sure if it works, in history I see that just ipa-4-2 branch > has been updated in zanata, and I tried to push master twice and there > is no information about it in zanata web, I have to investigate more. I found in different view, that other branches has been updated too, so current sources in zanata should be OK Martin^2 > >> >>> I pushed sources to all branches but as we agreed, only master >>> should be activelly translated, should I lock translations for IPA >>> 4.2 and possibly for 4.3? >>> >>> Could it work if we push sources to zanata: >>> * monthly for everything >> >> My vote is for this case. > > I meant this as closer to release then more frequent pushes to zanata >> >>> * weekly, month before major release >>> * daily, week before major release >>> ? >>> >>> >>> Martin^2 >> >> Best regards, >> Yuri > From mbasti at redhat.com Thu May 26 14:52:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 16:52:08 +0200 Subject: [Freeipa-devel] [PATCH 0486, 0487] Update zanata config Message-ID: <6ff73b41-c1a2-e6f0-87bd-0ca073e3d069@redhat.com> https://fedorahosted.org/freeipa/ticket/5915 Patches attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.2-mbasti-0487-Set-proper-zanata-project-version.patch Type: text/x-patch Size: 818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.3-mbasti-0487-Set-proper-zanata-project-version.patch Type: text/x-patch Size: 818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0486-Translations-remove-deprecated-locale-configuration.patch Type: text/x-patch Size: 1302 bytes Desc: not available URL: From npmccallum at redhat.com Thu May 26 15:36:30 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 26 May 2016 11:36:30 -0400 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <20160525113211.GK29502@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> <1464106108.2783.25.camel@redhat.com> <1464106903.2783.27.camel@redhat.com> <20160525113211.GK29502@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1464276990.10194.38.camel@redhat.com> Martin, can we get patches 1-4 pushed? I'll submit patch 5 again to the list after a rebase for further discussion. On Wed, 2016-05-25 at 13:32 +0200, Sumit Bose wrote: > On Tue, May 24, 2016 at 12:21:43PM -0400, Nathaniel McCallum wrote: > > New versions again. This time I just removed the stray "TODO: > > assign > > OID" line in the commit as it no longer applies. > > ACK to patches 1-4. > > Patch 5 can be committed independently and needs some additional > discussion, see below. > > bye, > Sumit > > > > > On Tue, 2016-05-24 at 12:08 -0400, Nathaniel McCallum wrote: > > > I have attached new versions of the patches. Comments below. > > > > > > On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: > > > > On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum > > > > wrote: > > > > > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: > > > > > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel > > > > > > McCallum > > > > > > wrote: > > ... > > > > > > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 > > > > > 00:00:00 > > > > > 2001 > > > > > From: Nathaniel McCallum > > > > > Date: Wed, 4 May 2016 17:08:45 -0400 > > > > > Subject: [PATCH 5/5] Enable service authentication indicator > > > > > management > > > > > > > > > > > > > For me the patch looks good, but it would be nice if someone > > > > more > > > > used > > > > to our usage of python can have a short look to see if all > > > > conventioens > > > > are met. ACK for the functionality. > > > > > > I would like for us to merge the first four patches first and > > > then > > > concentrate on this one. > > > > > > In particular, the following issue needs to be discussed. We > > > currently > > > only have two, hard-coded indicator values: otp and radius. Thus, > > > we > > > use a StrEnum for this property. However, in the long-term, I'd > > > like > > > to > > > have more flexibility; such as per-token indicators. This implies > > > String. > > > > > > Is there some way to do StrEnum now and easily migrate to String > > > later? > > > I think this will break API. Thoughts? > > > From mbasti at redhat.com Thu May 26 16:43:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 18:43:23 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> Message-ID: <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> On 26.05.2016 11:21, Martin Basti wrote: > > > On 26.05.2016 07:15, Jan Cholasta wrote: >> On 25.5.2016 18:17, Martin Basti wrote: >>> >>> >>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>> On 25.5.2016 15:03, David Kupka wrote: >>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>> change >>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>> >>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>> LDAPQuery * >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>> class * >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>> client * >>>>>>>>> 1) >>>>>>>>> you forgot to increment VERSION >>>>>>>> >>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>> VERSION >>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>> merged. >>>>>>>> But we're not there yet, so fixed. >>>>>>>> >>>>>>> How we should handle VERSION after your patches? >>>>>>>>> >>>>>>>>> Otherwise LGTM >>>>>>>>> >>>>>>>>> * otptoken: fix import of DN * >>>>>>>>> ACK >>>>>>>>> >>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>> 1) >>>>>>>>> you forgot to increment VERSION >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> Did you find out why this was issue? >>>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>>> omitted? >>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>> error if >>>>>>>>> omitted? >>>>>>>> >>>>>>>> The command definition was not complete, it was missing >>>>>>>> has_output. >>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise LGTM >>>>>>>>> >>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>> counterparts * >>>>>>>>> 1) >>>>>>>>> you forgot to increment Version >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>>> needed >>>>>>>>> in commit message >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> The other commits I will check later. >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>> >>>>>>>> Okay. Thanks. >>>>>>>> >>>>>>> >>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>> LGTM >>>>>>> >>>>>>> * frontend: perform argument value validation only on server >>>>>>> LGTM >>>>>>> >>>>>>> * frontend: do not forward argument defaults to server >>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>> havent >>>>>>> found anything better to use. >>>>>> >>>>>> It always returned None for unset params. >>>>>> >>>>>>> LGTM >>>>>>> >>>>>>> * ipalib: optimize API.txt >>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>> copy of >>>>>>> current to proper places, LGTM >>>>>> >>>>>> It's actually mostly cut-n-paste. >>>>>> >>>>>>> >>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>> Looks good, but I miss explanation why is this change needed >>>>>> >>>>>> The next change would be impossible without this. >>>>>> >>>>>>> >>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>> LGTM >>>>>>> >>>>>>> >>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>> registration >>>>>>> ACK >>>>>>> >>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>>> LGTM >>>>>>> >>>>>>> >>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>> LGTM >>>>>>> >>>>>>> >>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>> LGTM >>>>>>> >>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>> LGTM >>>>>>> >>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>> LGTM >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> Hello, >>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>> to be >>>>> pushed into master. >>>>> All upto "frontend: allow commands to have an argument named >>>>> `name`" got >>>>> over numerous test&fix cycles in last week+ and is working as >>>>> expected >>>>> now, ACK. >>>> >>>> Thanks for the review. >>>> >>>>> >>>>> Honzo, please rebase and push them, thanks! >>>>> >>>> >>>> Attaching the patches for reference. >>>> >>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>> >>> >>> Guys, you forgot to test it with newer pylint. >> >> I don't see any "BuildRequires: newer pylint" in the spec file. >> >>> >>> Patch attached. >> >> LGTM, although the commit message is wrong - this is not related to >> thin client at all, PublicError and PublicMessage had .kw since forever. >> > updated commit message > > > > > Can I push that fix for pylint? I found something suspicious in tests, did anything in IPA messages change? I suspect that this is related to client_patches. E AssertionError: assert_deepequal: dict keys mismatch. E 0026: permission_find: Search for u'testperm' with a limit of 1 (truncated) with members E missing keys = [] E extra keys = [u'data'] E expected = {'message': u'Search result has been truncated: Configured size limit exceeded', 'code': 13017, 'type': u'warning', 'name': u'SearchResultTruncated'} E got = {u'data': {u'reason': u'Configured size limit exceeded'}, u'message': u'Search result has been truncated: Configured size limit exceeded', u'code': 13017, u'type': u'warning', u'name': u'SearchResultTruncated'} E path = ('messages', 0) E AssertionError: assert_deepequal: dict keys mismatch. E 0024: permission_find: Search for u'testperm' with a limit of 1 (truncated) with members E missing keys = [] E extra keys = [u'data'] E expected = {'message': u'Search result has been truncated: Configured size limit exceeded', 'code': 13017, 'type': u'warning', 'name': u'SearchResultTruncated'} E got = {u'data': {u'reason': u'Configured size limit exceeded'}, u'message': u'Search result has been truncated: Configured size limit exceeded', u'code': 13017, u'type': u'warning', u'name': u'SearchResultTruncated'} E path = ('messages', 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu May 26 16:49:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 May 2016 18:49:45 +0200 Subject: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators In-Reply-To: <1464276990.10194.38.camel@redhat.com> References: <1462397635.1537.70.camel@redhat.com> <20160506124444.GC9843@p.Speedport_W_724V_Typ_A_05011603_00_009> <1463088806.2785.23.camel@redhat.com> <20160524132529.GD29502@p.Speedport_W_724V_Typ_A_05011603_00_009> <1464106108.2783.25.camel@redhat.com> <1464106903.2783.27.camel@redhat.com> <20160525113211.GK29502@p.Speedport_W_724V_Typ_A_05011603_00_009> <1464276990.10194.38.camel@redhat.com> Message-ID: On 26.05.2016 17:36, Nathaniel McCallum wrote: > Martin, can we get patches 1-4 pushed? I'll submit patch 5 again to the > list after a rebase for further discussion. Here it is, pushed to master: * cd9bc84240c99ed744e5ee44db18d925a5292ffd Rename syncreq.[ch] to otpctrl.[ch] * 168a6c7d4778a2a3c729e3ac24e4ad9dfacb46c0 Ensure that ipa-otpd bind auths validate an OTP * 204200d73bb135cb7b9b31b8f1ba5268d73094a5 Return password-only preauth if passwords are allowed * 8f356a4305a9aa74aacae36806d6e8ed1b765245 Enable authentication indicators for OTP and RADIUS > > On Wed, 2016-05-25 at 13:32 +0200, Sumit Bose wrote: >> On Tue, May 24, 2016 at 12:21:43PM -0400, Nathaniel McCallum wrote: >>> New versions again. This time I just removed the stray "TODO: >>> assign >>> OID" line in the commit as it no longer applies. >> ACK to patches 1-4. >> >> Patch 5 can be committed independently and needs some additional >> discussion, see below. >> >> bye, >> Sumit >> >>> On Tue, 2016-05-24 at 12:08 -0400, Nathaniel McCallum wrote: >>>> I have attached new versions of the patches. Comments below. >>>> >>>> On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote: >>>>> On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum >>>>> wrote: >>>>>> On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote: >>>>>>> On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel >>>>>>> McCallum >>>>>>> wrote: >> ... >> >>>>>> From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 >>>>>> 00:00:00 >>>>>> 2001 >>>>>> From: Nathaniel McCallum >>>>>> Date: Wed, 4 May 2016 17:08:45 -0400 >>>>>> Subject: [PATCH 5/5] Enable service authentication indicator >>>>>> management >>>>>> >>>>> For me the patch looks good, but it would be nice if someone >>>>> more >>>>> used >>>>> to our usage of python can have a short look to see if all >>>>> conventioens >>>>> are met. ACK for the functionality. >>>> I would like for us to merge the first four patches first and >>>> then >>>> concentrate on this one. >>>> >>>> In particular, the following issue needs to be discussed. We >>>> currently >>>> only have two, hard-coded indicator values: otp and radius. Thus, >>>> we >>>> use a StrEnum for this property. However, in the long-term, I'd >>>> like >>>> to >>>> have more flexibility; such as per-token indicators. This implies >>>> String. >>>> >>>> Is there some way to do StrEnum now and easily migrate to String >>>> later? >>>> I think this will break API. Thoughts? >>>> From slaznick at redhat.com Thu May 26 17:21:38 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 26 May 2016 19:21:38 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't Message-ID: Hello, Please, see the attached patch. Fixes https://fedorahosted.org/freeipa/ticket/5898 Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0033-Fixes-CA-always-being-presented-as-running.patch Type: text/x-patch Size: 2304 bytes Desc: not available URL: From slaznick at redhat.com Thu May 26 17:31:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 26 May 2016 19:31:05 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: References: Message-ID: Self NACK. I should not post patches when tired, sorry. Minor fix is attached. On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: > Hello, > > Please, see the attached patch. Fixes > https://fedorahosted.org/freeipa/ticket/5898 > > Standa > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0033-2-Fixes-CA-always-being-presented-as-running.patch Type: text/x-patch Size: 2311 bytes Desc: not available URL: From jcholast at redhat.com Fri May 27 05:49:30 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 May 2016 07:49:30 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> Message-ID: On 26.5.2016 18:43, Martin Basti wrote: > > > On 26.05.2016 11:21, Martin Basti wrote: >> >> >> On 26.05.2016 07:15, Jan Cholasta wrote: >>> On 25.5.2016 18:17, Martin Basti wrote: >>>> >>>> >>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>> change >>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>> >>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>> LDAPQuery * >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>> class * >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>>> client * >>>>>>>>>> 1) >>>>>>>>>> you forgot to increment VERSION >>>>>>>>> >>>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>>> VERSION >>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>> merged. >>>>>>>>> But we're not there yet, so fixed. >>>>>>>>> >>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>> >>>>>>>>>> Otherwise LGTM >>>>>>>>>> >>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>> ACK >>>>>>>>>> >>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>> 1) >>>>>>>>>> you forgot to increment VERSION >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> Did you find out why this was issue? >>>>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>>>> omitted? >>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>> error if >>>>>>>>>> omitted? >>>>>>>>> >>>>>>>>> The command definition was not complete, it was missing >>>>>>>>> has_output. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Otherwise LGTM >>>>>>>>>> >>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>> counterparts * >>>>>>>>>> 1) >>>>>>>>>> you forgot to increment Version >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>>>> needed >>>>>>>>>> in commit message >>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The other commits I will check later. >>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>> >>>>>>>>> Okay. Thanks. >>>>>>>>> >>>>>>>> >>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>> LGTM >>>>>>>> >>>>>>>> * frontend: perform argument value validation only on server >>>>>>>> LGTM >>>>>>>> >>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>>> havent >>>>>>>> found anything better to use. >>>>>>> >>>>>>> It always returned None for unset params. >>>>>>> >>>>>>>> LGTM >>>>>>>> >>>>>>>> * ipalib: optimize API.txt >>>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>>> copy of >>>>>>>> current to proper places, LGTM >>>>>>> >>>>>>> It's actually mostly cut-n-paste. >>>>>>> >>>>>>>> >>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>> >>>>>>> The next change would be impossible without this. >>>>>>> >>>>>>>> >>>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>>> LGTM >>>>>>>> >>>>>>>> >>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>> registration >>>>>>>> ACK >>>>>>>> >>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>>>> LGTM >>>>>>>> >>>>>>>> >>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>> LGTM >>>>>>>> >>>>>>>> >>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>> LGTM >>>>>>>> >>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>> LGTM >>>>>>>> >>>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>>> LGTM >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Hello, >>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>>> to be >>>>>> pushed into master. >>>>>> All upto "frontend: allow commands to have an argument named >>>>>> `name`" got >>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>> expected >>>>>> now, ACK. >>>>> >>>>> Thanks for the review. >>>>> >>>>>> >>>>>> Honzo, please rebase and push them, thanks! >>>>>> >>>>> >>>>> Attaching the patches for reference. >>>>> >>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>> >>>> >>>> Guys, you forgot to test it with newer pylint. >>> >>> I don't see any "BuildRequires: newer pylint" in the spec file. >>> >>>> >>>> Patch attached. >>> >>> LGTM, although the commit message is wrong - this is not related to >>> thin client at all, PublicError and PublicMessage had .kw since forever. >>> >> updated commit message >> >> >> >> >> > Can I push that fix for pylint? Sure, ACK. > > I found something suspicious in tests, did anything in IPA messages > change? I suspect that this is related to client_patches. Yes, 'data' is a dict which contains structured message data. I did not see these specific failures before, though. Just add it to expected results where missing. > > E AssertionError: assert_deepequal: dict keys mismatch. > E 0026: permission_find: Search for u'testperm' with a > limit of 1 (truncated) with members > E missing keys = [] > E extra keys = [u'data'] > E expected = {'message': u'Search result has been > truncated: Configured size limit exceeded', 'code': 13017, 'type': > u'warning', 'name': u'SearchResultTruncated'} > E got = {u'data': {u'reason': u'Configured size limit > exceeded'}, u'message': u'Search result has been truncated: Configured > size limit exceeded', u'code': 13017, u'type': u'warning', u'name': > u'SearchResultTruncated'} > E path = ('messages', 0) > > > > E AssertionError: assert_deepequal: dict keys mismatch. > E 0024: permission_find: Search for u'testperm' with a > limit of 1 (truncated) with members > E missing keys = [] > E extra keys = [u'data'] > E expected = {'message': u'Search result has been > truncated: Configured size limit exceeded', 'code': 13017, 'type': > u'warning', 'name': u'SearchResultTruncated'} > E got = {u'data': {u'reason': u'Configured size limit > exceeded'}, u'message': u'Search result has been truncated: Configured > size limit exceeded', u'code': 13017, u'type': u'warning', u'name': > u'SearchResultTruncated'} > E path = ('messages', 0) -- Jan Cholasta From mbasti at redhat.com Fri May 27 07:26:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 May 2016 09:26:21 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> Message-ID: <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> On 27.05.2016 07:49, Jan Cholasta wrote: > On 26.5.2016 18:43, Martin Basti wrote: >> >> >> On 26.05.2016 11:21, Martin Basti wrote: >>> >>> >>> On 26.05.2016 07:15, Jan Cholasta wrote: >>>> On 25.5.2016 18:17, Martin Basti wrote: >>>>> >>>>> >>>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> All commits up to "ipalib: use relative imports for >>>>>>>>>>>> cross-plugin >>>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>>> change >>>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>>> >>>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>>> LDAPQuery * >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>>> class * >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>>>> client * >>>>>>>>>>> 1) >>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>> >>>>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>>>> VERSION >>>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>>> merged. >>>>>>>>>> But we're not there yet, so fixed. >>>>>>>>>> >>>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>>> >>>>>>>>>>> Otherwise LGTM >>>>>>>>>>> >>>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>>> ACK >>>>>>>>>>> >>>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>>> 1) >>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> Did you find out why this was issue? >>>>>>>>>>> - del answer['value'] # Why does this cause an >>>>>>>>>>> error if >>>>>>>>>>> omitted? >>>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>>> error if >>>>>>>>>>> omitted? >>>>>>>>>> >>>>>>>>>> The command definition was not complete, it was missing >>>>>>>>>> has_output. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Otherwise LGTM >>>>>>>>>>> >>>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>>> counterparts * >>>>>>>>>>> 1) >>>>>>>>>>> you forgot to increment Version >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>>> 1) Missing explanation for future generations why this >>>>>>>>>>> change is >>>>>>>>>>> needed >>>>>>>>>>> in commit message >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The other commits I will check later. >>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Okay. Thanks. >>>>>>>>>> >>>>>>>>> >>>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * frontend: perform argument value validation only on server >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>>>> havent >>>>>>>>> found anything better to use. >>>>>>>> >>>>>>>> It always returned None for unset params. >>>>>>>> >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * ipalib: optimize API.txt >>>>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>>>> copy of >>>>>>>>> current to proper places, LGTM >>>>>>>> >>>>>>>> It's actually mostly cut-n-paste. >>>>>>>> >>>>>>>>> >>>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>>> >>>>>>>> The next change would be impossible without this. >>>>>>>> >>>>>>>>> >>>>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> >>>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>>> registration >>>>>>>>> ACK >>>>>>>>> >>>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in >>>>>>>>> docstrings >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> >>>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> >>>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>>>> to be >>>>>>> pushed into master. >>>>>>> All upto "frontend: allow commands to have an argument named >>>>>>> `name`" got >>>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>>> expected >>>>>>> now, ACK. >>>>>> >>>>>> Thanks for the review. >>>>>> >>>>>>> >>>>>>> Honzo, please rebase and push them, thanks! >>>>>>> >>>>>> >>>>>> Attaching the patches for reference. >>>>>> >>>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>>> >>>>> >>>>> Guys, you forgot to test it with newer pylint. >>>> >>>> I don't see any "BuildRequires: newer pylint" in the spec file. >>>> >>>>> >>>>> Patch attached. >>>> >>>> LGTM, although the commit message is wrong - this is not related to >>>> thin client at all, PublicError and PublicMessage had .kw since >>>> forever. >>>> >>> updated commit message >>> >>> >>> >>> >>> >> Can I push that fix for pylint? > > Sure, ACK. Pushed to master: aa4123d852d81b908cd18208577bb509fff08c5b > >> >> I found something suspicious in tests, did anything in IPA messages >> change? I suspect that this is related to client_patches. > > Yes, 'data' is a dict which contains structured message data. I did > not see these specific failures before, though. Just add it to > expected results where missing. > >> >> E AssertionError: assert_deepequal: dict keys mismatch. >> E 0026: permission_find: Search for u'testperm' with a >> limit of 1 (truncated) with members >> E missing keys = [] >> E extra keys = [u'data'] >> E expected = {'message': u'Search result has been >> truncated: Configured size limit exceeded', 'code': 13017, 'type': >> u'warning', 'name': u'SearchResultTruncated'} >> E got = {u'data': {u'reason': u'Configured size limit >> exceeded'}, u'message': u'Search result has been truncated: Configured >> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >> u'SearchResultTruncated'} >> E path = ('messages', 0) >> >> >> >> E AssertionError: assert_deepequal: dict keys mismatch. >> E 0024: permission_find: Search for u'testperm' with a >> limit of 1 (truncated) with members >> E missing keys = [] >> E extra keys = [u'data'] >> E expected = {'message': u'Search result has been >> truncated: Configured size limit exceeded', 'code': 13017, 'type': >> u'warning', 'name': u'SearchResultTruncated'} >> E got = {u'data': {u'reason': u'Configured size limit >> exceeded'}, u'message': u'Search result has been truncated: Configured >> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >> u'SearchResultTruncated'} >> E path = ('messages', 0) > From ldoudova at redhat.com Fri May 27 07:57:37 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 27 May 2016 09:57:37 +0200 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains Message-ID: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> Hi all, here [1] is a draft of test plan for V4 RFE Support of UPN for trusted domains. Please review this and let me know if there's something missing or wrong. Thanks, Lenka [1] http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains/Test_Plan From sbose at redhat.com Fri May 27 08:13:09 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 May 2016 10:13:09 +0200 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains In-Reply-To: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> References: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> Message-ID: <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote: > Hi all, > > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted > domains. > > Please review this and let me know if there's something missing or wrong. Hi Lenka, thank you for the test plan. About the TBD, Alexander and I agreed to store the alternative domain suffixes read from AD in a new attribute in the LDAP object of the forest root of the trusted domain. About the kinit tests. Please note that it is expected that the -E option of kinit must be used when alternative suffixes are used. I'm not sure if SSSD tests are in the scope here as well. If they are I would suggest to add authentication tests with SSSD where e.g. the name with an alternative domain suffix is used as login name. This in general already works with SSSD but is disabled by default for IPA because of the missing server-side support so far. Since SSSD must be able to work with old and new IPA server https://fedorahosted.org/sssd/ticket/3018 was created so that SSSD can detect at runtime if the server supports this or not. bye, Sumit > > > Thanks, > > Lenka > > > [1] > http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains/Test_Plan > > -- > 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 From abokovoy at redhat.com Fri May 27 08:24:24 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 May 2016 11:24:24 +0300 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains In-Reply-To: <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20160527082424.sr4wkzmcq4nwzpmg@redhat.com> On Fri, 27 May 2016, Sumit Bose wrote: >On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote: >> Hi all, >> >> >> here [1] is a draft of test plan for V4 RFE Support of UPN for trusted >> domains. >> >> Please review this and let me know if there's something missing or wrong. > >Hi Lenka, > >thank you for the test plan. > >About the TBD, Alexander and I agreed to store the alternative domain >suffixes read from AD in a new attribute in the LDAP object of the >forest root of the trusted domain. > >About the kinit tests. Please note that it is expected that the -E >option of kinit must be used when alternative suffixes are used. > >I'm not sure if SSSD tests are in the scope here as well. If they are I >would suggest to add authentication tests with SSSD where e.g. the name >with an alternative domain suffix is used as login name. This in general >already works with SSSD but is disabled by default for IPA because of >the missing server-side support so far. Since SSSD must be able to work >with old and new IPA server https://fedorahosted.org/sssd/ticket/3018 >was created so that SSSD can detect at runtime if the server supports >this or not. Right, I think we should make sure SSSD is tested against IPA UPN support because otherwise we might get regressions. -- / Alexander Bokovoy From pspacek at redhat.com Fri May 27 08:33:44 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 May 2016 10:33:44 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> Message-ID: <20c19eb5-80f4-3143-9a9b-f0f508e46fad@redhat.com> On 27.5.2016 09:26, Martin Basti wrote: > > > On 27.05.2016 07:49, Jan Cholasta wrote: >> On 26.5.2016 18:43, Martin Basti wrote: >>> >>> >>> On 26.05.2016 11:21, Martin Basti wrote: >>>> >>>> >>>> On 26.05.2016 07:15, Jan Cholasta wrote: >>>>> On 25.5.2016 18:17, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>>>> change >>>>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>>>> >>>>>>>>>>>>> Honza >>>>>>>>>>>>> >>>>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>>>> >>>>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>>>> LDAPQuery * >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>>>> class * >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>>>>> client * >>>>>>>>>>>> 1) >>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>> >>>>>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>>>>> VERSION >>>>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>>>> merged. >>>>>>>>>>> But we're not there yet, so fixed. >>>>>>>>>>> >>>>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>>>> >>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>> >>>>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>>>> ACK >>>>>>>>>>>> >>>>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>>>> 1) >>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> Did you find out why this was issue? >>>>>>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>>>>>> omitted? >>>>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>>>> error if >>>>>>>>>>>> omitted? >>>>>>>>>>> >>>>>>>>>>> The command definition was not complete, it was missing >>>>>>>>>>> has_output. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>> >>>>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>>>> counterparts * >>>>>>>>>>>> 1) >>>>>>>>>>>> you forgot to increment Version >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>>>>>> needed >>>>>>>>>>>> in commit message >>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The other commits I will check later. >>>>>>>>>>>> Martin^2 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Okay. Thanks. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * frontend: perform argument value validation only on server >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>>>>> havent >>>>>>>>>> found anything better to use. >>>>>>>>> >>>>>>>>> It always returned None for unset params. >>>>>>>>> >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * ipalib: optimize API.txt >>>>>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>>>>> copy of >>>>>>>>>> current to proper places, LGTM >>>>>>>>> >>>>>>>>> It's actually mostly cut-n-paste. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>>>> >>>>>>>>> The next change would be impossible without this. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>>>> registration >>>>>>>>>> ACK >>>>>>>>>> >>>>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>>>>> to be >>>>>>>> pushed into master. >>>>>>>> All upto "frontend: allow commands to have an argument named >>>>>>>> `name`" got >>>>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>>>> expected >>>>>>>> now, ACK. >>>>>>> >>>>>>> Thanks for the review. >>>>>>> >>>>>>>> >>>>>>>> Honzo, please rebase and push them, thanks! >>>>>>>> >>>>>>> >>>>>>> Attaching the patches for reference. >>>>>>> >>>>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>>>> >>>>>> >>>>>> Guys, you forgot to test it with newer pylint. >>>>> >>>>> I don't see any "BuildRequires: newer pylint" in the spec file. >>>>> >>>>>> >>>>>> Patch attached. >>>>> >>>>> LGTM, although the commit message is wrong - this is not related to >>>>> thin client at all, PublicError and PublicMessage had .kw since forever. >>>>> >>>> updated commit message >>>> >>>> >>>> >>>> >>>> >>> Can I push that fix for pylint? >> >> Sure, ACK. > Pushed to master: aa4123d852d81b908cd18208577bb509fff08c5b > > >> >>> >>> I found something suspicious in tests, did anything in IPA messages >>> change? I suspect that this is related to client_patches. >> >> Yes, 'data' is a dict which contains structured message data. I did not see >> these specific failures before, though. Just add it to expected results >> where missing. >> >>> >>> E AssertionError: assert_deepequal: dict keys mismatch. >>> E 0026: permission_find: Search for u'testperm' with a >>> limit of 1 (truncated) with members >>> E missing keys = [] >>> E extra keys = [u'data'] >>> E expected = {'message': u'Search result has been >>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>> u'warning', 'name': u'SearchResultTruncated'} >>> E got = {u'data': {u'reason': u'Configured size limit >>> exceeded'}, u'message': u'Search result has been truncated: Configured >>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>> u'SearchResultTruncated'} >>> E path = ('messages', 0) >>> >>> >>> >>> E AssertionError: assert_deepequal: dict keys mismatch. >>> E 0024: permission_find: Search for u'testperm' with a >>> limit of 1 (truncated) with members >>> E missing keys = [] >>> E extra keys = [u'data'] >>> E expected = {'message': u'Search result has been >>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>> u'warning', 'name': u'SearchResultTruncated'} >>> E got = {u'data': {u'reason': u'Configured size limit >>> exceeded'}, u'message': u'Search result has been truncated: Configured >>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>> u'SearchResultTruncated'} >>> E path = ('messages', 0) It is even worse that tests. If I call command 'ipa' or 'ipa help' it blows up. I'm attaching debug log from 'ipa -d' invocation. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.log Type: text/x-log Size: 4704 bytes Desc: not available URL: From thozza at redhat.com Fri May 27 08:41:49 2016 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 27 May 2016 10:41:49 +0200 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: hashsize() return type changed in libdns v164 Message-ID: Hello. Since bind version 9.10.4b1 (libdns version 164), the return type of hashsize() has changed from unsigned int to size_t. Without this change the plugin does not compile against bind 9.10.4b1 or newer on 64bit architecture. I tested building of the package on Fedora 24 and 25 and also RHEL-7.3. Regards, -- Tomas Hozza Senior Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-hashsize-return-type-changed-in-libdns-v164.patch Type: text/x-patch Size: 985 bytes Desc: not available URL: From pspacek at redhat.com Fri May 27 08:51:00 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 May 2016 10:51:00 +0200 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: hashsize() return type changed in libdns v164 In-Reply-To: References: Message-ID: <59532e3c-987f-1732-cb77-e47aaa7802a7@redhat.com> On 27.5.2016 10:41, Tomas Hozza wrote: > Hello. > > Since bind version 9.10.4b1 (libdns version 164), the return type of > hashsize() has changed from unsigned int to size_t. Without this change > the plugin does not compile against bind 9.10.4b1 or newer on 64bit > architecture. > > I tested building of the package on Fedora 24 and 25 and also RHEL-7.3. > > Regards, > Thanks! ACK, pushed to master: a6853a73a52fa2f4f329ef52fe05b108a5b4e8e4 -- Petr^2 Spacek From frenaud at redhat.com Fri May 27 09:35:46 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Fri, 27 May 2016 11:35:46 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Add the culprit line when a configuration file has an incorrect format Message-ID: Hi all, this patch adds information to the output of ipa-client-install when it fails due to invalid format in a configuration file: ipa-client-install failing with SyntaxError: Syntax Error: Unknown line format Fixes: https://fedorahosted.org/freeipa/ticket/5811 -- Florence Blanc-Renaud Identity Management Team, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-002-Add-the-culprit-line-when-a-configuration-file-has-a.patch Type: text/x-patch Size: 1408 bytes Desc: not available URL: From slaznick at redhat.com Fri May 27 11:42:28 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 27 May 2016 13:42:28 +0200 Subject: [Freeipa-devel] [PATCH 0034] Added some attributes to the Modify Users permission Message-ID: <08bcd7de-e32e-49ce-b8a3-2b2c3969805a@redhat.com> https://fedorahosted.org/freeipa/ticket/5911 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0034-Added-some-attributes-to-Modify-Users-permission.patch Type: text/x-patch Size: 4014 bytes Desc: not available URL: From slaznick at redhat.com Fri May 27 11:50:11 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 27 May 2016 13:50:11 +0200 Subject: [Freeipa-devel] [PATCH 35] Added pyusb dependency Message-ID: <49f94100-491f-b1f2-0ec8-b75ac8a9c540@redhat.com> https://fedorahosted.org/freeipa/ticket/5886 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0035-Added-pyusb-as-a-dependency.patch Type: text/x-patch Size: 998 bytes Desc: not available URL: From pspacek at redhat.com Fri May 27 12:12:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 May 2016 14:12:06 +0200 Subject: [Freeipa-devel] [PATCH 0123-132] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> Message-ID: On 25.5.2016 12:50, Martin Basti wrote: > > > On 20.05.2016 12:19, Petr Spacek wrote: >> On 11.5.2016 12:08, Martin Basti wrote: >>> >>> On 03.05.2016 14:59, Petr Spacek wrote: >>>> Hello, >>>> >>>> DNS upgrade: change forwarding policy to "only" if private IPs are used. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5710 >>>> >>>> This is the upgrade part. I will add one more patch to print a warning in >>>> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >>>> yet. >>>> >>>> >>>> >>> 1) >>> Upgrade failed with 'BindInstance' object has no attribute >>> 'named_conf_get_directive' >>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command >>> ipa-server-upgrade manually. >>> ('IPA upgrade failed.', 1) >>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more >>> information >>> >>> 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no >>> attribute 'named_conf_get_directive' >>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >>> 213, in __upgrade >>> self.modified = (ld.update(self.files) or self.modified) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>> line 917, in update >>> self._run_updates(all_updates) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>> line 889, in _run_updates >>> self._run_update_plugin(update['plugin']) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>> line 862, in _run_update_plugin >>> restart_ds, updates = self.api.Updater[plugin_name]() >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1418, in >>> __call__ >>> return self.execute(**options) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>> line 547, in execute >>> self.update_global_named_conf_forwarder(bind) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>> line 508, in update_global_named_conf_forwarder >>> if bind.named_conf_get_directive( >>> AttributeError: 'BindInstance' object has no attribute >>> 'named_conf_get_directive' >>> >>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 447, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 437, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >>> 221, in __upgrade >>> raise RuntimeError(e) >>> RuntimeError: 'BindInstance' object has no attribute >>> 'named_conf_get_directive' >>> >>> PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new >>> attribute * >>> 2) >>> + Int('ipadnsversion?', >>> + label=_('IPA DNS version'), >>> + ), >>> >>> Shouldn't be this part of System: Read DNS Configuration permission? >>> >>> 3) >>> - def postprocess_result(self, result): >>> + def postprocess_result(self, result, show_version): >>> if not any(param in result['result'] for param in self.params): >>> result['summary'] = unicode(_('Global DNS configuration is >>> empty')) >>> >>> show_version param was added but I don't see it used in this patch. >>> >>> 4) >>> + Int('ipadnsversion?', >>> + label=_('IPA DNS version'), >>> + ), >>> >>> Could we add comment here that this option is accessible only from installers >>> and upgrade? >>> >>> 5) >>> + for config_option in container_entry.get("ipaConfigString", []): >>> + matched = re.match("^DNSVersion\s+(?P\d+)$", >>> + config_option, flags=re.I) >>> + if matched: >>> + version = int(matched.group("version")) >>> >>> Shouldn't we print error if version cannot be parsed? >>> >>> PATCH * DNS upgrade: separate backup logic to make it reusable * >>> >>> LGTM >>> >>> PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * >>> >>> 7) >>> I'm curious why do you need to check superdomains? >>> >>> PATCH * DNS upgrade: change forwarding policy to = only for conflicting >>> forward zones* >>> >>> 8) >>> + self.log.debug('Zone %s was sucessfully modified to use ' >>> + 'forward policy "only"', zone['idnsname'][0]) >>> <---missing empty line----> >>> + def execute(self, **options): >>> >>> PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if >>> private IPs are used * >>> 9) >>> - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) >>> + dnsutil.related_to_auto_empty_zone( >>> + dnsutil.DNSName(zone.get('idnsname')[0])) >>> >>> Should be in previous commit >>> >>> 10) >>> - return >>> + return False, [] >>> This should be fixed in the previous commit >>> >>> PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" >>> if private IPs are used * >>> 11) >>> IMO this is an upgrade of configuration and this should be in >>> ipaserver/install/server/upgrade.py, upgrade plugins are used only for >>> updating of LDAP values >>> >>> Unless you really want to use this as precedence, but then it requires broader >>> discussion. >>> >>> 12) >>> >>> bind.named_conf_get_directive >>> should be >>> bindinstance.named_conf_get_directive >>> >>> see 1) >> This new patchset completely obsoletes the old one. I had to reshuffle few >> things to to make the split between server config & LDAP upgrade possible. >> >> Hopefully I addressed all your comment. >> > > commits > * Move IP address resolution from ipaserver.install.installutils to > ipapython.dnsutil * and * Turn verify_host_resolvable() into a wrapper around > ipapython.dnsutil * > > cause regression in case that dns.python resolver returns NoNameservers > exception, it is handled as 'Internal server error' > > In original code every exception was caught and transformed to > DNSNotARecordError. > > So we have following options: > * keep the old behavior in 'resolve_rrsets' and catch all exceptions there > * or catch all DNS errors in 'verify_host_resolvable' and raise it as new > PublicError (DNSGenericError (doesn't exist) for example) > > > E InternalError: an internal error has occurred > > ../ipalib/rpc.py:1100: InternalError > test_forwardzone_delegation_warnings.test_command[0017: dnsrecord_mod: Delete > (using dnsrecord-mod) NS record which delegates zone > u'fw.sub2.sub.dnszone.test.' from zone u'dnszone.test' (expected warning for > u'fw.sub2.sub.dnszone.test.')] > > [Wed May 25 12:17:00.172143 2016] [wsgi:error] [pid 62789] Traceback (most > recent call last): > [Wed May 25 12:17:00.172152 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in > wsgi_execute > [Wed May 25 12:17:00.172158 2016] [wsgi:error] [pid 62789] result = > self.Command[name](*args, **options) > [Wed May 25 12:17:00.172164 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 434, in __call__ > [Wed May 25 12:17:00.172168 2016] [wsgi:error] [pid 62789] return > self.__do_call(*args, **options) > [Wed May 25 12:17:00.172173 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 460, in __do_call > [Wed May 25 12:17:00.172178 2016] [wsgi:error] [pid 62789] ret = > self.run(*args, **options) > [Wed May 25 12:17:00.172183 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 777, in run > [Wed May 25 12:17:00.172189 2016] [wsgi:error] [pid 62789] return > self.execute(*args, **options) > [Wed May 25 12:17:00.172194 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3774, in execute > [Wed May 25 12:17:00.172199 2016] [wsgi:error] [pid 62789] result = > super(dnsrecord_add, self).execute(*keys, **options) > [Wed May 25 12:17:00.172204 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1230, in > execute > [Wed May 25 12:17:00.172209 2016] [wsgi:error] [pid 62789] *keys, **options) > [Wed May 25 12:17:00.172213 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3719, in > pre_callback > [Wed May 25 12:17:00.172229 2016] [wsgi:error] [pid 62789] > self.obj.run_precallback_validators(dn, entry_attrs, *keys, **options) > [Wed May 25 12:17:00.172237 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3135, in > run_precallback_validators > [Wed May 25 12:17:00.172242 2016] [wsgi:error] [pid 62789] rtype_cb(ldap, dn, > entry_attrs, *keys, **options) > [Wed May 25 12:17:00.172247 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3057, in > _nsrecord_pre_callback > [Wed May 25 12:17:00.172252 2016] [wsgi:error] [pid 62789] > check_ns_rec_resolvable(keys[0], DNSName(nsrecord), self.log) > [Wed May 25 12:17:00.172256 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1577, in > check_ns_rec_resolvable > [Wed May 25 12:17:00.172261 2016] [wsgi:error] [pid 62789] > verify_host_resolvable(name) > [Wed May 25 12:17:00.172265 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipalib/util.py", line 70, in > verify_host_resolvable > [Wed May 25 12:17:00.172270 2016] [wsgi:error] [pid 62789] if not > resolve_ip_addresses(fqdn): > [Wed May 25 12:17:00.172274 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 328, in > resolve_ip_addresses > [Wed May 25 12:17:00.172278 2016] [wsgi:error] [pid 62789] rrsets = > resolve_rrsets(fqdn, ['A', 'AAAA']) > [Wed May 25 12:17:00.172282 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 305, in > resolve_rrsets > [Wed May 25 12:17:00.172287 2016] [wsgi:error] [pid 62789] answer = > dns.resolver.query(fqdn, rdtype) > [Wed May 25 12:17:00.172292 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/dns/resolver.py", line 1029, in query > [Wed May 25 12:17:00.172296 2016] [wsgi:error] [pid 62789] raise_on_no_answer, > source_port) > [Wed May 25 12:17:00.172301 2016] [wsgi:error] [pid 62789] File > "/usr/lib/python2.7/site-packages/dns/resolver.py", line 856, in query > [Wed May 25 12:17:00.172328 2016] [wsgi:error] [pid 62789] raise > NoNameservers(request=request, errors=errors) Fixed patches are attached. Please note that I've renumbered the patches because the naming does not match the original set anymore. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0123-Move-check_zone_overlap-from-ipapython.ipautil-to-ip.patch Type: text/x-patch Size: 8779 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0124-Use-root_logger-for-verify_host_resolvable.patch Type: text/x-patch Size: 7354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0125-Move-IP-address-resolution-from-ipaserver.install.in.patch Type: text/x-patch Size: 7559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0126-Turn-verify_host_resolvable-into-a-wrapper-around-ip.patch Type: text/x-patch Size: 6381 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0127-Add-ipaDNSVersion-option-to-dnsconfig-commands-and-u.patch Type: text/x-patch Size: 16167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0128-DNS-upgrade-separate-backup-logic-to-make-it-reusabl.patch Type: text/x-patch Size: 9297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0129-Add-function-ipapython.dnsutil.related_to_auto_empty.patch Type: text/x-patch Size: 1859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0130-DNS-upgrade-change-forwarding-policy-to-only-for-con.patch Type: text/x-patch Size: 6178 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0131-DNS-upgrade-change-global-forwarding-policy-in-LDAP-.patch Type: text/x-patch Size: 3275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0132-DNS-upgrade-change-global-forwarding-policy-in-named.patch Type: text/x-patch Size: 5852 bytes Desc: not available URL: From pspacek at redhat.com Fri May 27 12:13:09 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 May 2016 14:13:09 +0200 Subject: [Freeipa-devel] [PATCH 0110] DNS: Warn if forwarding policy conflicts with automatic empty zone In-Reply-To: References: <44b60702-e8cb-364f-39bc-114404349972@redhat.com> Message-ID: <3e925ead-6fbd-ef81-d704-bba77009eb13@redhat.com> On 25.5.2016 12:30, Martin Basti wrote: > > > On 04.05.2016 10:43, Petr Spacek wrote: >> Hello, >> >> DNS: Warn if forwarding policy conflicts with automatic empty zones >> >> Forwarding policy "first" or "none" may conflicts with some automatic empty >> zones. Queries for zones specified by RFC 6303 will ignore >> forwarding and recursion and always result in NXDOMAIN answers. >> >> This is not detected and warned about. Global forwarding is equivalent >> to forward zone ".". >> >> Example: >> Forward zone 1.10.in-addr.arpa with policy "first" >> will not forward anything because BIND will automatically prefer >> automatic empty zone "10.in-addr.arpa." which is authoritative. >> >> https://fedorahosted.org/freeipa/ticket/5710 >> >> >> This is last patch in the series so the ticket can be closed when all relevant >> patches are pushed. >> >> >> > > > You forgot to update tests > > _____________________________________________________________________ > test_dns.test_command[0087: dnsconfig_mod: Update global DNS settings] > ______________________________________________________________________ > > self = 0x7fcef3ef2510>, index = 87 > declarative_test_definition = {'command': ('dnsconfig_mod', [], > {'idnsforwarders': ['172.16.31.80'], 'version': '2.166'}), 'desc': 'Update > global DN...arders': ['172.16.31.80']}, 'summary': None, 'value': None}, > 'nice': '0087: dnsconfig_mod: Update global DNS settings'} > > def test_command(self, index, declarative_test_definition): > """Run an individual test > > The arguments are provided by the pytest plugin. > """ > if callable(declarative_test_definition): > declarative_test_definition(self) > else: >> self.check(**declarative_test_definition) > > test_xmlrpc/xmlrpc_test.py:313: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > test_xmlrpc/xmlrpc_test.py:325: in check > self.check_output(nice, cmd, args, options, expected, extra_check) > test_xmlrpc/xmlrpc_test.py:368: in check_output > assert_deepequal(expected, got, nice) > util.py:361: in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > expected = [{'code': 13006, 'message': at 0x7fcef426c758>, > 'name': 'DNSServerValidationWarning', 'type': 'warning'}] > got = [{'code': 13021, 'message': "Forwarding policy conflicts with some > automatic empty zones. Queries for zones specified ...': The DNS operation > timed out after 10.0008428097 seconds.", 'name': 'DNSServerValidationWarning', > 'type': 'warning'}] > doc = '0087: dnsconfig_mod: Update global DNS settings', stack = ('messages',) > > def assert_deepequal(expected, got, doc='', stack=tuple()): > """ > Recursively check for type and equality. > > If a value in expected is callable then it will used as a callback to > test for equality on the got value. The callback is passed the got > value and returns True if equal, False otherwise. > > If the tests fails, it will raise an ``AssertionError`` with detailed > information, including the path to the offending value. For example: > > >>> expected = [u'Hello', dict(world=u'how are you?')] > >>> got = [u'Hello', dict(world='how are you?')] > >>> expected == got > True > >>> assert_deepequal(expected, got, doc='Testing my nested data') > Traceback (most recent call last): > ... > AssertionError: assert_deepequal: type(expected) is not type(got). > Testing my nested data > type(expected) = > type(got) = > expected = u'how are you?' > got = 'how are you?' > path = (0, 'world') > > Note that lists and tuples are considered equivalent, and the order of > their elements does not matter. > """ > if isinstance(expected, tuple): > expected = list(expected) > if isinstance(got, tuple): > got = list(got) > if isinstance(expected, DN): > if isinstance(got, six.string_types): > got = DN(got) > if not (isinstance(expected, Fuzzy) or callable(expected) or > type(expected) is type(got)): > raise AssertionError( > TYPE % (doc, type(expected), type(got), expected, got, stack) > ) > if isinstance(expected, (list, tuple)): > if len(expected) != len(got): > raise AssertionError( >> LEN % (doc, len(expected), len(got), expected, got, stack) > ) > E AssertionError: assert_deepequal: list length mismatch. > E 0087: dnsconfig_mod: Update global DNS settings > E len(expected) = 1 > E len(got) = 2 > E expected = [{u'message': at > 0x7fcef426c758>, u'code': 13006, u'type': u'warning', u'name': > u'DNSServerValidationWarning'}] > E got = [{u'message': u"Forwarding policy conflicts with some > automatic empty zones. Queries for zones specified by RFC 6303 will ignore > forwarding and recursion and always result in NXDOMAIN answers. To override > this behavior use forward policy 'only'.", u'code': 13021, u'type': > u'warning', u'name': u'DNSForwardPolicyConflictWithEmptyZone'}, {u'message': > u"DNS server 172.16.31.80: query '. SOA': The DNS operation timed out after > 10.0008428097 seconds.", u'code': 13006, u'type': u'warning', u'name': > u'DNSServerValidationWarning'}] > E path = (u'messages',) > > util.py:332: AssertionError Fixed patch is attached. It depends on newest patches 113-132. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0110-2-DNS-Warn-if-forwarding-policy-conflicts-with-automat.patch Type: text/x-patch Size: 6737 bytes Desc: not available URL: From slaznick at redhat.com Fri May 27 12:52:37 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 27 May 2016 14:52:37 +0200 Subject: [Freeipa-devel] [PATCH 0036] Increased mod_wsgi socket-timeout Message-ID: <304a20ca-ca5b-8df7-f1ca-090c60ec3a01@redhat.com> https://fedorahosted.org/freeipa/ticket/5833 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0036-Increased-mod_wsgi-socket-timeout.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From frenaud at redhat.com Fri May 27 13:53:11 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Fri, 27 May 2016 15:53:11 +0200 Subject: [Freeipa-devel] [PATCH] 0003 batch command can be used to trigger internal errors on server Message-ID: <6b54d58e-58c5-02a7-d6fb-6f370ab14770@redhat.com> Hi all, the following patch checks the format of parameters passed to a method called through the batch command. I picked the ConversionError for invalid parameters format but this choice can be discussed if you have better suggestions... Fixes: https://fedorahosted.org/freeipa/ticket/5810 -- Florence Blanc-Renaud Identity Management Team, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-003-batch-command-can-be-used-to-trigger-internal-errors.patch Type: text/x-patch Size: 3290 bytes Desc: not available URL: From slaznick at redhat.com Fri May 27 14:17:24 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 27 May 2016 16:17:24 +0200 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf Message-ID: https://fedorahosted.org/freeipa/ticket/5912 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0037-Added-krb5.conf.d-to-included-dirs-in-krb5.conf.patch Type: text/x-patch Size: 2200 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 27 15:25:55 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 11:25:55 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management Message-ID: <1464362755.3425.7.camel@redhat.com> All core functionality for authentication indicators has already been merged. All that is left is the CLI and UI patches. Attached is the CLI patch. One outstanding question that I have is how to future-proof this patch. Right now, we want to only permit two possible values: otp and radius. So we are using an StrEnum. However, in the future (probably after krb5-spake) we may want to have per-token custom indicators. That means that this value will need to become a Str. How do I code this so that we can later do a StrEnum => Str transition without breaking API? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0093-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 5008 bytes Desc: not available URL: From mbabinsk at redhat.com Fri May 27 15:30:38 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 May 2016 17:30:38 +0200 Subject: [Freeipa-devel] [PATCH 0146-0147] Server Roles: basic infrastructure In-Reply-To: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> References: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> Message-ID: <0ba1b172-3bb8-0c29-8212-72c7027841a9@redhat.com> On 05/19/2016 04:59 PM, Martin Babinsky wrote: > Patch 0146 implements lower-lever infrastructure for querying server > roles/attributes > > Patch 0147 are some basic tests slapped together for the `serverroles` > backend to ensure that it works as expected. > > The new/modified CLI commands specified in the design page [1] will be > coming soon. > > Also coming soon will be an interface to construct DNS records for each > role requested by Petr^2 and Martin^2 which I will start implement when > we agree on the backend implementation. > > https://fedorahosted.org/freeipa/ticket/5181 > > [1] https://www.freeipa.org/page/V4/Server_Roles#CLI > > > Thanks Martin and Honza for review. I have reworked the patches based on your comments. I have split patch 146 into two (role/attribute definitions and backend code) so patches 146-147 are for code and 148 hosts test suite. I hope that I will send API patches on monday after I resolve some framework-related questions with the local guru. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0146-Server-roles-definitions-of-server-roles-and-attribu.patch Type: text/x-patch Size: 20917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0147-Server-Roles-Backend-plugin-to-query-roles-and-attri.patch Type: text/x-patch Size: 6495 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0148-Test-suite-for-serverroles-backend.patch Type: text/x-patch Size: 25510 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 27 15:33:54 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 11:33:54 -0400 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464107138.2783.28.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> <1464102105.2783.16.camel@redhat.com> <1464107138.2783.28.camel@redhat.com> Message-ID: <1464363234.3425.8.camel@redhat.com> On Tue, 2016-05-24 at 12:25 -0400, Nathaniel McCallum wrote: > On Tue, 2016-05-24 at 11:01 -0400, Nathaniel McCallum wrote: > > On Tue, 2016-05-24 at 16:55 +0200, Martin Kosek wrote: > > > On 05/24/2016 04:29 PM, Nathaniel McCallum wrote: > > > > Using a pragma instead of guards is easier to write, less error > > > > prone > > > > and avoids name clashes (a source of very subtle bugs). This > > > > pragma > > > > is supported on almost all compilers, including all the > > > > compilers > > > > we > > > > care about: https://en.wikipedia.org/wiki/Pragma_once#Portabili > > > > ty > > > > . > > > > > > > > > > > > > > > > > > Makes sense to me. I did not test, just saw a potential > > > typo/omission: > > > > > > --- a/daemons/ipa-otpd/internal.h > > > +++ b/daemons/ipa-otpd/internal.h > > > @@ -20,9 +20,6 @@ > > > ? * along with this program.??If not, see > > en > > > se > > > s/>. > > > ? */ > > > > > > -#ifndef INTERNAL_H_ > > > -#define INTERNAL_H_ > > > - > > > > > > > > > ... no pragma there. > > > > Fixed. > > Here is a new version with a slightly edited commit message (just to > confirm that we don't edit the autogenerated files). Attached is a new version that is simply rebased on to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0094-Migrate-from-ifndef-guards-to-pragma-once.patch Type: text/x-patch Size: 10534 bytes Desc: not available URL: From abokovoy at redhat.com Fri May 27 15:35:05 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 May 2016 18:35:05 +0300 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <1464362755.3425.7.camel@redhat.com> References: <1464362755.3425.7.camel@redhat.com> Message-ID: <20160527153505.4627dvyqdwqwbyuf@redhat.com> On Fri, 27 May 2016, Nathaniel McCallum wrote: >All core functionality for authentication indicators has already been >merged. All that is left is the CLI and UI patches. Attached is the CLI >patch. > >One outstanding question that I have is how to future-proof this patch. >Right now, we want to only permit two possible values: otp and radius. >So we are using an StrEnum. However, in the future (probably after >krb5-spake) we may want to have per-token custom indicators. That means >that this value will need to become a Str. PKINIT has already support for AI, so it would be good to add pkinit indicator as well. The problem here is that pkinit indicator is not fixed and can be defined in the krb5.conf. >How do I code this so that we can later do a StrEnum => Str transition >without breaking API? Maybe just go to Str* right now and make a validation function that performs the actual check? Once you'd upgrade the validation code would change but method signature wouldn't. -- / Alexander Bokovoy From pvomacka at redhat.com Fri May 27 15:43:21 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 27 May 2016 17:43:21 +0200 Subject: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators In-Reply-To: <1463087612.2785.10.camel@redhat.com> References: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> <1463087612.2785.10.camel@redhat.com> Message-ID: <499355d3-a44e-f330-8bac-4959a04822d2@redhat.com> On 05/12/2016 11:13 PM, Nathaniel McCallum wrote: > On Wed, 2016-05-11 at 13:08 +0200, Pavel Vomacka wrote: >> Hi, >> >> the patch adds webui part for authentication indicators. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/5872 > The otp option displays as: OTP. > The radius option displays as: Radius. > > However, both are acronyms. The capitalization should be consistent. I'm sorry for late answer. They are displayed this way: 'OTP' and 'Radius'. So it should not require any change. -- Pavel^3 From npmccallum at redhat.com Fri May 27 15:44:01 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 11:44:01 -0400 Subject: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators In-Reply-To: <499355d3-a44e-f330-8bac-4959a04822d2@redhat.com> References: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> <1463087612.2785.10.camel@redhat.com> <499355d3-a44e-f330-8bac-4959a04822d2@redhat.com> Message-ID: <1464363841.3425.10.camel@redhat.com> On Fri, 2016-05-27 at 17:43 +0200, Pavel Vomacka wrote: > > On 05/12/2016 11:13 PM, Nathaniel McCallum wrote: > > On Wed, 2016-05-11 at 13:08 +0200, Pavel Vomacka wrote: > > > Hi, > > > > > > the patch adds webui part for authentication indicators. > > > > > > Ticket: https://fedorahosted.org/freeipa/ticket/5872 > > The otp option displays as: OTP. > > The radius option displays as: Radius. > > > > However, both are acronyms. The capitalization should be > > consistent. > I'm sorry for late answer. They are displayed this way: 'OTP' and? > 'Radius'. So it should not require any change. That is incorrect. It should be: OTP and RADIUS. From npmccallum at redhat.com Fri May 27 15:55:03 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 11:55:03 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <20160527153505.4627dvyqdwqwbyuf@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> Message-ID: <1464364503.3425.13.camel@redhat.com> On Fri, 2016-05-27 at 18:35 +0300, Alexander Bokovoy wrote: > On Fri, 27 May 2016, Nathaniel McCallum wrote: > > All core functionality for authentication indicators has already > > been > > merged. All that is left is the CLI and UI patches. Attached is the > > CLI > > patch. > > > > One outstanding question that I have is how to future-proof this > > patch. > > Right now, we want to only permit two possible values: otp and > > radius. > > So we are using an StrEnum. However, in the future (probably after > > krb5-spake) we may want to have per-token custom indicators. That > > means > > that this value will need to become a Str. > PKINIT has already support for AI, so it would be good to add pkinit > indicator as well. The problem here is that pkinit indicator is not > fixed and can be defined in the krb5.conf. Okay. You've convinced me that we should just make it a string now and be done with it since administrators can already set custom AIs. New patch attached. I think this is ready for merge. > > How do I code this so that we can later do a StrEnum => Str > > transition > > without breaking API? > Maybe just go to Str* right now and make a validation function that > performs the actual check? Once you'd upgrade the validation code > would > change but method signature wouldn't. Since admins can already set custom AIs, there is no reason for a validator. Let's just accept everything. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0093-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 4929 bytes Desc: not available URL: From pvomacka at redhat.com Fri May 27 15:58:52 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 27 May 2016 17:58:52 +0200 Subject: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators In-Reply-To: <1464363841.3425.10.camel@redhat.com> References: <3e3162a1-8d3b-5acf-734c-9e33c173e615@redhat.com> <1463087612.2785.10.camel@redhat.com> <499355d3-a44e-f330-8bac-4959a04822d2@redhat.com> <1464363841.3425.10.camel@redhat.com> Message-ID: On 05/27/2016 05:44 PM, Nathaniel McCallum wrote: > On Fri, 2016-05-27 at 17:43 +0200, Pavel Vomacka wrote: >> On 05/12/2016 11:13 PM, Nathaniel McCallum wrote: >>> On Wed, 2016-05-11 at 13:08 +0200, Pavel Vomacka wrote: >>>> Hi, >>>> >>>> the patch adds webui part for authentication indicators. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/5872 >>> The otp option displays as: OTP. >>> The radius option displays as: Radius. >>> >>> However, both are acronyms. The capitalization should be >>> consistent. >> I'm sorry for late answer. They are displayed this way: 'OTP' and >> 'Radius'. So it should not require any change. > That is incorrect. It should be: OTP and RADIUS. I'm sorry, I didn't understand correctly. Fixed patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0034-2-Add-authentication-indicators-to-webui.patch Type: text/x-patch Size: 4853 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 27 16:00:30 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 12:00:30 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <1464364503.3425.13.camel@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> Message-ID: <1464364830.3425.14.camel@redhat.com> Pavel, since we made the change here from a StrEnum to a Str, we need to update the UI patch accordingly. On Fri, 2016-05-27 at 11:55 -0400, Nathaniel McCallum wrote: > On Fri, 2016-05-27 at 18:35 +0300, Alexander Bokovoy wrote: > > On Fri, 27 May 2016, Nathaniel McCallum wrote: > > > All core functionality for authentication indicators has already > > > been > > > merged. All that is left is the CLI and UI patches. Attached is > > > the > > > CLI > > > patch. > > > > > > One outstanding question that I have is how to future-proof this > > > patch. > > > Right now, we want to only permit two possible values: otp and > > > radius. > > > So we are using an StrEnum. However, in the future (probably > > > after > > > krb5-spake) we may want to have per-token custom indicators. That > > > means > > > that this value will need to become a Str. > > PKINIT has already support for AI, so it would be good to add > > pkinit > > indicator as well. The problem here is that pkinit indicator is not > > fixed and can be defined in the krb5.conf. > > Okay. You've convinced me that we should just make it a string now > and > be done with it since administrators can already set custom AIs. New > patch attached. I think this is ready for merge. > > > > How do I code this so that we can later do a StrEnum => Str > > > transition > > > without breaking API? > > Maybe just go to Str* right now and make a validation function that > > performs the actual check? Once you'd upgrade the validation code > > would > > change but method signature wouldn't. > > Since admins can already set custom AIs, there is no reason for a > validator. Let's just accept everything. From npmccallum at redhat.com Fri May 27 16:17:40 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 May 2016 12:17:40 -0400 Subject: [Freeipa-devel] [PATCH 0095] Fix RADIUS capitalization Message-ID: <1464365860.3425.16.camel@redhat.com> RADIUS is an acryonym. This patch fixes its usage to match our capitalization of other acronyms, like OTP. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0095-Fix-RADIUS-capitalization.patch Type: text/x-patch Size: 6963 bytes Desc: not available URL: From rharwood at redhat.com Fri May 27 21:53:53 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Fri, 27 May 2016 17:53:53 -0400 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf In-Reply-To: References: Message-ID: Stanislav Laznicka writes: > From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001 > From: Stanislav Laznicka > Date: Fri, 27 May 2016 16:12:31 +0200 > Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf > > The include of /etc/krb5.conf.d/ is required for crypto-policies to work properly > > https://fedorahosted.org/freeipa/ticket/5912 Thank you for working on this. Is the intent on the part of FreeIPA to keep a separate, freeipa-speicifc directory? And if so, can I suggest that we not do that? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From abokovoy at redhat.com Sat May 28 04:24:51 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 28 May 2016 07:24:51 +0300 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf In-Reply-To: References: Message-ID: <20160528042451.lewcj5jnicq2noxd@redhat.com> On Fri, 27 May 2016, Robbie Harwood wrote: >Stanislav Laznicka writes: > >> From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001 >> From: Stanislav Laznicka >> Date: Fri, 27 May 2016 16:12:31 +0200 >> Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf >> >> The include of /etc/krb5.conf.d/ is required for crypto-policies to work properly >> >> https://fedorahosted.org/freeipa/ticket/5912 > >Thank you for working on this. Is the intent on the part of FreeIPA to >keep a separate, freeipa-speicifc directory? And if so, can I suggest >that we not do that? Which directory are you talking about? /var/lib/sss/pubconf/krb5.include.d/? SSSD directory is used already by all FreeIPA clients for very long time because SSSD puts several important snippets there: - CA paths and domain_realm information based on the trust topology of FreeIPA - localauth plugin definition for SSSD plugin SSSD cannot write to /etc and I don't think we have to change it. -- / Alexander Bokovoy From mbasti at redhat.com Sat May 28 11:17:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 28 May 2016 13:17:31 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches Message-ID: https://fedorahosted.org/freeipa/ticket/4995 Patches attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0488-Make-option-no-members-public-in-CLI.patch Type: text/x-patch Size: 1068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0489-Performance-Find-commands-do-not-process-members-by-.patch Type: text/x-patch Size: 88521 bytes Desc: not available URL: From mbasti at redhat.com Sat May 28 11:28:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 28 May 2016 13:28:48 +0200 Subject: [Freeipa-devel] [PATCH 0095] Fix RADIUS capitalization In-Reply-To: <1464365860.3425.16.camel@redhat.com> References: <1464365860.3425.16.camel@redhat.com> Message-ID: <4df6dde5-c4ca-23c1-3b12-bca5a3e2efdf@redhat.com> On 27.05.2016 18:17, Nathaniel McCallum wrote: > RADIUS is an acryonym. This patch fixes its usage to match our > capitalization of other acronyms, like OTP. > > Hi Nathaniel, I don't think that translations should be modified by this patch, because translation will be replaced by pulling new translations from zanata, this should be changed on zanata side Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sat May 28 13:59:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 28 May 2016 15:59:35 +0200 Subject: [Freeipa-devel] [PATCH 0036] Increased mod_wsgi socket-timeout In-Reply-To: <304a20ca-ca5b-8df7-f1ca-090c60ec3a01@redhat.com> References: <304a20ca-ca5b-8df7-f1ca-090c60ec3a01@redhat.com> Message-ID: <58d3d9ef-d8c5-50be-1348-3c8b2835d70d@redhat.com> On 27.05.2016 14:52, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/5833 > > > Is possible to remove timeout completely as it used to be before? Even if this timeout is exceeded, command continue in execution and it just doesnt print result to user Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sat May 28 14:25:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 28 May 2016 16:25:49 +0200 Subject: [Freeipa-devel] [PATCH 35] Added pyusb dependency In-Reply-To: <49f94100-491f-b1f2-0ec8-b75ac8a9c540@redhat.com> References: <49f94100-491f-b1f2-0ec8-b75ac8a9c540@redhat.com> Message-ID: <8b508b89-03c4-90fd-272e-47f90e121d23@redhat.com> On 27.05.2016 13:50, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/5886 > > > ACK master: * c91d8099331513ca2147e5220312e444f0b2dae5 Added pyusb as a dependency ipa-4-3: * d20c8318cd735ac9f811f51a1501b8ba66ecea09 Added pyusb as a dependency -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sat May 28 14:34:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 28 May 2016 16:34:18 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Add missing CA options to the manpage for ipa-replica-install In-Reply-To: References: Message-ID: <38f63a5b-6c52-f16f-0470-adf0b1b0b304@redhat.com> On 26.05.2016 11:30, Stanislav Laznicka wrote: > > Hello, > > Thank you for your first patch! It seems fine to me so ACK. > > Standa > master: * 9cbb54db99eb1855a5c840699072ead9b6d75d04 Add missing CA options to the manpage for ipa-replica-install bottom posting Standa please > On 05/20/2016 12:52 PM, Florence Blanc-Renaud wrote: >> >> Hi all, >> >> this one will be my first patch submission, so apologies in advance >> if I make mistakes... >> >> The man page for ipa-replica-install was missing some commands >> related to CA-less installation, as well as --allow-zone-overlap and >> --auto-reverse. I added them in the relevant sections (CERTIFICATE >> SYSTEM OPTIONS and DNS OPTIONS). >> >> I also fixed a wrong short option for --realm (-r). >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5835 >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Sat May 28 16:33:02 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Sat, 28 May 2016 18:33:02 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <20c19eb5-80f4-3143-9a9b-f0f508e46fad@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> <20c19eb5-80f4-3143-9a9b-f0f508e46fad@redhat.com> Message-ID: <97013cc1-6a16-0c26-1ae6-882d96ff6918@redhat.com> On 05/27/2016 10:33 AM, Petr Spacek wrote: > On 27.5.2016 09:26, Martin Basti wrote: >> >> On 27.05.2016 07:49, Jan Cholasta wrote: >>> On 26.5.2016 18:43, Martin Basti wrote: >>>> >>>> On 26.05.2016 11:21, Martin Basti wrote: >>>>> >>>>> On 26.05.2016 07:15, Jan Cholasta wrote: >>>>>> On 25.5.2016 18:17, Martin Basti wrote: >>>>>>> >>>>>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>>>>> change >>>>>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Honza >>>>>>>>>>>>>> >>>>>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>>>>> >>>>>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>>>>> LDAPQuery * >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>>>>> class * >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>>>>>> client * >>>>>>>>>>>>> 1) >>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>>>>>> VERSION >>>>>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>>>>> merged. >>>>>>>>>>>> But we're not there yet, so fixed. >>>>>>>>>>>> >>>>>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>>>>> ACK >>>>>>>>>>>>> >>>>>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>>>>> 1) >>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>> Fixed. >>>>>>>>>>>> >>>>>>>>>>>>> 2) >>>>>>>>>>>>> Did you find out why this was issue? >>>>>>>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>>>>>>> omitted? >>>>>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>>>>> error if >>>>>>>>>>>>> omitted? >>>>>>>>>>>> The command definition was not complete, it was missing >>>>>>>>>>>> has_output. >>>>>>>>>>>> >>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>>>>> counterparts * >>>>>>>>>>>>> 1) >>>>>>>>>>>>> you forgot to increment Version >>>>>>>>>>>> Fixed. >>>>>>>>>>>> >>>>>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>>>>>>> needed >>>>>>>>>>>>> in commit message >>>>>>>>>>>> Fixed. >>>>>>>>>>>> >>>>>>>>>>>>> The other commits I will check later. >>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>> >>>>>>>>>>>> Okay. Thanks. >>>>>>>>>>>> >>>>>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * frontend: perform argument value validation only on server >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>>>>>> havent >>>>>>>>>>> found anything better to use. >>>>>>>>>> It always returned None for unset params. >>>>>>>>>> >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * ipalib: optimize API.txt >>>>>>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>>>>>> copy of >>>>>>>>>>> current to proper places, LGTM >>>>>>>>>> It's actually mostly cut-n-paste. >>>>>>>>>> >>>>>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>>>>> The next change would be impossible without this. >>>>>>>>>> >>>>>>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>>>>> registration >>>>>>>>>>> ACK >>>>>>>>>>> >>>>>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>>>>>> to be >>>>>>>>> pushed into master. >>>>>>>>> All upto "frontend: allow commands to have an argument named >>>>>>>>> `name`" got >>>>>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>>>>> expected >>>>>>>>> now, ACK. >>>>>>>> Thanks for the review. >>>>>>>> >>>>>>>>> Honzo, please rebase and push them, thanks! >>>>>>>>> >>>>>>>> Attaching the patches for reference. >>>>>>>> >>>>>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>>>>> >>>>>>> Guys, you forgot to test it with newer pylint. >>>>>> I don't see any "BuildRequires: newer pylint" in the spec file. >>>>>> >>>>>>> Patch attached. >>>>>> LGTM, although the commit message is wrong - this is not related to >>>>>> thin client at all, PublicError and PublicMessage had .kw since forever. >>>>>> >>>>> updated commit message >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Can I push that fix for pylint? >>> Sure, ACK. >> Pushed to master: aa4123d852d81b908cd18208577bb509fff08c5b >> >> >>>> I found something suspicious in tests, did anything in IPA messages >>>> change? I suspect that this is related to client_patches. >>> Yes, 'data' is a dict which contains structured message data. I did not see >>> these specific failures before, though. Just add it to expected results >>> where missing. >>> >>>> E AssertionError: assert_deepequal: dict keys mismatch. >>>> E 0026: permission_find: Search for u'testperm' with a >>>> limit of 1 (truncated) with members >>>> E missing keys = [] >>>> E extra keys = [u'data'] >>>> E expected = {'message': u'Search result has been >>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>> u'warning', 'name': u'SearchResultTruncated'} >>>> E got = {u'data': {u'reason': u'Configured size limit >>>> exceeded'}, u'message': u'Search result has been truncated: Configured >>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>> u'SearchResultTruncated'} >>>> E path = ('messages', 0) >>>> >>>> >>>> >>>> E AssertionError: assert_deepequal: dict keys mismatch. >>>> E 0024: permission_find: Search for u'testperm' with a >>>> limit of 1 (truncated) with members >>>> E missing keys = [] >>>> E extra keys = [u'data'] >>>> E expected = {'message': u'Search result has been >>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>> u'warning', 'name': u'SearchResultTruncated'} >>>> E got = {u'data': {u'reason': u'Configured size limit >>>> exceeded'}, u'message': u'Search result has been truncated: Configured >>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>> u'SearchResultTruncated'} >>>> E path = ('messages', 0) > > It is even worse that tests. > > If I call command 'ipa' or 'ipa help' it blows up. I'm attaching debug log > from 'ipa -d' invocation. > > > Hi Honza, I installed FreeIPA from rpms built from the current master branch and after restarting httpd service I got Internal Server Error in WebUI. I guess that it has something in common with Thin Client, so the stack trace from /var/log/httpd/error_log is in attached file. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd.log Type: text/x-log Size: 5135 bytes Desc: not available URL: From rharwood at redhat.com Sat May 28 19:13:02 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Sat, 28 May 2016 15:13:02 -0400 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf In-Reply-To: <20160528042451.lewcj5jnicq2noxd@redhat.com> References: <20160528042451.lewcj5jnicq2noxd@redhat.com> Message-ID: Alexander Bokovoy writes: > On Fri, 27 May 2016, Robbie Harwood wrote: >>Stanislav Laznicka writes: >> >>> From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001 >>> From: Stanislav Laznicka >>> Date: Fri, 27 May 2016 16:12:31 +0200 >>> Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf >>> >>> The include of /etc/krb5.conf.d/ is required for crypto-policies to work properly >>> >>> https://fedorahosted.org/freeipa/ticket/5912 >> >> Thank you for working on this. Is the intent on the part of FreeIPA to >> keep a separate, freeipa-speicifc directory? And if so, can I suggest >> that we not do that? > > Which directory are you talking about? /var/lib/sss/pubconf/krb5.include.d/? Yes, this one. > SSSD cannot write to /etc and I don't think we have to change it. Can you elaborate on this? Why can't sssd write the stuff it puts in /var/lib into /etc, or symlink it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From abokovoy at redhat.com Sat May 28 20:38:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 28 May 2016 23:38:55 +0300 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf In-Reply-To: References: <20160528042451.lewcj5jnicq2noxd@redhat.com> Message-ID: <20160528203855.yoyipbmpkej2pxkc@redhat.com> On Sat, 28 May 2016, Robbie Harwood wrote: >Alexander Bokovoy writes: > >> On Fri, 27 May 2016, Robbie Harwood wrote: >>>Stanislav Laznicka writes: >>> >>>> From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001 >>>> From: Stanislav Laznicka >>>> Date: Fri, 27 May 2016 16:12:31 +0200 >>>> Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf >>>> >>>> The include of /etc/krb5.conf.d/ is required for crypto-policies to work properly >>>> >>>> https://fedorahosted.org/freeipa/ticket/5912 >>> >>> Thank you for working on this. Is the intent on the part of FreeIPA to >>> keep a separate, freeipa-speicifc directory? And if so, can I suggest >>> that we not do that? >> >> Which directory are you talking about? /var/lib/sss/pubconf/krb5.include.d/? > >Yes, this one. > >> SSSD cannot write to /etc and I don't think we have to change it. > >Can you elaborate on this? Why can't sssd write the stuff it puts in >/var/lib into /etc, or symlink it? Writing to /etc is considered a privilege of a system administrator. A runtime override is typically done outside it, in /run like systemd allows for its configuration for volatile setups and in /var/lib for non-volatile ones. The latter has long been a state of affairs in Linux. Currently SSSD runs under root but it is already made possible to run as non-root user and we intend to switch to that mode in future releases. -- / Alexander Bokovoy From mbasti at redhat.com Sun May 29 12:07:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Sun, 29 May 2016 14:07:45 +0200 Subject: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once In-Reply-To: <1464363234.3425.8.camel@redhat.com> References: <1464100171.2783.13.camel@redhat.com> <7688a67b-55d0-e64b-f1bd-dab0e450cb00@redhat.com> <1464102105.2783.16.camel@redhat.com> <1464107138.2783.28.camel@redhat.com> <1464363234.3425.8.camel@redhat.com> Message-ID: <50ae52e1-0568-4834-a181-e08b56ee45e3@redhat.com> On 27.05.2016 17:33, Nathaniel McCallum wrote: > On Tue, 2016-05-24 at 12:25 -0400, Nathaniel McCallum wrote: >> On Tue, 2016-05-24 at 11:01 -0400, Nathaniel McCallum wrote: >>> On Tue, 2016-05-24 at 16:55 +0200, Martin Kosek wrote: >>>> On 05/24/2016 04:29 PM, Nathaniel McCallum wrote: >>>>> Using a pragma instead of guards is easier to write, less error >>>>> prone >>>>> and avoids name clashes (a source of very subtle bugs). This >>>>> pragma >>>>> is supported on almost all compilers, including all the >>>>> compilers >>>>> we >>>>> care about: https://en.wikipedia.org/wiki/Pragma_once#Portabili >>>>> ty >>>>> . >>>>> >>>>> >>>>> >>>> Makes sense to me. I did not test, just saw a potential >>>> typo/omission: >>>> >>>> --- a/daemons/ipa-otpd/internal.h >>>> +++ b/daemons/ipa-otpd/internal.h >>>> @@ -20,9 +20,6 @@ >>>> * along with this program. If not, see >>> en >>>> se >>>> s/>. >>>> */ >>>> >>>> -#ifndef INTERNAL_H_ >>>> -#define INTERNAL_H_ >>>> - >>>> >>>> >>>> ... no pragma there. >>> Fixed. >> Here is a new version with a slightly edited commit message (just to >> confirm that we don't edit the autogenerated files). > Attached is a new version that is simply rebased on to master. > > ACK ** Pushed to master: 4bafba06f2b8cc51cd95a725e1c8adf7bbf9a5fc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sun May 29 12:17:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Sun, 29 May 2016 14:17:52 +0200 Subject: [Freeipa-devel] [PATCH 0034] Added some attributes to the Modify Users permission In-Reply-To: <08bcd7de-e32e-49ce-b8a3-2b2c3969805a@redhat.com> References: <08bcd7de-e32e-49ce-b8a3-2b2c3969805a@redhat.com> Message-ID: <1a8061d6-ddc8-62c8-48c0-509001361e69@redhat.com> On 27.05.2016 13:42, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/5911 > > > ACK Pushed to master: 1ce63e6193701679f539f7c83ddee9f65056b806 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sun May 29 12:45:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Sun, 29 May 2016 14:45:34 +0200 Subject: [Freeipa-devel] [PATCH 0123-132] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> Message-ID: On 27.05.2016 14:12, Petr Spacek wrote: > On 25.5.2016 12:50, Martin Basti wrote: >> >> On 20.05.2016 12:19, Petr Spacek wrote: >>> On 11.5.2016 12:08, Martin Basti wrote: >>>> On 03.05.2016 14:59, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> DNS upgrade: change forwarding policy to "only" if private IPs are used. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>> >>>>> This is the upgrade part. I will add one more patch to print a warning in >>>>> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >>>>> yet. >>>>> >>>>> >>>>> >>>> 1) >>>> Upgrade failed with 'BindInstance' object has no attribute >>>> 'named_conf_get_directive' >>>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command >>>> ipa-server-upgrade manually. >>>> ('IPA upgrade failed.', 1) >>>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more >>>> information >>>> >>>> 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no >>>> attribute 'named_conf_get_directive' >>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >>>> 213, in __upgrade >>>> self.modified = (ld.update(self.files) or self.modified) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>> line 917, in update >>>> self._run_updates(all_updates) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>> line 889, in _run_updates >>>> self._run_update_plugin(update['plugin']) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>> line 862, in _run_update_plugin >>>> restart_ds, updates = self.api.Updater[plugin_name]() >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1418, in >>>> __call__ >>>> return self.execute(**options) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>> line 547, in execute >>>> self.update_global_named_conf_forwarder(bind) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>> line 508, in update_global_named_conf_forwarder >>>> if bind.named_conf_get_directive( >>>> AttributeError: 'BindInstance' object has no attribute >>>> 'named_conf_get_directive' >>>> >>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 447, in start_creation >>>> run_step(full_msg, method) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>>> 437, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line >>>> 221, in __upgrade >>>> raise RuntimeError(e) >>>> RuntimeError: 'BindInstance' object has no attribute >>>> 'named_conf_get_directive' >>>> >>>> PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new >>>> attribute * >>>> 2) >>>> + Int('ipadnsversion?', >>>> + label=_('IPA DNS version'), >>>> + ), >>>> >>>> Shouldn't be this part of System: Read DNS Configuration permission? >>>> >>>> 3) >>>> - def postprocess_result(self, result): >>>> + def postprocess_result(self, result, show_version): >>>> if not any(param in result['result'] for param in self.params): >>>> result['summary'] = unicode(_('Global DNS configuration is >>>> empty')) >>>> >>>> show_version param was added but I don't see it used in this patch. >>>> >>>> 4) >>>> + Int('ipadnsversion?', >>>> + label=_('IPA DNS version'), >>>> + ), >>>> >>>> Could we add comment here that this option is accessible only from installers >>>> and upgrade? >>>> >>>> 5) >>>> + for config_option in container_entry.get("ipaConfigString", []): >>>> + matched = re.match("^DNSVersion\s+(?P\d+)$", >>>> + config_option, flags=re.I) >>>> + if matched: >>>> + version = int(matched.group("version")) >>>> >>>> Shouldn't we print error if version cannot be parsed? >>>> >>>> PATCH * DNS upgrade: separate backup logic to make it reusable * >>>> >>>> LGTM >>>> >>>> PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * >>>> >>>> 7) >>>> I'm curious why do you need to check superdomains? >>>> >>>> PATCH * DNS upgrade: change forwarding policy to = only for conflicting >>>> forward zones* >>>> >>>> 8) >>>> + self.log.debug('Zone %s was sucessfully modified to use ' >>>> + 'forward policy "only"', zone['idnsname'][0]) >>>> <---missing empty line----> >>>> + def execute(self, **options): >>>> >>>> PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if >>>> private IPs are used * >>>> 9) >>>> - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) >>>> + dnsutil.related_to_auto_empty_zone( >>>> + dnsutil.DNSName(zone.get('idnsname')[0])) >>>> >>>> Should be in previous commit >>>> >>>> 10) >>>> - return >>>> + return False, [] >>>> This should be fixed in the previous commit >>>> >>>> PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" >>>> if private IPs are used * >>>> 11) >>>> IMO this is an upgrade of configuration and this should be in >>>> ipaserver/install/server/upgrade.py, upgrade plugins are used only for >>>> updating of LDAP values >>>> >>>> Unless you really want to use this as precedence, but then it requires broader >>>> discussion. >>>> >>>> 12) >>>> >>>> bind.named_conf_get_directive >>>> should be >>>> bindinstance.named_conf_get_directive >>>> >>>> see 1) >>> This new patchset completely obsoletes the old one. I had to reshuffle few >>> things to to make the split between server config & LDAP upgrade possible. >>> >>> Hopefully I addressed all your comment. >>> >> commits >> * Move IP address resolution from ipaserver.install.installutils to >> ipapython.dnsutil * and * Turn verify_host_resolvable() into a wrapper around >> ipapython.dnsutil * >> >> cause regression in case that dns.python resolver returns NoNameservers >> exception, it is handled as 'Internal server error' >> >> In original code every exception was caught and transformed to >> DNSNotARecordError. >> >> So we have following options: >> * keep the old behavior in 'resolve_rrsets' and catch all exceptions there >> * or catch all DNS errors in 'verify_host_resolvable' and raise it as new >> PublicError (DNSGenericError (doesn't exist) for example) >> >> >> E InternalError: an internal error has occurred >> >> ../ipalib/rpc.py:1100: InternalError >> test_forwardzone_delegation_warnings.test_command[0017: dnsrecord_mod: Delete >> (using dnsrecord-mod) NS record which delegates zone >> u'fw.sub2.sub.dnszone.test.' from zone u'dnszone.test' (expected warning for >> u'fw.sub2.sub.dnszone.test.')] >> >> [Wed May 25 12:17:00.172143 2016] [wsgi:error] [pid 62789] Traceback (most >> recent call last): >> [Wed May 25 12:17:00.172152 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in >> wsgi_execute >> [Wed May 25 12:17:00.172158 2016] [wsgi:error] [pid 62789] result = >> self.Command[name](*args, **options) >> [Wed May 25 12:17:00.172164 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 434, in __call__ >> [Wed May 25 12:17:00.172168 2016] [wsgi:error] [pid 62789] return >> self.__do_call(*args, **options) >> [Wed May 25 12:17:00.172173 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 460, in __do_call >> [Wed May 25 12:17:00.172178 2016] [wsgi:error] [pid 62789] ret = >> self.run(*args, **options) >> [Wed May 25 12:17:00.172183 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 777, in run >> [Wed May 25 12:17:00.172189 2016] [wsgi:error] [pid 62789] return >> self.execute(*args, **options) >> [Wed May 25 12:17:00.172194 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3774, in execute >> [Wed May 25 12:17:00.172199 2016] [wsgi:error] [pid 62789] result = >> super(dnsrecord_add, self).execute(*keys, **options) >> [Wed May 25 12:17:00.172204 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1230, in >> execute >> [Wed May 25 12:17:00.172209 2016] [wsgi:error] [pid 62789] *keys, **options) >> [Wed May 25 12:17:00.172213 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3719, in >> pre_callback >> [Wed May 25 12:17:00.172229 2016] [wsgi:error] [pid 62789] >> self.obj.run_precallback_validators(dn, entry_attrs, *keys, **options) >> [Wed May 25 12:17:00.172237 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3135, in >> run_precallback_validators >> [Wed May 25 12:17:00.172242 2016] [wsgi:error] [pid 62789] rtype_cb(ldap, dn, >> entry_attrs, *keys, **options) >> [Wed May 25 12:17:00.172247 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3057, in >> _nsrecord_pre_callback >> [Wed May 25 12:17:00.172252 2016] [wsgi:error] [pid 62789] >> check_ns_rec_resolvable(keys[0], DNSName(nsrecord), self.log) >> [Wed May 25 12:17:00.172256 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1577, in >> check_ns_rec_resolvable >> [Wed May 25 12:17:00.172261 2016] [wsgi:error] [pid 62789] >> verify_host_resolvable(name) >> [Wed May 25 12:17:00.172265 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipalib/util.py", line 70, in >> verify_host_resolvable >> [Wed May 25 12:17:00.172270 2016] [wsgi:error] [pid 62789] if not >> resolve_ip_addresses(fqdn): >> [Wed May 25 12:17:00.172274 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 328, in >> resolve_ip_addresses >> [Wed May 25 12:17:00.172278 2016] [wsgi:error] [pid 62789] rrsets = >> resolve_rrsets(fqdn, ['A', 'AAAA']) >> [Wed May 25 12:17:00.172282 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 305, in >> resolve_rrsets >> [Wed May 25 12:17:00.172287 2016] [wsgi:error] [pid 62789] answer = >> dns.resolver.query(fqdn, rdtype) >> [Wed May 25 12:17:00.172292 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 1029, in query >> [Wed May 25 12:17:00.172296 2016] [wsgi:error] [pid 62789] raise_on_no_answer, >> source_port) >> [Wed May 25 12:17:00.172301 2016] [wsgi:error] [pid 62789] File >> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 856, in query >> [Wed May 25 12:17:00.172328 2016] [wsgi:error] [pid 62789] raise >> NoNameservers(request=request, errors=errors) > > Fixed patches are attached. > > > Please note that I've renumbered the patches because the naming does not match > the original set anymore. > NACK # ipa-run-tests test_xmlrpc/test_host_plugin.py =============================================================================================== test session starts =============================================================================================== platform linux2 -- Python 2.7.11, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: sourceorder-0.5, multihost-1.0 collected 41 items test_xmlrpc/test_host_plugin.py ...................F...........s......... ==================================================================================================== FAILURES ===================================================================================================== ________________________________________________________________________________________ TestCRUD.test_try_add_not_in_dns _________________________________________________________________________________________ self = , host = def test_try_add_not_in_dns(self, host): host.ensure_missing() command = host.make_create_command(force=False) with raises_exact(errors.DNSNotARecordError( > reason=u'Host does not have corresponding DNS A/AAAA record')): test_xmlrpc/test_host_plugin.py:315: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../ipalib/errors.py:264: in __init__ messages.process_message_arguments(self, format, message, **kw) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ obj = DNSNotARecordError(), format = None, message = None, kw = {'reason': 'Host does not have corresponding DNS A/AAAA record'}, key = 'reason', value = 'Host does not have corresponding DNS A/AAAA record' name = 'DNSNotARecordError' def process_message_arguments(obj, format=None, message=None, **kw): for key, value in kw.items(): if not isinstance(value, six.integer_types): try: kw[key] = unicode(value) except UnicodeError: pass obj.kw = kw name = obj.__class__.__name__ if obj.format is not None and format is not None: raise ValueError( 'non-generic %r needs format=None; got format=%r' % ( name, format) ) if message is None: if obj.format is None: if format is None: raise ValueError( '%s.format is None yet format=None, message=None' % name ) obj.format = format obj.forwarded = False > obj.msg = obj.format % kw E KeyError: 'hostname' From jcholast at redhat.com Mon May 30 06:28:40 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 May 2016 08:28:40 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <97013cc1-6a16-0c26-1ae6-882d96ff6918@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> <20c19eb5-80f4-3143-9a9b-f0f508e46fad@redhat.com> <97013cc1-6a16-0c26-1ae6-882d96ff6918@redhat.com> Message-ID: On 28.5.2016 18:33, Pavel Vomacka wrote: > > > On 05/27/2016 10:33 AM, Petr Spacek wrote: >> On 27.5.2016 09:26, Martin Basti wrote: >>> >>> On 27.05.2016 07:49, Jan Cholasta wrote: >>>> On 26.5.2016 18:43, Martin Basti wrote: >>>>> >>>>> On 26.05.2016 11:21, Martin Basti wrote: >>>>>> >>>>>> On 26.05.2016 07:15, Jan Cholasta wrote: >>>>>>> On 25.5.2016 18:17, Martin Basti wrote: >>>>>>>> >>>>>>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>>>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All commits up to "ipalib: use relative imports for cross-plugin >>>>>>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>>>>>> change >>>>>>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Honza >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>>>>>> >>>>>>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>>>>>> LDAPQuery * >>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>> >>>>>>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>>>>>> class * >>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>> >>>>>>>>>>>>>> * dns: do not rely on server data structures in code called on >>>>>>>>>>>>>> client * >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>>> This was deliberate, as it will no longer be necessary to bump >>>>>>>>>>>>> VERSION >>>>>>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>>>>>> merged. >>>>>>>>>>>>> But we're not there yet, so fixed. >>>>>>>>>>>>> >>>>>>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>>> >>>>>>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>>>>>> ACK >>>>>>>>>>>>>> >>>>>>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>>> Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> Did you find out why this was issue? >>>>>>>>>>>>>> - del answer['value'] # Why does this cause an error if >>>>>>>>>>>>>> omitted? >>>>>>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>>>>>> error if >>>>>>>>>>>>>> omitted? >>>>>>>>>>>>> The command definition was not complete, it was missing >>>>>>>>>>>>> has_output. >>>>>>>>>>>>> >>>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>>> >>>>>>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>> >>>>>>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>>>>>> counterparts * >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> you forgot to increment Version >>>>>>>>>>>>> Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>>>>>> 1) Missing explanation for future generations why this change is >>>>>>>>>>>>>> needed >>>>>>>>>>>>>> in commit message >>>>>>>>>>>>> Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>>> The other commits I will check later. >>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>> >>>>>>>>>>>>> Okay. Thanks. >>>>>>>>>>>>> >>>>>>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * frontend: perform argument value validation only on server >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>>>>>> I'm not a fan of returning None in promt_param function, but I >>>>>>>>>>>> havent >>>>>>>>>>>> found anything better to use. >>>>>>>>>>> It always returned None for unset params. >>>>>>>>>>> >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * ipalib: optimize API.txt >>>>>>>>>>>> this contains a lot of black magic, but because this is mainly >>>>>>>>>>>> copy of >>>>>>>>>>>> current to proper places, LGTM >>>>>>>>>>> It's actually mostly cut-n-paste. >>>>>>>>>>> >>>>>>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>>>>>> The next change would be impossible without this. >>>>>>>>>>> >>>>>>>>>>>> * plugable: replace API.import_plugins with new API.add_package >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>>>>>> registration >>>>>>>>>>>> ACK >>>>>>>>>>>> >>>>>>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in docstrings >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> *frontend: move the interactive_prompt callback type to Command >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> Martin^2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is ready >>>>>>>>>> to be >>>>>>>>>> pushed into master. >>>>>>>>>> All upto "frontend: allow commands to have an argument named >>>>>>>>>> `name`" got >>>>>>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>>>>>> expected >>>>>>>>>> now, ACK. >>>>>>>>> Thanks for the review. >>>>>>>>> >>>>>>>>>> Honzo, please rebase and push them, thanks! >>>>>>>>>> >>>>>>>>> Attaching the patches for reference. >>>>>>>>> >>>>>>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>>>>>> >>>>>>>> Guys, you forgot to test it with newer pylint. >>>>>>> I don't see any "BuildRequires: newer pylint" in the spec file. >>>>>>> >>>>>>>> Patch attached. >>>>>>> LGTM, although the commit message is wrong - this is not related to >>>>>>> thin client at all, PublicError and PublicMessage had .kw since forever. >>>>>>> >>>>>> updated commit message >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Can I push that fix for pylint? >>>> Sure, ACK. >>> Pushed to master: aa4123d852d81b908cd18208577bb509fff08c5b >>> >>> >>>>> I found something suspicious in tests, did anything in IPA messages >>>>> change? I suspect that this is related to client_patches. >>>> Yes, 'data' is a dict which contains structured message data. I did not see >>>> these specific failures before, though. Just add it to expected results >>>> where missing. >>>> >>>>> E AssertionError: assert_deepequal: dict keys mismatch. >>>>> E 0026: permission_find: Search for u'testperm' with a >>>>> limit of 1 (truncated) with members >>>>> E missing keys = [] >>>>> E extra keys = [u'data'] >>>>> E expected = {'message': u'Search result has been >>>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>>> u'warning', 'name': u'SearchResultTruncated'} >>>>> E got = {u'data': {u'reason': u'Configured size limit >>>>> exceeded'}, u'message': u'Search result has been truncated: Configured >>>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>>> u'SearchResultTruncated'} >>>>> E path = ('messages', 0) >>>>> >>>>> >>>>> >>>>> E AssertionError: assert_deepequal: dict keys mismatch. >>>>> E 0024: permission_find: Search for u'testperm' with a >>>>> limit of 1 (truncated) with members >>>>> E missing keys = [] >>>>> E extra keys = [u'data'] >>>>> E expected = {'message': u'Search result has been >>>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>>> u'warning', 'name': u'SearchResultTruncated'} >>>>> E got = {u'data': {u'reason': u'Configured size limit >>>>> exceeded'}, u'message': u'Search result has been truncated: Configured >>>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>>> u'SearchResultTruncated'} >>>>> E path = ('messages', 0) >> >> It is even worse that tests. >> >> If I call command 'ipa' or 'ipa help' it blows up. I'm attaching debug log >> from 'ipa -d' invocation. Oops, I forgot about commands defined in ipalib.cli in commit 71f9604. Will fix. >> >> >> > Hi Honza, > > I installed FreeIPA from rpms built from the current master branch and > after restarting httpd service I got Internal Server Error in WebUI. I > guess that it has something in common with Thin Client, so the stack > trace from /var/log/httpd/error_log is in attached file. This is weird, json_metadata.execute does *not* take exactly 3 arguments: def execute(self, objname=None, methodname=None, **options): Have you upgraded your server properly? -- Jan Cholasta From pvomacka at redhat.com Mon May 30 07:48:14 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 30 May 2016 09:48:14 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> <433047ff-0677-1606-c16c-0960cffbdc2b@redhat.com> <9f84d44c-cca0-fc87-d8ff-8e502ab702b8@redhat.com> <5923e78f-48f5-9202-f9af-049bde6442f6@redhat.com> <95c87b9c-b379-a983-9b34-07ff5af59614@redhat.com> <5941537b-e853-0a3c-0a97-4b8ff04c5f0f@redhat.com> <178aee57-1f51-3370-3e3b-f85c5aea72d1@redhat.com> <20c19eb5-80f4-3143-9a9b-f0f508e46fad@redhat.com> <97013cc1-6a16-0c26-1ae6-882d96ff6918@redhat.com> Message-ID: On 05/30/2016 08:28 AM, Jan Cholasta wrote: > On 28.5.2016 18:33, Pavel Vomacka wrote: >> >> >> On 05/27/2016 10:33 AM, Petr Spacek wrote: >>> On 27.5.2016 09:26, Martin Basti wrote: >>>> >>>> On 27.05.2016 07:49, Jan Cholasta wrote: >>>>> On 26.5.2016 18:43, Martin Basti wrote: >>>>>> >>>>>> On 26.05.2016 11:21, Martin Basti wrote: >>>>>>> >>>>>>> On 26.05.2016 07:15, Jan Cholasta wrote: >>>>>>>> On 25.5.2016 18:17, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 25.05.2016 16:07, Jan Cholasta wrote: >>>>>>>>>> On 25.5.2016 15:03, David Kupka wrote: >>>>>>>>>>> On 18/05/16 08:01, Jan Cholasta wrote: >>>>>>>>>>>> On 16.5.2016 16:35, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 09.05.2016 14:07, Jan Cholasta wrote: >>>>>>>>>>>>>> On 6.5.2016 14:32, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 28.04.2016 14:45, Jan Cholasta wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have pushed my thin client WIP branch to GitHub: >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All commits up to "ipalib: use relative imports for >>>>>>>>>>>>>>>> cross-plugin >>>>>>>>>>>>>>>> imports" should be good for review. The rest is subject to >>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>> (WARNING: I will force push into this branch). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Honza >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I did not test it yet, I just checked the code >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * automount: do not inherit automountlocation_tofiles from >>>>>>>>>>>>>>> LDAPQuery * >>>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * dns: move all dnsrecord code called on client to a single >>>>>>>>>>>>>>> class * >>>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * dns: do not rely on server data structures in code >>>>>>>>>>>>>>> called on >>>>>>>>>>>>>>> client * >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>>>> This was deliberate, as it will no longer be necessary to >>>>>>>>>>>>>> bump >>>>>>>>>>>>>> VERSION >>>>>>>>>>>>>> for backward compatible changes after this whole patchset is >>>>>>>>>>>>>> merged. >>>>>>>>>>>>>> But we're not there yet, so fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>> How we should handle VERSION after your patches? >>>>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * otptoken: fix import of DN * >>>>>>>>>>>>>>> ACK >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * otptoken_yubikey: fix otptoken_add_yubikey arguments * >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> you forgot to increment VERSION >>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>> Did you find out why this was issue? >>>>>>>>>>>>>>> - del answer['value'] # Why does this cause an >>>>>>>>>>>>>>> error if >>>>>>>>>>>>>>> omitted? >>>>>>>>>>>>>>> - del answer['summary'] # Why does this cause an >>>>>>>>>>>>>>> error if >>>>>>>>>>>>>>> omitted? >>>>>>>>>>>>>> The command definition was not complete, it was missing >>>>>>>>>>>>>> has_output. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise LGTM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * vault: move client-side code to the module level * >>>>>>>>>>>>>>> LGTM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * vault: copy arguments of client commands from server >>>>>>>>>>>>>>> counterparts * >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> you forgot to increment Version >>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * ipalib: use relative imports for cross-plugin imports * >>>>>>>>>>>>>>> 1) Missing explanation for future generations why this >>>>>>>>>>>>>>> change is >>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>> in commit message >>>>>>>>>>>>>> Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The other commits I will check later. >>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay. Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>> * frontend: remove the unused Command.soft_validate method >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * frontend: perform argument value validation only on server >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * frontend: do not forward argument defaults to server >>>>>>>>>>>>> I'm not a fan of returning None in promt_param function, >>>>>>>>>>>>> but I >>>>>>>>>>>>> havent >>>>>>>>>>>>> found anything better to use. >>>>>>>>>>>> It always returned None for unset params. >>>>>>>>>>>> >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * ipalib: optimize API.txt >>>>>>>>>>>>> this contains a lot of black magic, but because this is >>>>>>>>>>>>> mainly >>>>>>>>>>>>> copy of >>>>>>>>>>>>> current to proper places, LGTM >>>>>>>>>>>> It's actually mostly cut-n-paste. >>>>>>>>>>>> >>>>>>>>>>>>> * makeaci: load additional plugins using API.add_module >>>>>>>>>>>>> Looks good, but I miss explanation why is this change needed >>>>>>>>>>>> The next change would be impossible without this. >>>>>>>>>>>> >>>>>>>>>>>>> * plugable: replace API.import_plugins with new >>>>>>>>>>>>> API.add_package >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * ipalib, ipaserver: migrate all plugins to Registry-based >>>>>>>>>>>>> registration >>>>>>>>>>>>> ACK >>>>>>>>>>>>> >>>>>>>>>>>>> * ipalib, ipaserver: fix incorrect API.register calls in >>>>>>>>>>>>> docstrings >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * plugable: remove the unused deprecated API.register method >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * plugable: switch API to Registry-based plugin discovery >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> * frontend: merge baseldap.CallbackRegistry into Command >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> *frontend: move the interactive_prompt callback type to >>>>>>>>>>>>> Command >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> first batch of 30 patches from Honza's trac-4739 branch >>>>>>>>>>> (https://github.com/jcholast/freeipa/commits/trac-4739) is >>>>>>>>>>> ready >>>>>>>>>>> to be >>>>>>>>>>> pushed into master. >>>>>>>>>>> All upto "frontend: allow commands to have an argument named >>>>>>>>>>> `name`" got >>>>>>>>>>> over numerous test&fix cycles in last week+ and is working as >>>>>>>>>>> expected >>>>>>>>>>> now, ACK. >>>>>>>>>> Thanks for the review. >>>>>>>>>> >>>>>>>>>>> Honzo, please rebase and push them, thanks! >>>>>>>>>>> >>>>>>>>>> Attaching the patches for reference. >>>>>>>>>> >>>>>>>>>> Pushed to master: 2b50fc617024f18a81e97f30f75ed1b9221c4055 >>>>>>>>>> >>>>>>>>> Guys, you forgot to test it with newer pylint. >>>>>>>> I don't see any "BuildRequires: newer pylint" in the spec file. >>>>>>>> >>>>>>>>> Patch attached. >>>>>>>> LGTM, although the commit message is wrong - this is not >>>>>>>> related to >>>>>>>> thin client at all, PublicError and PublicMessage had .kw since >>>>>>>> forever. >>>>>>>> >>>>>>> updated commit message >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Can I push that fix for pylint? >>>>> Sure, ACK. >>>> Pushed to master: aa4123d852d81b908cd18208577bb509fff08c5b >>>> >>>> >>>>>> I found something suspicious in tests, did anything in IPA messages >>>>>> change? I suspect that this is related to client_patches. >>>>> Yes, 'data' is a dict which contains structured message data. I >>>>> did not see >>>>> these specific failures before, though. Just add it to expected >>>>> results >>>>> where missing. >>>>> >>>>>> E AssertionError: assert_deepequal: dict keys >>>>>> mismatch. >>>>>> E 0026: permission_find: Search for u'testperm' >>>>>> with a >>>>>> limit of 1 (truncated) with members >>>>>> E missing keys = [] >>>>>> E extra keys = [u'data'] >>>>>> E expected = {'message': u'Search result has been >>>>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>>>> u'warning', 'name': u'SearchResultTruncated'} >>>>>> E got = {u'data': {u'reason': u'Configured size >>>>>> limit >>>>>> exceeded'}, u'message': u'Search result has been truncated: >>>>>> Configured >>>>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>>>> u'SearchResultTruncated'} >>>>>> E path = ('messages', 0) >>>>>> >>>>>> >>>>>> >>>>>> E AssertionError: assert_deepequal: dict keys >>>>>> mismatch. >>>>>> E 0024: permission_find: Search for u'testperm' >>>>>> with a >>>>>> limit of 1 (truncated) with members >>>>>> E missing keys = [] >>>>>> E extra keys = [u'data'] >>>>>> E expected = {'message': u'Search result has been >>>>>> truncated: Configured size limit exceeded', 'code': 13017, 'type': >>>>>> u'warning', 'name': u'SearchResultTruncated'} >>>>>> E got = {u'data': {u'reason': u'Configured size >>>>>> limit >>>>>> exceeded'}, u'message': u'Search result has been truncated: >>>>>> Configured >>>>>> size limit exceeded', u'code': 13017, u'type': u'warning', u'name': >>>>>> u'SearchResultTruncated'} >>>>>> E path = ('messages', 0) >>> >>> It is even worse that tests. >>> >>> If I call command 'ipa' or 'ipa help' it blows up. I'm attaching >>> debug log >>> from 'ipa -d' invocation. > > Oops, I forgot about commands defined in ipalib.cli in commit 71f9604. > > Will fix. > >>> >>> >>> >> Hi Honza, >> >> I installed FreeIPA from rpms built from the current master branch and >> after restarting httpd service I got Internal Server Error in WebUI. I >> guess that it has something in common with Thin Client, so the stack >> trace from /var/log/httpd/error_log is in attached file. > > This is weird, json_metadata.execute does *not* take exactly 3 arguments: > > def execute(self, objname=None, methodname=None, **options): > > Have you upgraded your server properly? > You are right I didn't have correct internal.py file on the server. Thank you for your help. From mbasti at redhat.com Mon May 30 09:00:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 May 2016 11:00:15 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Add the culprit line when a configuration file has an incorrect format In-Reply-To: References: Message-ID: <7c482bfd-c466-a2c9-ca29-bcd2a28163df@redhat.com> On 27.05.2016 11:35, Florence Blanc-Renaud wrote: > > Hi all, > > this patch adds information to the output of ipa-client-install when > it fails due to invalid format in a configuration file: > ipa-client-install failing with SyntaxError: Syntax Error: Unknown > line format > > Fixes: https://fedorahosted.org/freeipa/ticket/5811 > > -- > Florence Blanc-Renaud > Identity Management Team, Red Hat > > Thank you for your patch, I have just one nitpick. Can you please reuse the original exception? - curopts.append(self.parseLine(line)) + try: + curopts.append(self.parseLine(line)) + except SyntaxError as e: + raise SyntaxError('{error} in file {fname}: [{line}]'.format( + error=e, fname=f.name, line=line)) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon May 30 10:36:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 May 2016 12:36:51 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: References: Message-ID: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> On 26.05.2016 19:31, Stanislav Laznicka wrote: > > Self NACK. I should not post patches when tired, sorry. Minor fix is > attached. > > > On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: >> Hello, >> >> Please, see the attached patch. Fixes >> https://fedorahosted.org/freeipa/ticket/5898 >> >> Standa >> >> >> > > > LGTM, if nobody is against this, I will push it in 2 days -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon May 30 10:49:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 30 May 2016 12:49:51 +0200 Subject: [Freeipa-devel] [PATCH 0123-132] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> Message-ID: On 29.5.2016 14:45, Martin Basti wrote: > > > On 27.05.2016 14:12, Petr Spacek wrote: >> On 25.5.2016 12:50, Martin Basti wrote: >>> >>> On 20.05.2016 12:19, Petr Spacek wrote: >>>> On 11.5.2016 12:08, Martin Basti wrote: >>>>> On 03.05.2016 14:59, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> DNS upgrade: change forwarding policy to "only" if private IPs are used. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>> >>>>>> This is the upgrade part. I will add one more patch to print a warning in >>>>>> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >>>>>> yet. >>>>>> >>>>>> >>>>>> >>>>> 1) >>>>> Upgrade failed with 'BindInstance' object has no attribute >>>>> 'named_conf_get_directive' >>>>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command >>>>> ipa-server-upgrade manually. >>>>> ('IPA upgrade failed.', 1) >>>>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more >>>>> information >>>>> >>>>> 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no >>>>> attribute 'named_conf_get_directive' >>>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>> line >>>>> 213, in __upgrade >>>>> self.modified = (ld.update(self.files) or self.modified) >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>> line 917, in update >>>>> self._run_updates(all_updates) >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>> line 889, in _run_updates >>>>> self._run_update_plugin(update['plugin']) >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>> line 862, in _run_update_plugin >>>>> restart_ds, updates = self.api.Updater[plugin_name]() >>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>> 1418, in >>>>> __call__ >>>>> return self.execute(**options) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>>> line 547, in execute >>>>> self.update_global_named_conf_forwarder(bind) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>>> line 508, in update_global_named_conf_forwarder >>>>> if bind.named_conf_get_directive( >>>>> AttributeError: 'BindInstance' object has no attribute >>>>> 'named_conf_get_directive' >>>>> >>>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line >>>>> 447, in start_creation >>>>> run_step(full_msg, method) >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line >>>>> 437, in run_step >>>>> method() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>> line >>>>> 221, in __upgrade >>>>> raise RuntimeError(e) >>>>> RuntimeError: 'BindInstance' object has no attribute >>>>> 'named_conf_get_directive' >>>>> >>>>> PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new >>>>> attribute * >>>>> 2) >>>>> + Int('ipadnsversion?', >>>>> + label=_('IPA DNS version'), >>>>> + ), >>>>> >>>>> Shouldn't be this part of System: Read DNS Configuration permission? >>>>> >>>>> 3) >>>>> - def postprocess_result(self, result): >>>>> + def postprocess_result(self, result, show_version): >>>>> if not any(param in result['result'] for param in self.params): >>>>> result['summary'] = unicode(_('Global DNS configuration is >>>>> empty')) >>>>> >>>>> show_version param was added but I don't see it used in this patch. >>>>> >>>>> 4) >>>>> + Int('ipadnsversion?', >>>>> + label=_('IPA DNS version'), >>>>> + ), >>>>> >>>>> Could we add comment here that this option is accessible only from >>>>> installers >>>>> and upgrade? >>>>> >>>>> 5) >>>>> + for config_option in container_entry.get("ipaConfigString", []): >>>>> + matched = re.match("^DNSVersion\s+(?P\d+)$", >>>>> + config_option, flags=re.I) >>>>> + if matched: >>>>> + version = int(matched.group("version")) >>>>> >>>>> Shouldn't we print error if version cannot be parsed? >>>>> >>>>> PATCH * DNS upgrade: separate backup logic to make it reusable * >>>>> >>>>> LGTM >>>>> >>>>> PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * >>>>> >>>>> 7) >>>>> I'm curious why do you need to check superdomains? >>>>> >>>>> PATCH * DNS upgrade: change forwarding policy to = only for conflicting >>>>> forward zones* >>>>> >>>>> 8) >>>>> + self.log.debug('Zone %s was sucessfully modified to use ' >>>>> + 'forward policy "only"', zone['idnsname'][0]) >>>>> <---missing empty line----> >>>>> + def execute(self, **options): >>>>> >>>>> PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if >>>>> private IPs are used * >>>>> 9) >>>>> - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) >>>>> + dnsutil.related_to_auto_empty_zone( >>>>> + dnsutil.DNSName(zone.get('idnsname')[0])) >>>>> >>>>> Should be in previous commit >>>>> >>>>> 10) >>>>> - return >>>>> + return False, [] >>>>> This should be fixed in the previous commit >>>>> >>>>> PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" >>>>> if private IPs are used * >>>>> 11) >>>>> IMO this is an upgrade of configuration and this should be in >>>>> ipaserver/install/server/upgrade.py, upgrade plugins are used only for >>>>> updating of LDAP values >>>>> >>>>> Unless you really want to use this as precedence, but then it requires >>>>> broader >>>>> discussion. >>>>> >>>>> 12) >>>>> >>>>> bind.named_conf_get_directive >>>>> should be >>>>> bindinstance.named_conf_get_directive >>>>> >>>>> see 1) >>>> This new patchset completely obsoletes the old one. I had to reshuffle few >>>> things to to make the split between server config & LDAP upgrade possible. >>>> >>>> Hopefully I addressed all your comment. >>>> >>> commits >>> * Move IP address resolution from ipaserver.install.installutils to >>> ipapython.dnsutil * and * Turn verify_host_resolvable() into a wrapper around >>> ipapython.dnsutil * >>> >>> cause regression in case that dns.python resolver returns NoNameservers >>> exception, it is handled as 'Internal server error' >>> >>> In original code every exception was caught and transformed to >>> DNSNotARecordError. >>> >>> So we have following options: >>> * keep the old behavior in 'resolve_rrsets' and catch all exceptions there >>> * or catch all DNS errors in 'verify_host_resolvable' and raise it as new >>> PublicError (DNSGenericError (doesn't exist) for example) >>> >>> >>> E InternalError: an internal error has occurred >>> >>> ../ipalib/rpc.py:1100: InternalError >>> test_forwardzone_delegation_warnings.test_command[0017: dnsrecord_mod: >>> Delete >>> (using dnsrecord-mod) NS record which delegates zone >>> u'fw.sub2.sub.dnszone.test.' from zone u'dnszone.test' (expected warning for >>> u'fw.sub2.sub.dnszone.test.')] >>> >>> [Wed May 25 12:17:00.172143 2016] [wsgi:error] [pid 62789] Traceback (most >>> recent call last): >>> [Wed May 25 12:17:00.172152 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in >>> wsgi_execute >>> [Wed May 25 12:17:00.172158 2016] [wsgi:error] [pid 62789] result = >>> self.Command[name](*args, **options) >>> [Wed May 25 12:17:00.172164 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 434, in __call__ >>> [Wed May 25 12:17:00.172168 2016] [wsgi:error] [pid 62789] return >>> self.__do_call(*args, **options) >>> [Wed May 25 12:17:00.172173 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 460, in __do_call >>> [Wed May 25 12:17:00.172178 2016] [wsgi:error] [pid 62789] ret = >>> self.run(*args, **options) >>> [Wed May 25 12:17:00.172183 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 777, in run >>> [Wed May 25 12:17:00.172189 2016] [wsgi:error] [pid 62789] return >>> self.execute(*args, **options) >>> [Wed May 25 12:17:00.172194 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3774, in >>> execute >>> [Wed May 25 12:17:00.172199 2016] [wsgi:error] [pid 62789] result = >>> super(dnsrecord_add, self).execute(*keys, **options) >>> [Wed May 25 12:17:00.172204 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1230, in >>> execute >>> [Wed May 25 12:17:00.172209 2016] [wsgi:error] [pid 62789] *keys, **options) >>> [Wed May 25 12:17:00.172213 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3719, in >>> pre_callback >>> [Wed May 25 12:17:00.172229 2016] [wsgi:error] [pid 62789] >>> self.obj.run_precallback_validators(dn, entry_attrs, *keys, **options) >>> [Wed May 25 12:17:00.172237 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3135, in >>> run_precallback_validators >>> [Wed May 25 12:17:00.172242 2016] [wsgi:error] [pid 62789] rtype_cb(ldap, dn, >>> entry_attrs, *keys, **options) >>> [Wed May 25 12:17:00.172247 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3057, in >>> _nsrecord_pre_callback >>> [Wed May 25 12:17:00.172252 2016] [wsgi:error] [pid 62789] >>> check_ns_rec_resolvable(keys[0], DNSName(nsrecord), self.log) >>> [Wed May 25 12:17:00.172256 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1577, in >>> check_ns_rec_resolvable >>> [Wed May 25 12:17:00.172261 2016] [wsgi:error] [pid 62789] >>> verify_host_resolvable(name) >>> [Wed May 25 12:17:00.172265 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipalib/util.py", line 70, in >>> verify_host_resolvable >>> [Wed May 25 12:17:00.172270 2016] [wsgi:error] [pid 62789] if not >>> resolve_ip_addresses(fqdn): >>> [Wed May 25 12:17:00.172274 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 328, in >>> resolve_ip_addresses >>> [Wed May 25 12:17:00.172278 2016] [wsgi:error] [pid 62789] rrsets = >>> resolve_rrsets(fqdn, ['A', 'AAAA']) >>> [Wed May 25 12:17:00.172282 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 305, in >>> resolve_rrsets >>> [Wed May 25 12:17:00.172287 2016] [wsgi:error] [pid 62789] answer = >>> dns.resolver.query(fqdn, rdtype) >>> [Wed May 25 12:17:00.172292 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 1029, in query >>> [Wed May 25 12:17:00.172296 2016] [wsgi:error] [pid 62789] raise_on_no_answer, >>> source_port) >>> [Wed May 25 12:17:00.172301 2016] [wsgi:error] [pid 62789] File >>> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 856, in query >>> [Wed May 25 12:17:00.172328 2016] [wsgi:error] [pid 62789] raise >>> NoNameservers(request=request, errors=errors) >> >> Fixed patches are attached. >> >> >> Please note that I've renumbered the patches because the naming does not match >> the original set anymore. >> > > NACK > > # ipa-run-tests test_xmlrpc/test_host_plugin.py > =============================================================================================== > test session starts > =============================================================================================== > > platform linux2 -- Python 2.7.11, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > plugins: sourceorder-0.5, multihost-1.0 > collected 41 items > > test_xmlrpc/test_host_plugin.py ...................F...........s......... > > ==================================================================================================== > FAILURES > ===================================================================================================== > > ________________________________________________________________________________________ > TestCRUD.test_try_add_not_in_dns > _________________________________________________________________________________________ > > > self = 0x7efc061e4110>, host = object at 0x7efc0623bb90> > > def test_try_add_not_in_dns(self, host): > host.ensure_missing() > command = host.make_create_command(force=False) > with raises_exact(errors.DNSNotARecordError( >> reason=u'Host does not have corresponding DNS A/AAAA record')): > > test_xmlrpc/test_host_plugin.py:315: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > ../ipalib/errors.py:264: in __init__ > messages.process_message_arguments(self, format, message, **kw) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > obj = DNSNotARecordError(), format = None, message = None, kw = {'reason': > 'Host does not have corresponding DNS A/AAAA record'}, key = 'reason', value = > 'Host does not have corresponding DNS A/AAAA record' > name = 'DNSNotARecordError' > > def process_message_arguments(obj, format=None, message=None, **kw): > for key, value in kw.items(): > if not isinstance(value, six.integer_types): > try: > kw[key] = unicode(value) > except UnicodeError: > pass > obj.kw = kw > name = obj.__class__.__name__ > if obj.format is not None and format is not None: > raise ValueError( > 'non-generic %r needs format=None; got format=%r' % ( > name, format) > ) > if message is None: > if obj.format is None: > if format is None: > raise ValueError( > '%s.format is None yet format=None, message=None' % name > ) > obj.format = format > obj.forwarded = False >> obj.msg = obj.format % kw > E KeyError: 'hostname' Sorry, this got lost in all the 'normal' failures :-) I do not 100% understand this test logic so I hope that attached patch fixes it correctly. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0123-2-Move-check_zone_overlap-from-ipapython.ipautil-to-ip.patch Type: text/x-patch Size: 8779 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0124-2-Use-root_logger-for-verify_host_resolvable.patch Type: text/x-patch Size: 7354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0125-2-Move-IP-address-resolution-from-ipaserver.install.in.patch Type: text/x-patch Size: 7559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0126-2-Turn-verify_host_resolvable-into-a-wrapper-around-ip.patch Type: text/x-patch Size: 7203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0127-2-Add-ipaDNSVersion-option-to-dnsconfig-commands-and-u.patch Type: text/x-patch Size: 16167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0128-2-DNS-upgrade-separate-backup-logic-to-make-it-reusabl.patch Type: text/x-patch Size: 9297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0129-2-Add-function-ipapython.dnsutil.related_to_auto_empty.patch Type: text/x-patch Size: 1859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0130-2-DNS-upgrade-change-forwarding-policy-to-only-for-con.patch Type: text/x-patch Size: 6178 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0131-2-DNS-upgrade-change-global-forwarding-policy-in-LDAP-.patch Type: text/x-patch Size: 3275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0132-2-DNS-upgrade-change-global-forwarding-policy-in-named.patch Type: text/x-patch Size: 5852 bytes Desc: not available URL: From jcholast at redhat.com Mon May 30 10:54:29 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 May 2016 12:54:29 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> References: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> Message-ID: <651ee173-8f3d-b01f-7bf5-9d1f67dab451@redhat.com> On 30.5.2016 12:36, Martin Basti wrote: > > > On 26.05.2016 19:31, Stanislav Laznicka wrote: >> >> Self NACK. I should not post patches when tired, sorry. Minor fix is >> attached. >> >> >> On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: >>> Hello, >>> >>> Please, see the attached patch. Fixes >>> https://fedorahosted.org/freeipa/ticket/5898 >>> >>> Standa >>> >>> >>> >> >> >> > > LGTM, if nobody is against this, I will push it in 2 days NACK, please add `wait` argument and call self.wait_until_running(), same as in start() and restart(). -- Jan Cholasta From pspacek at redhat.com Mon May 30 12:12:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 30 May 2016 14:12:34 +0200 Subject: [Freeipa-devel] [PATCH 0036] Increased mod_wsgi socket-timeout In-Reply-To: <58d3d9ef-d8c5-50be-1348-3c8b2835d70d@redhat.com> References: <304a20ca-ca5b-8df7-f1ca-090c60ec3a01@redhat.com> <58d3d9ef-d8c5-50be-1348-3c8b2835d70d@redhat.com> Message-ID: <5c8a4e16-98b1-2e0c-3e78-c7e6e54098e9@redhat.com> On 28.5.2016 15:59, Martin Basti wrote: > > > On 27.05.2016 14:52, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/5833 >> >> >> > Is possible to remove timeout completely as it used to be before? > > Even if this timeout is exceeded, command continue in execution and it just > doesnt print result to user I agree with Martin. The timeout is pointless, please remove it or set it to 2^31 or so. -- Petr^2 Spacek From mbasti at redhat.com Mon May 30 14:48:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 May 2016 16:48:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0789-0796 Python 3 fixes for the server part In-Reply-To: <31cf8af1-a133-73b8-7304-90f827a8ad4e@redhat.com> References: <31cf8af1-a133-73b8-7304-90f827a8ad4e@redhat.com> Message-ID: <0ee00766-99dc-f597-5266-c99cc8737d3e@redhat.com> On 20.05.2016 17:04, Petr Viktorin wrote: > Hello, > Here are some more Python3 patches. Most are pretty routine, but pay > special attention to the first and last patch. > > > With these patches, running the in-tree test suite gives me the same > errors in Python 2 and Python 3, except: > - test_install ? failures in the updater that I haven't investigated yet > - test_ipaserver ? test bug (relying on order of values in an LDAP > attribute) and a text/bytes issue in certificate parsing > > > In the next few months, I'll need to focus less on IPA and more on > Samba, which is a prerequisite for porting the IPA server. So I'll > quickly summarize the current state of the porting effort: > > All of FreeIPA's dependencies except Samba are ported to Python 3 (and > packaged in Fedora). > A recent change switched the IPA client to running on Python 3. With the > patches I'm sending now, most of the "single machine" tests are passing. > The install scripts will still need some work, as will the server parts > that aren't shared with the client. > > > I'd like to ask the IPA team to sometimes take a look at the Python 3 > tests, and try to avoid too many regressions. > > > > ACK, pushed master: * 36094b2a542a9472506034dc6c86a573e95c71de ipaldap: Keep attribute names as text, not bytes * 75d0a73bbc426e9b6cabc38f2e932d701b25a762 ipapython.secrets.kem: Use ConfigParser from six.moves * 9477cddfeb9adc03e039155ce3b8a0b560f71098 test_topology_plugin: Don't rely on order of an attribute's values * 9ca450ac436344afd3a46d9852d8329a2e9a48d2 test_rpcserver: Expect updated error message under Python 3 * 743828b0f47ca4934125cfb8dc57f79283b95a4d ipaplatform.redhat: Use bytestrings when calling rpm.so for version comparison * 25560f0e1db0c432de35a2496d9c1f8e63dc3dfd test_ipaserver.test_ldap: Use bytestrings for raw LDAP values * c192c1ae3e080597995b906d93cc7607ffc605c0 ipaldap: Convert dict items to list before iterating * 037eae26d0cd8467d3a559bb4cc585c61b626734 test_ipaserver.test_ldap: Adjust tests to Python 3's KeyView ipa-4-3: * f01b5e506c720181f56e54aa89925a4720642d83 ipaldap: Keep attribute names as text, not bytes * 546b1d0fe6cefd2cbaa3d56f0b1d2939fbdff291 ipapython.secrets.kem: Use ConfigParser from six.moves * 937ebf43745dff7c9894954262bab2d71d9afc71 test_topology_plugin: Don't rely on order of an attribute's values * 74e3fd1d4ae4067caf0d4bda9e962e7c5ceb821c test_rpcserver: Expect updated error message under Python 3 * 12e73c95ccd26b5d8156abfddd59ddaca0689a6b ipaplatform.redhat: Use bytestrings when calling rpm.so for version comparison * 3c610bee162f6b420ae91592d90303b662249b7e test_ipaserver.test_ldap: Use bytestrings for raw LDAP values * a78c350589733585b78d6cd7ece63276c2b57634 ipaldap: Convert dict items to list before iterating * 1933e604fb0822bc08caa4aec499be949f731d3b test_ipaserver.test_ldap: Adjust tests to Python 3's KeyView -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon May 30 15:44:11 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 May 2016 17:44:11 +0200 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <1464364830.3425.14.camel@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> Message-ID: On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: > Pavel, since we made the change here from a StrEnum to a Str, we need > to update the UI patch accordingly. How should admin know what to write there intuitively? Shouldn't Web UI or CLI advertise the indicators supported by IPA? E.g. CLI in doc string. Web UI might even combine checkboxes (otp, radius) with textbox. > > On Fri, 2016-05-27 at 11:55 -0400, Nathaniel McCallum wrote: >> On Fri, 2016-05-27 at 18:35 +0300, Alexander Bokovoy wrote: >>> On Fri, 27 May 2016, Nathaniel McCallum wrote: >>>> All core functionality for authentication indicators has already >>>> been >>>> merged. All that is left is the CLI and UI patches. Attached is >>>> the >>>> CLI >>>> patch. >>>> >>>> One outstanding question that I have is how to future-proof this >>>> patch. >>>> Right now, we want to only permit two possible values: otp and >>>> radius. >>>> So we are using an StrEnum. However, in the future (probably >>>> after >>>> krb5-spake) we may want to have per-token custom indicators. That >>>> means >>>> that this value will need to become a Str. >>> PKINIT has already support for AI, so it would be good to add >>> pkinit >>> indicator as well. The problem here is that pkinit indicator is not >>> fixed and can be defined in the krb5.conf. >> >> Okay. You've convinced me that we should just make it a string now >> and >> be done with it since administrators can already set custom AIs. New >> patch attached. I think this is ready for merge. >> >>>> How do I code this so that we can later do a StrEnum => Str >>>> transition >>>> without breaking API? >>> Maybe just go to Str* right now and make a validation function that >>> performs the actual check? Once you'd upgrade the validation code >>> would >>> change but method signature wouldn't. >> >> Since admins can already set custom AIs, there is no reason for a >> validator. Let's just accept everything. > -- Petr Vobornik From pvoborni at redhat.com Mon May 30 15:57:40 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 May 2016 17:57:40 +0200 Subject: [Freeipa-devel] [PATCH 0013] Updated ipa-server-install man page for domain-level attribute In-Reply-To: <3abc892d-35e5-0798-55f1-05b122ab7809@redhat.com> References: <572C2C9A.5030000@redhat.com> <7f70763e-c89f-fe30-7cb7-ba1c155094cc@redhat.com> <573EF341.8030201@redhat.com> <3abc892d-35e5-0798-55f1-05b122ab7809@redhat.com> Message-ID: On 05/20/2016 01:56 PM, Petr Spacek wrote: > On 20.5.2016 13:21, Abhijeet Kasurde wrote: >> Hi All, ... > > Thanks but NACK. > > Domain level is not about one server. It defines that all servers in one IPA > topology behave in some particular way. > There is a proposal in triage: https://fedorahosted.org/freeipa/ticket/5907 which might and most likely will obsolete this ticket - #5708. -- Petr Vobornik From abokovoy at redhat.com Mon May 30 16:08:27 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 May 2016 19:08:27 +0300 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> Message-ID: <20160530160827.3rodv6htgn2dodeq@redhat.com> On Mon, 30 May 2016, Petr Vobornik wrote: >On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: >> Pavel, since we made the change here from a StrEnum to a Str, we need >> to update the UI patch accordingly. > >How should admin know what to write there intuitively? > >Shouldn't Web UI or CLI advertise the indicators supported by IPA? E.g. >CLI in doc string. Web UI might even combine checkboxes (otp, radius) >with textbox. That would be better, I think. We still need to keep the API with a free text field but Web UI, of course, should provide some pre-defined labels. -- / Alexander Bokovoy From frenaud at redhat.com Mon May 30 16:11:51 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Mon, 30 May 2016 18:11:51 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Add the culprit line when a configuration file has an incorrect format In-Reply-To: <7c482bfd-c466-a2c9-ca29-bcd2a28163df@redhat.com> References: <7c482bfd-c466-a2c9-ca29-bcd2a28163df@redhat.com> Message-ID: <93631e86-725f-ba0e-ce17-6e8b99325f23@redhat.com> Hi Martin, thanks for the review and the suggestion. Please find the updated patch attached. Flo. On 05/30/2016 11:00 AM, Martin Basti wrote: > > > > On 27.05.2016 11:35, Florence Blanc-Renaud wrote: >> >> Hi all, >> >> this patch adds information to the output of ipa-client-install when >> it fails due to invalid format in a configuration file: >> ipa-client-install failing with SyntaxError: Syntax Error: Unknown >> line format >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5811 >> >> -- >> Florence Blanc-Renaud >> Identity Management Team, Red Hat >> >> > Thank you for your patch, I have just one nitpick. Can you please > reuse the original exception? > > - curopts.append(self.parseLine(line)) > + try: > + curopts.append(self.parseLine(line)) > + except SyntaxError as e: > + raise SyntaxError('{error} in file {fname}: > [{line}]'.format( > + error=e, fname=f.name, line=line)) > > Martin^2 -- Florence Blanc-Renaud Identity Management Team, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0002-2-Add-the-culprit-line-when-a-configuration-file-has-a.patch Type: text/x-patch Size: 1405 bytes Desc: not available URL: From mbabinsk at redhat.com Mon May 30 17:03:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 30 May 2016 19:03:21 +0200 Subject: [Freeipa-devel] [PATCH 0146-0147] Server Roles: basic infrastructure In-Reply-To: <0ba1b172-3bb8-0c29-8212-72c7027841a9@redhat.com> References: <28b45db2-8116-359c-d28f-90201fa16271@redhat.com> <0ba1b172-3bb8-0c29-8212-72c7027841a9@redhat.com> Message-ID: <2e8aa9d9-ecf9-e175-141d-2038145f3354@redhat.com> On 05/27/2016 05:30 PM, Martin Babinsky wrote: > On 05/19/2016 04:59 PM, Martin Babinsky wrote: >> Patch 0146 implements lower-lever infrastructure for querying server >> roles/attributes >> >> Patch 0147 are some basic tests slapped together for the `serverroles` >> backend to ensure that it works as expected. >> >> The new/modified CLI commands specified in the design page [1] will be >> coming soon. >> >> Also coming soon will be an interface to construct DNS records for each >> role requested by Petr^2 and Martin^2 which I will start implement when >> we agree on the backend implementation. >> >> https://fedorahosted.org/freeipa/ticket/5181 >> >> [1] https://www.freeipa.org/page/V4/Server_Roles#CLI >> >> >> > Thanks Martin and Honza for review. > > I have reworked the patches based on your comments. I have split patch > 146 into two (role/attribute definitions and backend code) so patches > 146-147 are for code and 148 hosts test suite. > > I hope that I will send API patches on monday after I resolve some > framework-related questions with the local guru. > > > Another revision of backend patches attached. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0146.2-Server-roles-definitions-of-server-roles-and-attribu.patch Type: text/x-patch Size: 22152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0147.2-Server-Roles-Backend-plugin-to-query-roles-and-attri.patch Type: text/x-patch Size: 6210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0148.2-Test-suite-for-serverroles-backend.patch Type: text/x-patch Size: 25487 bytes Desc: not available URL: From mbabinsk at redhat.com Mon May 30 17:13:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 30 May 2016 19:13:08 +0200 Subject: [Freeipa-devel] [PATCH 0149-0152] Server Roles: user-facing part Message-ID: <7d27e63b-a93a-30dd-b661-aa4f31535609@redhat.com> These patches implement the usable part of Server Roles design. There might be some discrepancies between the design and actual implementation, I was head first in hacking and was not very disciplined in keeping the design up to date. I will fix this ASAP. http://www.freeipa.org/page/V4/Server_Roles https://fedorahosted.org/freeipa/ticket/5181 https://fedorahosted.org/freeipa/ticket/5689 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0149-Server-Roles-public-API-for-server-roles.patch Type: text/x-patch Size: 6756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0150-Server-Roles-make-server-show-find-utilize-role-info.patch Type: text/x-patch Size: 7935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0151-Server-Roles-make-config-show-consume-relevant-roles.patch Type: text/x-patch Size: 6797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0152-Server-Roles-provide-an-API-for-setting-CA-renewal-m.patch Type: text/x-patch Size: 5112 bytes Desc: not available URL: From frenaud at redhat.com Mon May 30 17:58:18 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Mon, 30 May 2016 19:58:18 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Report missing certificate in external trust chain Message-ID: <45575d05-92a0-bc30-d287-a547d76dd62e@redhat.com> Hi all, this patch adds in the error message the missing certificate that caused i/pa-server-install --external-cert-file=.../ to fail. https://fedorahosted.org/freeipa/ticket/5792 -- Florence Blanc-Renaud Identity Management Team, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0004-Report-missing-certificate-in-external-trust-chain.patch Type: text/x-patch Size: 1500 bytes Desc: not available URL: From mbasti at redhat.com Mon May 30 18:38:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 May 2016 20:38:55 +0200 Subject: [Freeipa-devel] [PATCH 0123-132] DNS upgrade: change forwarding policy to "only" if private IPs are used In-Reply-To: References: <511dce5e-4f52-6f29-9ea5-19d189885cbf@redhat.com> <269d1dec-6677-a6c6-5b79-df0d2ce697a7@redhat.com> <56c1e83f-5629-1da7-8090-ba55355c6bf9@redhat.com> Message-ID: On 30.05.2016 12:49, Petr Spacek wrote: > On 29.5.2016 14:45, Martin Basti wrote: >> >> On 27.05.2016 14:12, Petr Spacek wrote: >>> On 25.5.2016 12:50, Martin Basti wrote: >>>> On 20.05.2016 12:19, Petr Spacek wrote: >>>>> On 11.5.2016 12:08, Martin Basti wrote: >>>>>> On 03.05.2016 14:59, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> DNS upgrade: change forwarding policy to "only" if private IPs are used. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>>> >>>>>>> This is the upgrade part. I will add one more patch to print a warning in >>>>>>> dnsforwardzone* commands to avoid surprises. Please do not close the ticket >>>>>>> yet. >>>>>>> >>>>>>> >>>>>>> >>>>>> 1) >>>>>> Upgrade failed with 'BindInstance' object has no attribute >>>>>> 'named_conf_get_directive' >>>>>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command >>>>>> ipa-server-upgrade manually. >>>>>> ('IPA upgrade failed.', 1) >>>>>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more >>>>>> information >>>>>> >>>>>> 2016-05-11T08:26:20Z ERROR Upgrade failed with 'BindInstance' object has no >>>>>> attribute 'named_conf_get_directive' >>>>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>> line >>>>>> 213, in __upgrade >>>>>> self.modified = (ld.update(self.files) or self.modified) >>>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>> line 917, in update >>>>>> self._run_updates(all_updates) >>>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>> line 889, in _run_updates >>>>>> self._run_update_plugin(update['plugin']) >>>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", >>>>>> line 862, in _run_update_plugin >>>>>> restart_ds, updates = self.api.Updater[plugin_name]() >>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>>> 1418, in >>>>>> __call__ >>>>>> return self.execute(**options) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>>>> line 547, in execute >>>>>> self.update_global_named_conf_forwarder(bind) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", >>>>>> line 508, in update_global_named_conf_forwarder >>>>>> if bind.named_conf_get_directive( >>>>>> AttributeError: 'BindInstance' object has no attribute >>>>>> 'named_conf_get_directive' >>>>>> >>>>>> 2016-05-11T08:26:20Z DEBUG Traceback (most recent call last): >>>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 447, in start_creation >>>>>> run_step(full_msg, method) >>>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> line >>>>>> 437, in run_step >>>>>> method() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>>>>> line >>>>>> 221, in __upgrade >>>>>> raise RuntimeError(e) >>>>>> RuntimeError: 'BindInstance' object has no attribute >>>>>> 'named_conf_get_directive' >>>>>> >>>>>> PATCH * Add ipaDNSVersion option to dnsconfig* commands and use new >>>>>> attribute * >>>>>> 2) >>>>>> + Int('ipadnsversion?', >>>>>> + label=_('IPA DNS version'), >>>>>> + ), >>>>>> >>>>>> Shouldn't be this part of System: Read DNS Configuration permission? >>>>>> >>>>>> 3) >>>>>> - def postprocess_result(self, result): >>>>>> + def postprocess_result(self, result, show_version): >>>>>> if not any(param in result['result'] for param in self.params): >>>>>> result['summary'] = unicode(_('Global DNS configuration is >>>>>> empty')) >>>>>> >>>>>> show_version param was added but I don't see it used in this patch. >>>>>> >>>>>> 4) >>>>>> + Int('ipadnsversion?', >>>>>> + label=_('IPA DNS version'), >>>>>> + ), >>>>>> >>>>>> Could we add comment here that this option is accessible only from >>>>>> installers >>>>>> and upgrade? >>>>>> >>>>>> 5) >>>>>> + for config_option in container_entry.get("ipaConfigString", []): >>>>>> + matched = re.match("^DNSVersion\s+(?P\d+)$", >>>>>> + config_option, flags=re.I) >>>>>> + if matched: >>>>>> + version = int(matched.group("version")) >>>>>> >>>>>> Shouldn't we print error if version cannot be parsed? >>>>>> >>>>>> PATCH * DNS upgrade: separate backup logic to make it reusable * >>>>>> >>>>>> LGTM >>>>>> >>>>>> PATCH * Add function ipapython.dnsutil.related_to_auto_empty_zone() * >>>>>> >>>>>> 7) >>>>>> I'm curious why do you need to check superdomains? >>>>>> >>>>>> PATCH * DNS upgrade: change forwarding policy to = only for conflicting >>>>>> forward zones* >>>>>> >>>>>> 8) >>>>>> + self.log.debug('Zone %s was sucessfully modified to use ' >>>>>> + 'forward policy "only"', zone['idnsname'][0]) >>>>>> <---missing empty line----> >>>>>> + def execute(self, **options): >>>>>> >>>>>> PATCH * DNS upgrade: change global forwarding policy in LDAP to "only" if >>>>>> private IPs are used * >>>>>> 9) >>>>>> - dnsutil.related_to_auto_empty_zone(zone.get('idnsname')[0]) >>>>>> + dnsutil.related_to_auto_empty_zone( >>>>>> + dnsutil.DNSName(zone.get('idnsname')[0])) >>>>>> >>>>>> Should be in previous commit >>>>>> >>>>>> 10) >>>>>> - return >>>>>> + return False, [] >>>>>> This should be fixed in the previous commit >>>>>> >>>>>> PATCH * DNS upgrade: change global forwarding policy in named.conf to "only" >>>>>> if private IPs are used * >>>>>> 11) >>>>>> IMO this is an upgrade of configuration and this should be in >>>>>> ipaserver/install/server/upgrade.py, upgrade plugins are used only for >>>>>> updating of LDAP values >>>>>> >>>>>> Unless you really want to use this as precedence, but then it requires >>>>>> broader >>>>>> discussion. >>>>>> >>>>>> 12) >>>>>> >>>>>> bind.named_conf_get_directive >>>>>> should be >>>>>> bindinstance.named_conf_get_directive >>>>>> >>>>>> see 1) >>>>> This new patchset completely obsoletes the old one. I had to reshuffle few >>>>> things to to make the split between server config & LDAP upgrade possible. >>>>> >>>>> Hopefully I addressed all your comment. >>>>> >>>> commits >>>> * Move IP address resolution from ipaserver.install.installutils to >>>> ipapython.dnsutil * and * Turn verify_host_resolvable() into a wrapper around >>>> ipapython.dnsutil * >>>> >>>> cause regression in case that dns.python resolver returns NoNameservers >>>> exception, it is handled as 'Internal server error' >>>> >>>> In original code every exception was caught and transformed to >>>> DNSNotARecordError. >>>> >>>> So we have following options: >>>> * keep the old behavior in 'resolve_rrsets' and catch all exceptions there >>>> * or catch all DNS errors in 'verify_host_resolvable' and raise it as new >>>> PublicError (DNSGenericError (doesn't exist) for example) >>>> >>>> >>>> E InternalError: an internal error has occurred >>>> >>>> ../ipalib/rpc.py:1100: InternalError >>>> test_forwardzone_delegation_warnings.test_command[0017: dnsrecord_mod: >>>> Delete >>>> (using dnsrecord-mod) NS record which delegates zone >>>> u'fw.sub2.sub.dnszone.test.' from zone u'dnszone.test' (expected warning for >>>> u'fw.sub2.sub.dnszone.test.')] >>>> >>>> [Wed May 25 12:17:00.172143 2016] [wsgi:error] [pid 62789] Traceback (most >>>> recent call last): >>>> [Wed May 25 12:17:00.172152 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in >>>> wsgi_execute >>>> [Wed May 25 12:17:00.172158 2016] [wsgi:error] [pid 62789] result = >>>> self.Command[name](*args, **options) >>>> [Wed May 25 12:17:00.172164 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 434, in __call__ >>>> [Wed May 25 12:17:00.172168 2016] [wsgi:error] [pid 62789] return >>>> self.__do_call(*args, **options) >>>> [Wed May 25 12:17:00.172173 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 460, in __do_call >>>> [Wed May 25 12:17:00.172178 2016] [wsgi:error] [pid 62789] ret = >>>> self.run(*args, **options) >>>> [Wed May 25 12:17:00.172183 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 777, in run >>>> [Wed May 25 12:17:00.172189 2016] [wsgi:error] [pid 62789] return >>>> self.execute(*args, **options) >>>> [Wed May 25 12:17:00.172194 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3774, in >>>> execute >>>> [Wed May 25 12:17:00.172199 2016] [wsgi:error] [pid 62789] result = >>>> super(dnsrecord_add, self).execute(*keys, **options) >>>> [Wed May 25 12:17:00.172204 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1230, in >>>> execute >>>> [Wed May 25 12:17:00.172209 2016] [wsgi:error] [pid 62789] *keys, **options) >>>> [Wed May 25 12:17:00.172213 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3719, in >>>> pre_callback >>>> [Wed May 25 12:17:00.172229 2016] [wsgi:error] [pid 62789] >>>> self.obj.run_precallback_validators(dn, entry_attrs, *keys, **options) >>>> [Wed May 25 12:17:00.172237 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3135, in >>>> run_precallback_validators >>>> [Wed May 25 12:17:00.172242 2016] [wsgi:error] [pid 62789] rtype_cb(ldap, dn, >>>> entry_attrs, *keys, **options) >>>> [Wed May 25 12:17:00.172247 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 3057, in >>>> _nsrecord_pre_callback >>>> [Wed May 25 12:17:00.172252 2016] [wsgi:error] [pid 62789] >>>> check_ns_rec_resolvable(keys[0], DNSName(nsrecord), self.log) >>>> [Wed May 25 12:17:00.172256 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 1577, in >>>> check_ns_rec_resolvable >>>> [Wed May 25 12:17:00.172261 2016] [wsgi:error] [pid 62789] >>>> verify_host_resolvable(name) >>>> [Wed May 25 12:17:00.172265 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipalib/util.py", line 70, in >>>> verify_host_resolvable >>>> [Wed May 25 12:17:00.172270 2016] [wsgi:error] [pid 62789] if not >>>> resolve_ip_addresses(fqdn): >>>> [Wed May 25 12:17:00.172274 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 328, in >>>> resolve_ip_addresses >>>> [Wed May 25 12:17:00.172278 2016] [wsgi:error] [pid 62789] rrsets = >>>> resolve_rrsets(fqdn, ['A', 'AAAA']) >>>> [Wed May 25 12:17:00.172282 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/ipapython/dnsutil.py", line 305, in >>>> resolve_rrsets >>>> [Wed May 25 12:17:00.172287 2016] [wsgi:error] [pid 62789] answer = >>>> dns.resolver.query(fqdn, rdtype) >>>> [Wed May 25 12:17:00.172292 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 1029, in query >>>> [Wed May 25 12:17:00.172296 2016] [wsgi:error] [pid 62789] raise_on_no_answer, >>>> source_port) >>>> [Wed May 25 12:17:00.172301 2016] [wsgi:error] [pid 62789] File >>>> "/usr/lib/python2.7/site-packages/dns/resolver.py", line 856, in query >>>> [Wed May 25 12:17:00.172328 2016] [wsgi:error] [pid 62789] raise >>>> NoNameservers(request=request, errors=errors) >>> Fixed patches are attached. >>> >>> >>> Please note that I've renumbered the patches because the naming does not match >>> the original set anymore. >>> >> NACK >> >> # ipa-run-tests test_xmlrpc/test_host_plugin.py >> =============================================================================================== >> test session starts >> =============================================================================================== >> >> platform linux2 -- Python 2.7.11, pytest-2.9.1, py-1.4.31, pluggy-0.3.1 >> rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini >> plugins: sourceorder-0.5, multihost-1.0 >> collected 41 items >> >> test_xmlrpc/test_host_plugin.py ...................F...........s......... >> >> ==================================================================================================== >> FAILURES >> ===================================================================================================== >> >> ________________________________________________________________________________________ >> TestCRUD.test_try_add_not_in_dns >> _________________________________________________________________________________________ >> >> >> self = > 0x7efc061e4110>, host = > object at 0x7efc0623bb90> >> >> def test_try_add_not_in_dns(self, host): >> host.ensure_missing() >> command = host.make_create_command(force=False) >> with raises_exact(errors.DNSNotARecordError( >>> reason=u'Host does not have corresponding DNS A/AAAA record')): >> test_xmlrpc/test_host_plugin.py:315: >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> ../ipalib/errors.py:264: in __init__ >> messages.process_message_arguments(self, format, message, **kw) >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> >> obj = DNSNotARecordError(), format = None, message = None, kw = {'reason': >> 'Host does not have corresponding DNS A/AAAA record'}, key = 'reason', value = >> 'Host does not have corresponding DNS A/AAAA record' >> name = 'DNSNotARecordError' >> >> def process_message_arguments(obj, format=None, message=None, **kw): >> for key, value in kw.items(): >> if not isinstance(value, six.integer_types): >> try: >> kw[key] = unicode(value) >> except UnicodeError: >> pass >> obj.kw = kw >> name = obj.__class__.__name__ >> if obj.format is not None and format is not None: >> raise ValueError( >> 'non-generic %r needs format=None; got format=%r' % ( >> name, format) >> ) >> if message is None: >> if obj.format is None: >> if format is None: >> raise ValueError( >> '%s.format is None yet format=None, message=None' % name >> ) >> obj.format = format >> obj.forwarded = False >>> obj.msg = obj.format % kw >> E KeyError: 'hostname' > Sorry, this got lost in all the 'normal' failures :-) > > I do not 100% understand this test logic so I hope that attached patch fixes > it correctly. > ACK master: * 0c75df4bf3784eae08f41c176bbaab44c6d510a7 Move check_zone_overlap() from ipapython.ipautil to ipapython.dnsutil * ec49130b94d2aa195c6b704a30fe6c3137fabdbf Use root_logger for verify_host_resolvable() * dc405005f537cf278fd6ddfe6b87060bd13d9a67 Move IP address resolution from ipaserver.install.installutils to ipapython.dnsutil * 70794c7b1d001ce331d4a64c77d23abcc02c541e Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil * 321a2ba9185e4a21d5b2f9949cd3bec32a1fd60a Add ipaDNSVersion option to dnsconfig* commands and use new attribute * a4da9a23788d9f09f562c12d80353fca42f73441 DNS upgrade: separate backup logic to make it reusable * c978ad5b425a564b6bd3b97fb7a5e25219000e52 Add function ipapython.dnsutil.related_to_auto_empty_zone() * f750d42b6f2d7f792ce56b6832d2bd1ae1f333a0 DNS upgrade: change forwarding policy to = only for conflicting forward zones * e45a80308c947a58c0fb5266d75eedc1d9aef321 DNS upgrade: change global forwarding policy in LDAP to "only" if private IPs are used * 6eb00561c0f85085d86f7be936b632ba017fc4f1 DNS upgrade: change global forwarding policy in named.conf to "only" if private IPs are used ipa-4-3: * b18f848bed6ace5fd63fe1c6559ebc68997ccbe2 Move check_zone_overlap() from ipapython.ipautil to ipapython.dnsutil * a54b8222dc2f3ec7d22e67f00b8c30b3893c0ced Use root_logger for verify_host_resolvable() * f170f155b9a0921b6f4ab6b24713a3c1bf0148bc Move IP address resolution from ipaserver.install.installutils to ipapython.dnsutil * da119a620f36bac24f43098d2f0713bb46cf4329 Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil * d75998c55d9a961c1cbd74b3ef00a5921e9bde0a Add ipaDNSVersion option to dnsconfig* commands and use new attribute * 12590597320c7d4ef4506a018097dad629113fdc DNS upgrade: separate backup logic to make it reusable * e69254b253903aa8fd76022df7f5e5505a819ebf Add function ipapython.dnsutil.related_to_auto_empty_zone() * f8a39898bbd4c17d2976515c9d73f0e27a984709 DNS upgrade: change forwarding policy to = only for conflicting forward zones * 700246174c8c9cfbbbee5b0101acfa4227995cc7 DNS upgrade: change global forwarding policy in LDAP to "only" if private IPs are used * 233550ab1dab55d518cfdc104b521672babdde7f DNS upgrade: change global forwarding policy in named.conf to "only" if private IPs are used From mbasti at redhat.com Mon May 30 18:39:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 May 2016 20:39:33 +0200 Subject: [Freeipa-devel] [PATCH 0110] DNS: Warn if forwarding policy conflicts with automatic empty zone In-Reply-To: <3e925ead-6fbd-ef81-d704-bba77009eb13@redhat.com> References: <44b60702-e8cb-364f-39bc-114404349972@redhat.com> <3e925ead-6fbd-ef81-d704-bba77009eb13@redhat.com> Message-ID: <60b5b40c-5ffe-78bc-28cd-113d6fc1b4fa@redhat.com> On 27.05.2016 14:13, Petr Spacek wrote: > On 25.5.2016 12:30, Martin Basti wrote: >> >> On 04.05.2016 10:43, Petr Spacek wrote: >>> Hello, >>> >>> DNS: Warn if forwarding policy conflicts with automatic empty zones >>> >>> Forwarding policy "first" or "none" may conflicts with some automatic empty >>> zones. Queries for zones specified by RFC 6303 will ignore >>> forwarding and recursion and always result in NXDOMAIN answers. >>> >>> This is not detected and warned about. Global forwarding is equivalent >>> to forward zone ".". >>> >>> Example: >>> Forward zone 1.10.in-addr.arpa with policy "first" >>> will not forward anything because BIND will automatically prefer >>> automatic empty zone "10.in-addr.arpa." which is authoritative. >>> >>> https://fedorahosted.org/freeipa/ticket/5710 >>> >>> >>> This is last patch in the series so the ticket can be closed when all relevant >>> patches are pushed. >>> >>> >>> >> >> You forgot to update tests >> >> _____________________________________________________________________ >> test_dns.test_command[0087: dnsconfig_mod: Update global DNS settings] >> ______________________________________________________________________ >> >> self = > 0x7fcef3ef2510>, index = 87 >> declarative_test_definition = {'command': ('dnsconfig_mod', [], >> {'idnsforwarders': ['172.16.31.80'], 'version': '2.166'}), 'desc': 'Update >> global DN...arders': ['172.16.31.80']}, 'summary': None, 'value': None}, >> 'nice': '0087: dnsconfig_mod: Update global DNS settings'} >> >> def test_command(self, index, declarative_test_definition): >> """Run an individual test >> >> The arguments are provided by the pytest plugin. >> """ >> if callable(declarative_test_definition): >> declarative_test_definition(self) >> else: >>> self.check(**declarative_test_definition) >> test_xmlrpc/xmlrpc_test.py:313: >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> test_xmlrpc/xmlrpc_test.py:325: in check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> test_xmlrpc/xmlrpc_test.py:368: in check_output >> assert_deepequal(expected, got, nice) >> util.py:361: in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> >> expected = [{'code': 13006, 'message': at 0x7fcef426c758>, >> 'name': 'DNSServerValidationWarning', 'type': 'warning'}] >> got = [{'code': 13021, 'message': "Forwarding policy conflicts with some >> automatic empty zones. Queries for zones specified ...': The DNS operation >> timed out after 10.0008428097 seconds.", 'name': 'DNSServerValidationWarning', >> 'type': 'warning'}] >> doc = '0087: dnsconfig_mod: Update global DNS settings', stack = ('messages',) >> >> def assert_deepequal(expected, got, doc='', stack=tuple()): >> """ >> Recursively check for type and equality. >> >> If a value in expected is callable then it will used as a callback to >> test for equality on the got value. The callback is passed the got >> value and returns True if equal, False otherwise. >> >> If the tests fails, it will raise an ``AssertionError`` with detailed >> information, including the path to the offending value. For example: >> >> >>> expected = [u'Hello', dict(world=u'how are you?')] >> >>> got = [u'Hello', dict(world='how are you?')] >> >>> expected == got >> True >> >>> assert_deepequal(expected, got, doc='Testing my nested data') >> Traceback (most recent call last): >> ... >> AssertionError: assert_deepequal: type(expected) is not type(got). >> Testing my nested data >> type(expected) = >> type(got) = >> expected = u'how are you?' >> got = 'how are you?' >> path = (0, 'world') >> >> Note that lists and tuples are considered equivalent, and the order of >> their elements does not matter. >> """ >> if isinstance(expected, tuple): >> expected = list(expected) >> if isinstance(got, tuple): >> got = list(got) >> if isinstance(expected, DN): >> if isinstance(got, six.string_types): >> got = DN(got) >> if not (isinstance(expected, Fuzzy) or callable(expected) or >> type(expected) is type(got)): >> raise AssertionError( >> TYPE % (doc, type(expected), type(got), expected, got, stack) >> ) >> if isinstance(expected, (list, tuple)): >> if len(expected) != len(got): >> raise AssertionError( >>> LEN % (doc, len(expected), len(got), expected, got, stack) >> ) >> E AssertionError: assert_deepequal: list length mismatch. >> E 0087: dnsconfig_mod: Update global DNS settings >> E len(expected) = 1 >> E len(got) = 2 >> E expected = [{u'message': at >> 0x7fcef426c758>, u'code': 13006, u'type': u'warning', u'name': >> u'DNSServerValidationWarning'}] >> E got = [{u'message': u"Forwarding policy conflicts with some >> automatic empty zones. Queries for zones specified by RFC 6303 will ignore >> forwarding and recursion and always result in NXDOMAIN answers. To override >> this behavior use forward policy 'only'.", u'code': 13021, u'type': >> u'warning', u'name': u'DNSForwardPolicyConflictWithEmptyZone'}, {u'message': >> u"DNS server 172.16.31.80: query '. SOA': The DNS operation timed out after >> 10.0008428097 seconds.", u'code': 13006, u'type': u'warning', u'name': >> u'DNSServerValidationWarning'}] >> E path = (u'messages',) >> >> util.py:332: AssertionError > Fixed patch is attached. It depends on newest patches 113-132. > ACK master: * da71e7e9de233bc0e40a90adb2db6d0944a1356a DNS: Warn if forwarding policy conflicts with automatic empty zones ipa-4-3: * 8cbecdbc8dc022005beec3a9fe19aabd91041bbf DNS: Warn if forwarding policy conflicts with automatic empty zones From npmccallum at redhat.com Mon May 30 19:00:37 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 30 May 2016 15:00:37 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <20160530160827.3rodv6htgn2dodeq@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> <20160530160827.3rodv6htgn2dodeq@redhat.com> Message-ID: <1464634837.11210.0.camel@redhat.com> On Mon, 2016-05-30 at 19:08 +0300, Alexander Bokovoy wrote: > On Mon, 30 May 2016, Petr Vobornik wrote: > > On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: > > > Pavel, since we made the change here from a StrEnum to a Str, we > > > need > > > to update the UI patch accordingly. > > > > How should admin know what to write there intuitively? > > > > Shouldn't Web UI or CLI advertise the indicators supported by IPA? > > E.g. > > CLI in doc string. Web UI might even combine checkboxes (otp, > > radius) > > with textbox. > That would be better, I think. We still need to keep the API with a > free > text field but Web UI, of course, should provide some pre-defined > labels. +1 From slaznick at redhat.com Tue May 31 07:41:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 31 May 2016 09:41:05 +0200 Subject: [Freeipa-devel] [PATCH 0036] Increased mod_wsgi socket-timeout In-Reply-To: <5c8a4e16-98b1-2e0c-3e78-c7e6e54098e9@redhat.com> References: <304a20ca-ca5b-8df7-f1ca-090c60ec3a01@redhat.com> <58d3d9ef-d8c5-50be-1348-3c8b2835d70d@redhat.com> <5c8a4e16-98b1-2e0c-3e78-c7e6e54098e9@redhat.com> Message-ID: <98ffcdc1-e89e-06fb-2c0f-11d659b70d76@redhat.com> On 05/30/2016 02:12 PM, Petr Spacek wrote: > On 28.5.2016 15:59, Martin Basti wrote: >> On 27.05.2016 14:52, Stanislav Laznicka wrote: >>> https://fedorahosted.org/freeipa/ticket/5833 >>> >>> >>> >> Is possible to remove timeout completely as it used to be before? >> >> Even if this timeout is exceeded, command continue in execution and it just >> doesnt print result to user > I agree with Martin. The timeout is pointless, please remove it or set it to > 2^31 or so. > The documentation does not clearly state what happens in the corner cases of this setting. However, by looking at the source code, I'm guessing that 0 is the default value which would eventually point to the Apache TimeOut and negative values seem just wrong for them here. They are converting it with atoi(), so I propose to set this to 2^31-1. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0036-2-Increased-mod_wsgi-socket-timeout.patch Type: text/x-patch Size: 1204 bytes Desc: not available URL: From slaznick at redhat.com Tue May 31 08:22:14 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 31 May 2016 10:22:14 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: <651ee173-8f3d-b01f-7bf5-9d1f67dab451@redhat.com> References: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> <651ee173-8f3d-b01f-7bf5-9d1f67dab451@redhat.com> Message-ID: <07c4d154-954f-eee0-127c-3574ceab7435@redhat.com> On 05/30/2016 12:54 PM, Jan Cholasta wrote: > On 30.5.2016 12:36, Martin Basti wrote: >> >> >> On 26.05.2016 19:31, Stanislav Laznicka wrote: >>> >>> Self NACK. I should not post patches when tired, sorry. Minor fix is >>> attached. >>> >>> >>> On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> Please, see the attached patch. Fixes >>>> https://fedorahosted.org/freeipa/ticket/5898 >>>> >>>> Standa >>>> >>>> >>>> >>> >>> >>> >> >> LGTM, if nobody is against this, I will push it in 2 days > > NACK, please add `wait` argument and call self.wait_until_running(), > same as in start() and restart(). > A pretty good point, please see the modified patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0033-3-Fixes-CA-always-being-presented-as-running.patch Type: text/x-patch Size: 2363 bytes Desc: not available URL: From slaznick at redhat.com Tue May 31 09:40:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 31 May 2016 11:40:05 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: <07c4d154-954f-eee0-127c-3574ceab7435@redhat.com> References: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> <651ee173-8f3d-b01f-7bf5-9d1f67dab451@redhat.com> <07c4d154-954f-eee0-127c-3574ceab7435@redhat.com> Message-ID: <654f3bb1-384d-e914-c7fc-67647558b0d0@redhat.com> On 05/31/2016 10:22 AM, Stanislav Laznicka wrote: > On 05/30/2016 12:54 PM, Jan Cholasta wrote: >> On 30.5.2016 12:36, Martin Basti wrote: >>> >>> >>> On 26.05.2016 19:31, Stanislav Laznicka wrote: >>>> >>>> Self NACK. I should not post patches when tired, sorry. Minor fix is >>>> attached. >>>> >>>> >>>> On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> Please, see the attached patch. Fixes >>>>> https://fedorahosted.org/freeipa/ticket/5898 >>>>> >>>>> Standa >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> LGTM, if nobody is against this, I will push it in 2 days >> >> NACK, please add `wait` argument and call self.wait_until_running(), >> same as in start() and restart(). >> > A pretty good point, please see the modified patch. > > Self.NACK - can't add 'wait' agrument to service.Service.is_running this easy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue May 31 10:44:47 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 31 May 2016 12:44:47 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches In-Reply-To: References: Message-ID: On 05/28/2016 01:17 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4995 > > Patches attached > > > Hi, PATCH 0488: LGTM PATCH 0489: @@ -996,10 +997,10 @@ def check_deleted_segments(hostname, masters, topo_errors, starting_host): i = 0 while True: left = api.Command.topologysegment_find( - suffix_name, iparepltoposegmentleftnode=hostname, sizelimit=0 + suffix_name, iparepltoposegmentleftnode=hostname, sizelimit=0, )['result'] right = api.Command.topologysegment_find( - suffix_name, iparepltoposegmentrightnode=hostname, sizelimit=0 + suffix_name, iparepltoposegmentrightnode=hostname, sizelimit=0, )['result'] it seems that you added 'no_members=True' there and then removed it because reasons. Please revert the this part to the original code so that it does not stick out. -- Martin^3 Babinsky From mbasti at redhat.com Tue May 31 10:56:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 31 May 2016 12:56:46 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches In-Reply-To: References: Message-ID: On 31.05.2016 12:44, Martin Babinsky wrote: > On 05/28/2016 01:17 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4995 >> >> Patches attached >> >> >> > > Hi, > > PATCH 0488: LGTM > > PATCH 0489: > > @@ -996,10 +997,10 @@ def check_deleted_segments(hostname, masters, > topo_errors, starting_host): > i = 0 > while True: > left = api.Command.topologysegment_find( > - suffix_name, iparepltoposegmentleftnode=hostname, > sizelimit=0 > + suffix_name, iparepltoposegmentleftnode=hostname, > sizelimit=0, > )['result'] > right = api.Command.topologysegment_find( > - suffix_name, iparepltoposegmentrightnode=hostname, > sizelimit=0 > + suffix_name, iparepltoposegmentrightnode=hostname, > sizelimit=0, > )['result'] > > it seems that you added 'no_members=True' there and then removed it > because reasons. Please revert the this part to the original code so > that it does not stick out. > Thanks, updated patches attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0488.2-Performance-Find-commands-do-not-process-members-by-.patch Type: text/x-patch Size: 87831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0489.2-Performance-add-membership-cache.patch Type: text/x-patch Size: 7912 bytes Desc: not available URL: From mbabinsk at redhat.com Tue May 31 11:04:44 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 31 May 2016 13:04:44 +0200 Subject: [Freeipa-devel] [PATCH 0486, 0487] Update zanata config In-Reply-To: <6ff73b41-c1a2-e6f0-87bd-0ca073e3d069@redhat.com> References: <6ff73b41-c1a2-e6f0-87bd-0ca073e3d069@redhat.com> Message-ID: On 05/26/2016 04:52 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5915 > > Patches attached > > > ACK. -- Martin^3 Babinsky From mbasti at redhat.com Tue May 31 11:46:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 31 May 2016 13:46:06 +0200 Subject: [Freeipa-devel] [PATCH 0486, 0487] Update zanata config In-Reply-To: References: <6ff73b41-c1a2-e6f0-87bd-0ca073e3d069@redhat.com> Message-ID: <7227f09f-e61b-40a7-2f44-6683033c0a8f@redhat.com> On 31.05.2016 13:04, Martin Babinsky wrote: > On 05/26/2016 04:52 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5915 >> >> Patches attached >> >> >> > ACK. > Even better patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0488.2-DNS-Locations-prevent-to-remove-used-locations.patch Type: text/x-patch Size: 3872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0489.2-DNS-Locations-extend-tests-with-server-commands.patch Type: text/x-patch Size: 11837 bytes Desc: not available URL: From mbasti at redhat.com Tue May 31 11:52:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 31 May 2016 13:52:32 +0200 Subject: [Freeipa-devel] [PATCH 0486, 0487] Update zanata config In-Reply-To: <7227f09f-e61b-40a7-2f44-6683033c0a8f@redhat.com> References: <6ff73b41-c1a2-e6f0-87bd-0ca073e3d069@redhat.com> <7227f09f-e61b-40a7-2f44-6683033c0a8f@redhat.com> Message-ID: <5ec9637a-f834-3930-c15c-98329eaec2e2@redhat.com> On 31.05.2016 13:46, Martin Basti wrote: > > > On 31.05.2016 13:04, Martin Babinsky wrote: >> On 05/26/2016 04:52 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5915 >>> >>> Patches attached >>> >>> >>> >> ACK. >> > Even better patches attached. > > > > Wrong thread :D The original patches were pushed ipa-4-2: * c404d6586d6fd76d04bcf656b811b04f29704a41 Set proper zanata project-version * 776ef9ab63ee5bddc8ce0468570492b31180b70a Translations: remove deprecated locale configuration ipa-4-3: * 304bc038129229f6bd97e4415e6eec137f5fb3f8 Set proper zanata project-version * 67633d42bcd78dc44d2bdfb18597942b49734eee Translations: remove deprecated locale configuration master: * 204a18986a1923f75bc75215d20dfa2eb9229729 Translations: remove deprecated locale configuration -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue May 31 11:57:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 31 May 2016 13:57:01 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches In-Reply-To: References: Message-ID: <49fa67bc-5181-7cf2-738b-831839ea19a5@redhat.com> On 31.05.2016 12:44, Martin Babinsky wrote: > On 05/28/2016 01:17 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4995 >> >> Patches attached >> >> >> > > Hi, > > PATCH 0488: LGTM > > PATCH 0489: > > @@ -996,10 +997,10 @@ def check_deleted_segments(hostname, masters, > topo_errors, starting_host): > i = 0 > while True: > left = api.Command.topologysegment_find( > - suffix_name, iparepltoposegmentleftnode=hostname, > sizelimit=0 > + suffix_name, iparepltoposegmentleftnode=hostname, > sizelimit=0, > )['result'] > right = api.Command.topologysegment_find( > - suffix_name, iparepltoposegmentrightnode=hostname, > sizelimit=0 > + suffix_name, iparepltoposegmentrightnode=hostname, > sizelimit=0, > )['result'] > > it seems that you added 'no_members=True' there and then removed it > because reasons. Please revert the this part to the original code so > that it does not stick out. > Better (the right one) patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0488.2-Make-option-no-members-public-in-CLI.patch Type: text/x-patch Size: 1068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0489.2-Performance-Find-commands-do-not-process-members-by-.patch Type: text/x-patch Size: 87831 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 31 12:02:42 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 May 2016 14:02:42 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <5729E929.6010307@redhat.com> References: <5729E929.6010307@redhat.com> Message-ID: <11005494-67b0-92d5-36c0-cce718f61464@redhat.com> On 05/04/2016 02:20 PM, thierry bordaz wrote: > Hello, > > I have been doing some tests/measures using > https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. > The tool creates a set of typical users/hosts/groups... to import with a > ldapadd. > > I wrote down some finding in > http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. > I still have to do some cleanup around the performance but the basic of a > possible improvement is to do provisioning in several steps (disabling > plugins, provisioning, enabling plugin, running fixup tasks). > > Before going further in the design I wanted to share those ideas and know if > it raise any concern. > > thanks > thierry > Let me conclude the previous sub-thread and also continue with discussion we had over phone. The subthread ended with proposal to go with offline provisioning by disabling LDAP ports similar to ipa-server-upgrade tool and then using LDAPI to add records by using ipalib in server mode e.g., as in ipa_otptoken_import.py So these are the tasks to solve/investigate: 1. Provide guidance/write script which would disable memberof plugin and other plugins. Disable ldap and ldaps port 2. Provide guidance/script how to use ipalib in server mode and how to import date. This could be even script which would load file in some format(e.g. JSON) and executed commands from the file. Basically what was Alexander proposing and I was against it. After some thought, I agree that the tool could be easy to write but I'd rather avoid adding it to 4.4 release maybe even to future releases. Because: - It's almost the same as `[RFE] run multiple CLI commands in a batch` With the distinction that it connects directly LDAPI and not public API. First I'd like to see #5821 and then we can think of using same logic(input) to work in "migration" mode. - I don't want to include a quickly baked tool so late in 4.4 development. It will have design flaws which will be harder to fix later. I don't want to loose time with discussion about design of the tool in this phase of 4.4. 3. Provide guidance/script to revert #1 and run memberof fixup task. 4. Investigate how replication of so many records with member attributes will affect other replicas. I.e. if it would not brick entire topology. *Right now #4 seems to be the most important*. Then #1, #2, #3 could be delivered as sample script included in documentation and/or blog post/github. It would allow us to change it later. I would not focus on #2 before other core 4.4 items are finished. A lot of guidance is already written in tree design page but it will need to be transform to easily consumable form for admins. The scripts can be prepared even when 4.4 is out. In other words I would not create any official new ipa utility yet. -- Petr Vobornik From mbabinsk at redhat.com Tue May 31 12:08:00 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 31 May 2016 14:08:00 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches In-Reply-To: <49fa67bc-5181-7cf2-738b-831839ea19a5@redhat.com> References: <49fa67bc-5181-7cf2-738b-831839ea19a5@redhat.com> Message-ID: On 05/31/2016 01:57 PM, Martin Basti wrote: > > > On 31.05.2016 12:44, Martin Babinsky wrote: >> On 05/28/2016 01:17 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/4995 >>> >>> Patches attached >>> >>> >>> >> >> Hi, >> >> PATCH 0488: LGTM >> >> PATCH 0489: >> >> @@ -996,10 +997,10 @@ def check_deleted_segments(hostname, masters, >> topo_errors, starting_host): >> i = 0 >> while True: >> left = api.Command.topologysegment_find( >> - suffix_name, iparepltoposegmentleftnode=hostname, >> sizelimit=0 >> + suffix_name, iparepltoposegmentleftnode=hostname, >> sizelimit=0, >> )['result'] >> right = api.Command.topologysegment_find( >> - suffix_name, iparepltoposegmentrightnode=hostname, >> sizelimit=0 >> + suffix_name, iparepltoposegmentrightnode=hostname, >> sizelimit=0, >> )['result'] >> >> it seems that you added 'no_members=True' there and then removed it >> because reasons. Please revert the this part to the original code so >> that it does not stick out. >> > > Better (the right one) patches attached. ACK -- Martin^3 Babinsky From mbasti at redhat.com Tue May 31 12:10:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 31 May 2016 14:10:18 +0200 Subject: [Freeipa-devel] [PATCH 0488-0489] Perfomance: membership processing related patches In-Reply-To: References: <49fa67bc-5181-7cf2-738b-831839ea19a5@redhat.com> Message-ID: On 31.05.2016 14:08, Martin Babinsky wrote: > On 05/31/2016 01:57 PM, Martin Basti wrote: >> >> >> On 31.05.2016 12:44, Martin Babinsky wrote: >>> On 05/28/2016 01:17 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/4995 >>>> >>>> Patches attached >>>> >>>> >>>> >>> >>> Hi, >>> >>> PATCH 0488: LGTM >>> >>> PATCH 0489: >>> >>> @@ -996,10 +997,10 @@ def check_deleted_segments(hostname, masters, >>> topo_errors, starting_host): >>> i = 0 >>> while True: >>> left = api.Command.topologysegment_find( >>> - suffix_name, iparepltoposegmentleftnode=hostname, >>> sizelimit=0 >>> + suffix_name, iparepltoposegmentleftnode=hostname, >>> sizelimit=0, >>> )['result'] >>> right = api.Command.topologysegment_find( >>> - suffix_name, iparepltoposegmentrightnode=hostname, >>> sizelimit=0 >>> + suffix_name, iparepltoposegmentrightnode=hostname, >>> sizelimit=0, >>> )['result'] >>> >>> it seems that you added 'no_members=True' there and then removed it >>> because reasons. Please revert the this part to the original code so >>> that it does not stick out. >>> >> >> Better (the right one) patches attached. > > ACK > master: * 91572afc60f590f0d81ad18234189a0b48144bf5 Make option --no-members public in CLI * 5f42b42bd4557a669ab5cfcf1af6596f1a2535f1 Performance: Find commands: do not process members by default From npmccallum at redhat.com Tue May 31 12:49:46 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 31 May 2016 08:49:46 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <20160530160827.3rodv6htgn2dodeq@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> <20160530160827.3rodv6htgn2dodeq@redhat.com> Message-ID: <1464698986.11210.3.camel@redhat.com> On Mon, 2016-05-30 at 19:08 +0300, Alexander Bokovoy wrote: > On Mon, 30 May 2016, Petr Vobornik wrote: > > On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: > > > Pavel, since we made the change here from a StrEnum to a Str, we > > > need > > > to update the UI patch accordingly. > > > > How should admin know what to write there intuitively? > > > > Shouldn't Web UI or CLI advertise the indicators supported by IPA? > > E.g. > > CLI in doc string. Web UI might even combine checkboxes (otp, > > radius) > > with textbox. > That would be better, I think. We still need to keep the API with a > free > text field but Web UI, of course, should provide some pre-defined > labels. I *think* this means that this patch doesn't need any changes. Is that correct? If so, can I get a review? :) From pvoborni at redhat.com Tue May 31 13:25:21 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 May 2016 15:25:21 +0200 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <1464698986.11210.3.camel@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> <20160530160827.3rodv6htgn2dodeq@redhat.com> <1464698986.11210.3.camel@redhat.com> Message-ID: <250582ba-814e-79d0-7169-54198d0fa79f@redhat.com> On 05/31/2016 02:49 PM, Nathaniel McCallum wrote: > On Mon, 2016-05-30 at 19:08 +0300, Alexander Bokovoy wrote: >> On Mon, 30 May 2016, Petr Vobornik wrote: >>> On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: >>>> Pavel, since we made the change here from a StrEnum to a Str, we >>>> need >>>> to update the UI patch accordingly. >>> >>> How should admin know what to write there intuitively? >>> >>> Shouldn't Web UI or CLI advertise the indicators supported by IPA? >>> E.g. >>> CLI in doc string. Web UI might even combine checkboxes (otp, >>> radius) >>> with textbox. >> That would be better, I think. We still need to keep the API with a >> free >> text field but Web UI, of course, should provide some pre-defined >> labels. > > I *think* this means that this patch doesn't need any changes. Is that > correct? If so, can I get a review? :) > I meant that the param's 'doc' attribute can get the supported values. So that they would be shown in `ipa service-mod --help` Btw, the `required: false` and `multivalued: true` can be simplified into Str('krbprincipalauthind*') -- Petr Vobornik From ldoudova at redhat.com Tue May 31 13:30:46 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 31 May 2016 15:30:46 +0200 Subject: [Freeipa-devel] [Testplan] Thin client Message-ID: <5068918e-4233-98f5-60d3-311f253fdf3c@redhat.com> Hi all, here's [1] a draft of test plan for V4 RFE Thin client. Please review this and let me know if there's something missing or wrong. Thanks, Lenka [1] http://www.freeipa.org/page/V4/Thin_Client/Test_Plan From ldoudova at redhat.com Tue May 31 13:36:30 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 31 May 2016 15:36:30 +0200 Subject: [Freeipa-devel] [Testplan] Authentication indicators Message-ID: <4a4858a4-a0d2-8c64-c09c-5821539308f6@redhat.com> Hi all, here's [1] a draft of test plan for V4 RFE Authentication Indicators. Please review this and let me know if there's something missing or wrong. Thanks, Lenka [1] http://www.freeipa.org/page/V4/Authentication_Indicators/Test_Plan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue May 31 13:37:00 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 31 May 2016 15:37:00 +0200 Subject: [Freeipa-devel] Provisioning throughput In-Reply-To: <11005494-67b0-92d5-36c0-cce718f61464@redhat.com> References: <5729E929.6010307@redhat.com> <11005494-67b0-92d5-36c0-cce718f61464@redhat.com> Message-ID: <574D937C.4020602@redhat.com> On 05/31/2016 02:02 PM, Petr Vobornik wrote: > On 05/04/2016 02:20 PM, thierry bordaz wrote: >> Hello, >> >> I have been doing some tests/measures using >> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py. >> The tool creates a set of typical users/hosts/groups... to import with a >> ldapadd. >> >> I wrote down some finding in >> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins. >> I still have to do some cleanup around the performance but the basic of a >> possible improvement is to do provisioning in several steps (disabling >> plugins, provisioning, enabling plugin, running fixup tasks). >> >> Before going further in the design I wanted to share those ideas and know if >> it raise any concern. >> >> thanks >> thierry >> > Let me conclude the previous sub-thread and also continue with > discussion we had over phone. > > The subthread ended with proposal to go with offline provisioning by > disabling LDAP ports similar to ipa-server-upgrade tool and then using > LDAPI to add records by using ipalib in server mode e.g., as in > ipa_otptoken_import.py > > So these are the tasks to solve/investigate: > > 1. Provide guidance/write script which would disable memberof plugin and > other plugins. Disable ldap and ldaps port I started describing the operations http://www.freeipa.org/page/V4/Performance_Improvements#Algorithm. It needs to be updated with disabling regular ports and accessing through ldapi > > 2. Provide guidance/script how to use ipalib in server mode and how to > import date. This could be even script which would load file in some > format(e.g. JSON) and executed commands from the file. Basically what > was Alexander proposing and I was against it. After some thought, I > agree that the tool could be easy to write but I'd rather avoid adding > it to 4.4 release maybe even to future releases. Because: > - It's almost the same as `[RFE] run multiple CLI commands in a batch` > With the distinction that > it connects directly LDAPI and not public API. First I'd like to see > #5821 and then we can think of using same logic(input) to work in > "migration" mode. > - I don't want to include a quickly baked tool so late in 4.4 > development. It will have design flaws which will be harder to fix > later. I don't want to loose time with discussion about design of the > tool in this phase of 4.4. Investigating a ldap bulk load, there is a quite limited set of operations to prepare the instance, run a ldap bulk load and run fixup. However, starting yesterday looking at ipa-otptoken-import I am still unable to connect through ldapi and do those really simple operations... so even it could be easy to write tool my progress start slowly Regarding the batch commands, it looks quite different than bulk import because batch commands (like user-add) run several ldap ops (SRCH/ADD/MOD) and also batch commands does expect that DS plugins like memberof are enabled. > > 3. Provide guidance/script to revert #1 and run memberof fixup task. > > 4. Investigate how replication of so many records with member attributes > will affect other replicas. I.e. if it would not brick entire topology. > > *Right now #4 seems to be the most important*. This was shortly described in http://www.freeipa.org/page/V4/Performance_Improvements#Memberof_plugin and http://www.freeipa.org/page/V4/Performance_Improvements#Replication_being_late. The topology will slowly converge and eventually all provisioned entries will be available everywhere. But slowly can mean hours or even days before it converges. During that period, a provisioned rules can grant some rights on one replica (where it was imported) but will not grant it on an other where the rule is not yet replicated. If the topology is a production topology, it can be better to rely on total init of the replicas than on replication. > > Then #1, #2, #3 could be delivered as sample script included in > documentation and/or blog post/github. It would allow us to change it > later. I would not focus on #2 before other core 4.4 items are finished. > A lot of guidance is already written in tree design page but it will > need to be transform to easily consumable form for admins. The scripts > can be prepared even when 4.4 is out. > > In other words I would not create any official new ipa utility yet. From npmccallum at redhat.com Tue May 31 13:57:05 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 31 May 2016 09:57:05 -0400 Subject: [Freeipa-devel] [PATCH 0093] Enable service authentication indicator management In-Reply-To: <250582ba-814e-79d0-7169-54198d0fa79f@redhat.com> References: <1464362755.3425.7.camel@redhat.com> <20160527153505.4627dvyqdwqwbyuf@redhat.com> <1464364503.3425.13.camel@redhat.com> <1464364830.3425.14.camel@redhat.com> <20160530160827.3rodv6htgn2dodeq@redhat.com> <1464698986.11210.3.camel@redhat.com> <250582ba-814e-79d0-7169-54198d0fa79f@redhat.com> Message-ID: <1464703025.11210.28.camel@redhat.com> On Tue, 2016-05-31 at 15:25 +0200, Petr Vobornik wrote: > On 05/31/2016 02:49 PM, Nathaniel McCallum wrote: > > On Mon, 2016-05-30 at 19:08 +0300, Alexander Bokovoy wrote: > > > On Mon, 30 May 2016, Petr Vobornik wrote: > > > > On 05/27/2016 06:00 PM, Nathaniel McCallum wrote: > > > > > Pavel, since we made the change here from a StrEnum to a Str, > > > > > we > > > > > need > > > > > to update the UI patch accordingly. > > > > > > > > How should admin know what to write there intuitively? > > > > > > > > Shouldn't Web UI or CLI advertise the indicators supported by > > > > IPA? > > > > E.g. > > > > CLI in doc string. Web UI might even combine checkboxes (otp, > > > > radius) > > > > with textbox. > > > That would be better, I think. We still need to keep the API with > > > a > > > free > > > text field but Web UI, of course, should provide some pre-defined > > > labels. > > > > I *think* this means that this patch doesn't need any changes. Is > > that > > correct? If so, can I get a review? :) > > > > I meant that the param's 'doc' attribute can get the supported > values. > So that they would be shown in `ipa service-mod --help` > > Btw, the `required: false` and `multivalued: true` can be simplified > into Str('krbprincipalauthind*') I fixed the doc string as well as the verbosity. I also rebased against the current master. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0093-Enable-service-authentication-indicator-management.patch Type: text/x-patch Size: 5102 bytes Desc: not available URL: From slaznick at redhat.com Tue May 31 14:32:39 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 31 May 2016 16:32:39 +0200 Subject: [Freeipa-devel] [PATCH 0033] Fix CA being presented as running even if it weren't In-Reply-To: <654f3bb1-384d-e914-c7fc-67647558b0d0@redhat.com> References: <4967dac0-c475-17da-45b5-399da32e545c@redhat.com> <651ee173-8f3d-b01f-7bf5-9d1f67dab451@redhat.com> <07c4d154-954f-eee0-127c-3574ceab7435@redhat.com> <654f3bb1-384d-e914-c7fc-67647558b0d0@redhat.com> Message-ID: On 05/31/2016 11:40 AM, Stanislav Laznicka wrote: > On 05/31/2016 10:22 AM, Stanislav Laznicka wrote: >> On 05/30/2016 12:54 PM, Jan Cholasta wrote: >>> On 30.5.2016 12:36, Martin Basti wrote: >>>> >>>> >>>> On 26.05.2016 19:31, Stanislav Laznicka wrote: >>>>> >>>>> Self NACK. I should not post patches when tired, sorry. Minor fix is >>>>> attached. >>>>> >>>>> >>>>> On 05/26/2016 07:21 PM, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> Please, see the attached patch. Fixes >>>>>> https://fedorahosted.org/freeipa/ticket/5898 >>>>>> >>>>>> Standa >>>>>> >>>>> >>>> >>>> LGTM, if nobody is against this, I will push it in 2 days >>> >>> NACK, please add `wait` argument and call self.wait_until_running(), >>> same as in start() and restart(). >>> >> A pretty good point, please see the modified patch. > Self.NACK - can't add 'wait' agrument to service.Service.is_running > this easy. > Should be fixed now. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0033-4-Fixes-CA-always-being-presented-as-running.patch Type: text/x-patch Size: 3325 bytes Desc: not available URL: From slaznick at redhat.com Tue May 31 15:10:12 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 31 May 2016 17:10:12 +0200 Subject: [Freeipa-devel] [PATCH 0038] Reduced time for IO blocking of DS Message-ID: <655db353-b7f2-cee7-3cff-2635ee6bd523@redhat.com> Hello, This is a fix to https://fedorahosted.org/freeipa/ticket/5383. From the comments I am not sure if nsslapd-idletimeout should be reduced as well. If so, could you please propose a value that you find reasonable? Thanks, Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0038-Decreased-timeout-for-IO-blocking-for-DS.patch Type: text/x-patch Size: 945 bytes Desc: not available URL: From pvoborni at redhat.com Tue May 31 16:07:52 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 May 2016 18:07:52 +0200 Subject: [Freeipa-devel] [Testplan] Thin client In-Reply-To: <5068918e-4233-98f5-60d3-311f253fdf3c@redhat.com> References: <5068918e-4233-98f5-60d3-311f253fdf3c@redhat.com> Message-ID: <6e123456-c1d2-32fb-18ca-1d41f244fbaf@redhat.com> On 05/31/2016 03:30 PM, Lenka Doudova wrote: > Hi all, > > here's [1] a draft of test plan for V4 RFE Thin client. > > Please review this and let me know if there's something missing or wrong. > > > Thanks, > > Lenka > > > [1] http://www.freeipa.org/page/V4/Thin_Client/Test_Plan > Hi Lenka, It is implied, but somewhere should be mentioned that "the command" is a command of IPA CLI - `ipa`. E.g. once in overview. Missing: Install 4.4 client against newer server, e.g. non-existant 4.5. Could be simulated. I'm not sure if API version file is still relevant here. Maybe it could be simulated by adding custom plugin which would automatically change version hash (assuming it was implemented that way, if not, please correct me). -- Petr Vobornik From pvoborni at redhat.com Tue May 31 16:20:38 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 May 2016 18:20:38 +0200 Subject: [Freeipa-devel] [Testplan Review] Server Roles In-Reply-To: <5745B341.1090808@redhat.com> References: <5745B341.1090808@redhat.com> Message-ID: <7b6fd5ae-0338-94d1-0188-6635a845e908@redhat.com> On 05/25/2016 04:14 PM, Oleg Fayans wrote: > Hi guys. Here is a rather schematic (as neither the feature not the > design document is not complete) of the server roles testplan. Could you > please review it and tell me what is missing? > > http://www.freeipa.org/page/V4/Server_Roles/Test_Plan > Note: I've not done thorough review. 1. you have wrong command for showing and setting renewal master. It's done using config-mod|show Today the design page[1] got an update, but still, I think it was there even before. 2. Roles will be also shown in dnsconfig-show, trustconfig-show, vaultconfig-show commands. [1] http://www.freeipa.org/page/V4/Server_Roles -- Petr Vobornik From pvoborni at redhat.com Tue May 31 16:36:35 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 May 2016 18:36:35 +0200 Subject: [Freeipa-devel] [Testplan Review] In-Reply-To: <5742B00F.4090509@redhat.com> References: <573D97BE.8020202@redhat.com> <15def057-454b-8fe1-7e93-0e63d81c2a62@redhat.com> <5742B00F.4090509@redhat.com> Message-ID: On 05/23/2016 09:23 AM, Oleg Fayans wrote: > Hi Petr, > > The test plan is updated. Thanks, is it possible to number test cases? It is hard to refer to them without copying the full name. 1. first test case: `ipa host-find` will show the host entry, but cert will be revoked and kerb key removed 2. "Test case: server_del API call is executed at ipa-server-install --uninstall on the replica under domain " In dom. lvl 1(after step 3), checks/output from first test case should apply here + server should be uninstalled. 3. *-ruv subcommands of ipa-replica-manage are extended to handle CA-specific RUVs I'll assume that '97' is just an example. It might be different. It is possible that step 3 will fail - it's racy. 4. Last test case with the "autogenerated" placeholder is not much important - so only if you have nothing more important to do. Web UI will get interactive add of segments + some other improvements in a topology graph but I don't know if it can be tested easily. > > On 05/19/2016 12:54 PM, Petr Vobornik wrote: >> On 05/19/2016 12:38 PM, Oleg Fayans wrote: >>> Hi all, >>> >>> I've created the first versio of the testplan for Topology Management >>> feature in 4.4 release: >>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>> >>> Could someone please review it? >>> >> >> I'll mention what are the important parts. >> >> 1. In the 3 scenarios, the most important one is testing the >> `ipa-server-install --uninstall`. There it is more important to check >> whether it did the same as `ipa-csreplica-manage del`, >> `ipa-replica-manage del` and `ipa-server-install --uninstall` procedure. >> Which means removal of master entry, DNS records, Kerberos keys, >> revocation of certificates... Checking RUVs is not the critical part. >> >> 2. I miss test for move of `ipa-replica-manage set-renewal-master` to API > > Isn't it more related to the server roles feature? Will it be one of the > ipa server* commands? True > >> >> 3. test of new `ipa server-del` method >> >> when these three are done then I'd focus on RUVs >> > -- Petr Vobornik From rharwood at redhat.com Tue May 31 17:19:55 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Tue, 31 May 2016 13:19:55 -0400 Subject: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf In-Reply-To: <20160528203855.yoyipbmpkej2pxkc@redhat.com> References: <20160528042451.lewcj5jnicq2noxd@redhat.com> <20160528203855.yoyipbmpkej2pxkc@redhat.com> Message-ID: Alexander Bokovoy writes: > On Sat, 28 May 2016, Robbie Harwood wrote: >> Alexander Bokovoy writes: >>> On Fri, 27 May 2016, Robbie Harwood wrote: >>>> Stanislav Laznicka writes: >>>>> From: Stanislav Laznicka >>>>> >>>>> The include of /etc/krb5.conf.d/ is required for crypto-policies >>>>> to work properly >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5912 >>>> >>>> Thank you for working on this. Is the intent on the part of >>>> FreeIPA to keep a separate, freeipa-speicifc directory? And if so, >>>> can I suggest that we not do that? >>> >>> SSSD cannot write to /etc and I don't think we have to change it. >> >> Can you elaborate on this? Why can't sssd write the stuff it puts in >> /var/lib into /etc, or symlink it? > > Writing to /etc is considered a privilege of a system administrator. A > runtime override is typically done outside it, in /run like systemd > allows for its configuration for volatile setups and in /var/lib > for non-volatile ones. The latter has long been a state of affairs in > Linux. > > Currently SSSD runs under root but it is already made possible to run as > non-root user and we intend to switch to that mode in future releases. I guess I don't see a meaningful difference here. We're still writing to /etc when we modify krb5.conf. My reading of the FHS is that this is not an intended use of /var/lib: /var/lib is for state information [0], and the only time the FHS mentions config files is to point out that they go in the /etc tree. Anyway, I've said my piece and won't derail this further. If you want to merge, this is a cosmetic issue and I can live with it. [0]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: