From sbose at redhat.com Mon Jul 1 14:38:17 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 1 Jul 2013 16:38:17 +0200 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs Message-ID: <20130701143817.GK27655@localhost.localdomain> Hi, this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only to allow SSSD running on a FreeIPA server to access the AD LDAP server. In the ticket a more generic solution is described but since there is no other use case so far I think this patch is sufficient for the time being. bye, Sumit -------------- next part -------------- From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 1 Jul 2013 13:47:22 +0200 Subject: [PATCH] Add PAC to master host TGTs For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server of a trusted domain with the credentials of a FreeIPA server host a PAC must be added to the TGT for the host. We use the well know RID for the Domain Computers group for the primary gid element of the PAC, this is the same as AD uses for host tickets. The rid element of the PAC is set to the well know RID of the Domain Controllers group. This is working for the SSSD use case but might be improved later for more general use cases. To determine if a host is a FreeIPA server or not it is checked if there is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately this requires an additional LDAP lookup. But since TGS-REQs for hosts should be rare I think it is acceptable for the time being. Fixes https://fedorahosted.org/freeipa/ticket/3651 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 154 ++++++++++++++++++++++++++++++---------- 1 file changed, 115 insertions(+), 39 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 2662b947bd589074faa1acf6a9bb97748161cb05..92dc8dd7fa6c51d9edfc4d73cef23b3129c01192 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -58,6 +58,7 @@ static char *user_pac_attrs[] = { "objectClass", "uid", "cn", + "fqdn", "gidNumber", "krbPrincipalName", "krbCanonicalName", @@ -358,6 +359,29 @@ static int sid_split_rid(struct dom_sid *sid, uint32_t *rid) return 0; } +static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn) +{ + int ret; + char *master_host_base = NULL; + LDAPMessage *result = NULL; + krb5_error_code err; + + ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", + fqdn, ipactx->base); + if (ret == -1) { + return false; + } + err = ipadb_simple_search(ipactx, master_host_base, LDAP_SCOPE_BASE, + NULL, NULL, &result); + free(master_host_base); + ldap_msgfree(result); + if (err == 0) { + return true; + } + + return false; +} + static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, LDAPMessage *lentry, TALLOC_CTX *memctx, @@ -371,13 +395,65 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, char *strres; int intres; int ret; + char **objectclasses = NULL; + size_t c; + bool is_host = false; + bool is_user = false; - ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); - if (ret) { - /* gidNumber is mandatory */ - return ret; + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "objectClass", + &objectclasses); + if (ret == 0 && objectclasses != NULL) { + for (c = 0; objectclasses[c] != NULL; c++) { + if (strcasecmp(objectclasses[c], "ipaHost") == 0) { + is_host = true; + } + if (strcasecmp(objectclasses[c], "ipaNTUserAttrs") == 0) { + is_user = true; + } + free(objectclasses[c]); + } + } + free(objectclasses); + + if (!is_host && !is_user) { + /* We only handle users and hosts */ + return ENOENT; + } + + if (is_host) { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "fqdn", &strres); + if (ret) { + /* fqdn is mandatory for hosts */ + return ret; + } + + /* Currently we only add a PAC to TGTs for IPA servers to allow SSSD in + * ipa_server_mode to access the AD LDAP server */ + if (!is_master_host(ipactx, strres)) { + free(strres); + return ENOENT; + } + } else { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); + if (ret) { + /* uid is mandatory */ + return ret; + } + } + + info3->base.account_name.string = talloc_strdup(memctx, strres); + free(strres); + + if (is_host) { + prigid = 515; /* Well known RID for domain computers group */ + } else { + ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); + if (ret) { + /* gidNumber is mandatory */ + return ret; + } + prigid = intres; } - prigid = intres; info3->base.logon_time = 0; /* do not have this info yet */ @@ -419,15 +495,6 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.allow_password_change = 0; info3->base.force_password_change = -1; - /* FIXME: handle computer accounts they do not use 'uid' */ - ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); - if (ret) { - /* uid is mandatory */ - return ret; - } - info3->base.account_name.string = talloc_strdup(memctx, strres); - free(strres); - ret = ipadb_ldap_attr_to_str(lcontext, lentry, "cn", &strres); switch (ret) { case 0: @@ -500,21 +567,25 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.logon_count = 0; /* we do not have this info yet */ info3->base.bad_password_count = 0; /* we do not have this info yet */ - ret = ipadb_ldap_attr_to_str(lcontext, lentry, - "ipaNTSecurityIdentifier", &strres); - if (ret) { - /* SID is mandatory */ - return ret; - } - ret = string_to_sid(strres, &sid); - free(strres); - if (ret) { - return ret; - } - - ret = sid_split_rid(&sid, &info3->base.rid); - if (ret) { - return ret; + if (is_host) { + /* Well know RID of domain controllers group */ + info3->base.rid = 516; + } else { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, + "ipaNTSecurityIdentifier", &strres); + if (ret) { + /* SID is mandatory */ + return ret; + } + ret = string_to_sid(strres, &sid); + free(strres); + if (ret) { + return ret; + } + ret = sid_split_rid(&sid, &info3->base.rid); + if (ret) { + return ret; + } } ret = ipadb_ldap_deref_results(lcontext, lentry, &deref_results); @@ -587,11 +658,15 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } if (info3->base.primary_gid == 0) { - if (ipactx->mspac->fallback_rid) { - info3->base.primary_gid = ipactx->mspac->fallback_rid; + if (is_host) { + info3->base.primary_gid = 515; /* Well known RID for domain computers group */ } else { - /* can't give a pack without a primary group rid */ - return ENOENT; + if (ipactx->mspac->fallback_rid) { + info3->base.primary_gid = ipactx->mspac->fallback_rid; + } else { + /* can't give a pack without a primary group rid */ + return ENOENT; + } } } @@ -623,8 +698,13 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, return ENOENT; } - /* we got the domain SID for the user sid */ - info3->base.domain_sid = talloc_memdup(memctx, &sid, sizeof(sid)); + if (is_host) { + info3->base.domain_sid = talloc_memdup(memctx, &ipactx->mspac->domsid, + sizeof(ipactx->mspac->domsid)); + } else { + /* we got the domain SID for the user sid */ + info3->base.domain_sid = talloc_memdup(memctx, &sid, sizeof(sid)); + } /* always zero out, not used for Krb, only NTLM */ memset(&info3->base.LMSessKey, '\0', sizeof(info3->base.key)); @@ -666,10 +746,6 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, return EINVAL; } - if (!ied->ipa_user) { - return 0; - } - tmpctx = talloc_new(NULL); if (!tmpctx) { return ENOMEM; -- 1.8.1.4 From npmccallum at redhat.com Mon Jul 1 15:05:39 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 01 Jul 2013 11:05:39 -0400 Subject: [Freeipa-devel] [PATCH] Permit reads to ipatokenRadiusProxyUser objects In-Reply-To: <51C2D7A7.5070006@redhat.com> References: <1371580050.23980.20.camel@localhost.localdomain> <51C2D7A7.5070006@redhat.com> Message-ID: <1372691139.2261.1.camel@localhost.localdomain> On Thu, 2013-06-20 at 12:21 +0200, Martin Kosek wrote: > On 06/18/2013 08:27 PM, Nathaniel McCallum wrote: > > Patch attached. > > > > Hello Nathaniel, > > Thanks for the patch! I have just few general procedural comments with > submitting patch: > > 1. As you are doing a work on an upstream ticket, please assign the upstream > Trac ticket to yourself and accept it. When the patch is sent to the list, you > should also mark the ticket as "patch sent". > > 2. Please follow our patch format: > - https://fedorahosted.org/freeipa/wiki/PatchFormat > > This is just a short excerpt of our Development process: > http://www.freeipa.org/page/Contribute#Development_Process Patch is attached with proper formatting. The ticket is properly assigned and flagged. No code has changed since the last patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0009-Permit-reads-to-ipatokenRadiusProxyUser-objects.patch Type: text/x-patch Size: 3695 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jul 3 10:00:43 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Jul 2013 13:00:43 +0300 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130701143817.GK27655@localhost.localdomain> References: <20130701143817.GK27655@localhost.localdomain> Message-ID: <20130703100043.GA12345@leiri.espoo.7ia.org> On Mon, 01 Jul 2013, Sumit Bose wrote: >Hi, > >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only >to allow SSSD running on a FreeIPA server to access the AD LDAP server. >In the ticket a more generic solution is described but since there is no >other use case so far I think this patch is sufficient for the time >being. > >bye, >Sumit >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 >From: Sumit Bose >Date: Mon, 1 Jul 2013 13:47:22 +0200 >Subject: [PATCH] Add PAC to master host TGTs > >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server >of a trusted domain with the credentials of a FreeIPA server host a >PAC must be added to the TGT for the host. s/SALS/SASL/ >To determine if a host is a FreeIPA server or not it is checked if there >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately >this requires an additional LDAP lookup. But since TGS-REQs for hosts >should be rare I think it is acceptable for the time being. I think it is better to change this lookup to "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would explicitly limit us to the IPA masters running AD trusts. >+static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn) >+{ >+ int ret; >+ char *master_host_base = NULL; >+ LDAPMessage *result = NULL; >+ krb5_error_code err; >+ >+ ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", >+ fqdn, ipactx->base); here: "cn=ADTRUST,cn=%s,cn=masters,cn=ipa,cn=etc,%s" >+ if (is_host) { >+ prigid = 515; /* Well known RID for domain computers group */ Could you please mention this fact in the commit message as well? >+ if (is_host) { >+ /* Well know RID of domain controllers group */ >+ info3->base.rid = 516; Same here. -- / Alexander Bokovoy From sbose at redhat.com Wed Jul 3 12:53:55 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 3 Jul 2013 14:53:55 +0200 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130703100043.GA12345@leiri.espoo.7ia.org> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> Message-ID: <20130703125355.GO27655@localhost.localdomain> On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: > On Mon, 01 Jul 2013, Sumit Bose wrote: > >Hi, > > > >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only > >to allow SSSD running on a FreeIPA server to access the AD LDAP server. > >In the ticket a more generic solution is described but since there is no > >other use case so far I think this patch is sufficient for the time > >being. > > > >bye, > >Sumit > > >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 > >From: Sumit Bose > >Date: Mon, 1 Jul 2013 13:47:22 +0200 > >Subject: [PATCH] Add PAC to master host TGTs > > > >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is > >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server > >of a trusted domain with the credentials of a FreeIPA server host a > >PAC must be added to the TGT for the host. > s/SALS/SASL/ Thank you for the review, I've fixed the typo and added the numerical values for the well-known RIDs to the commit message. > > > >To determine if a host is a FreeIPA server or not it is checked if there > >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately > >this requires an additional LDAP lookup. But since TGS-REQs for hosts > >should be rare I think it is acceptable for the time being. > I think it is better to change this lookup to > "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would > explicitly limit us to the IPA masters running AD trusts. I'm not sure if this restriction is needed. With SSSD's ipa_server_mode any IPA master (which networkwise can access an AD server of the trusted domain) can read AD user and group data, no running smbd or winbind is required. So it would be possible to run the extdom plugin or the compat plugin for the legacy clients on any IPA server which would allow a much better load balancing. If there are other concerns I'm happy to add the restriction. bye, Sumit > > >+static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn) > >+{ > >+ int ret; > >+ char *master_host_base = NULL; > >+ LDAPMessage *result = NULL; > >+ krb5_error_code err; > >+ > >+ ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", > >+ fqdn, ipactx->base); > here: "cn=ADTRUST,cn=%s,cn=masters,cn=ipa,cn=etc,%s" > > >+ if (is_host) { > >+ prigid = 515; /* Well known RID for domain computers group */ > Could you please mention this fact in the commit message as well? > > >+ if (is_host) { > >+ /* Well know RID of domain controllers group */ > >+ info3->base.rid = 516; > Same here. > > > > -- > / Alexander Bokovoy -------------- next part -------------- From 76b1be5d8331c92e5837e6e0f7f19fab2876be9b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 1 Jul 2013 13:47:22 +0200 Subject: [PATCH] Add PAC to master host TGTs For a proper SASL bind with GSSAPI against an AD LDAP server a PAC is needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server of a trusted domain with the credentials of a FreeIPA server host a PAC must be added to the TGT for the host. We use the well know RID of the Domain Computers group (515) for the primary gid element of the PAC, this is the same as AD uses for host tickets. The rid element of the PAC is set to the well know RID of the Domain Controllers group (516). This is working for the SSSD use case but might be improved later for more general use cases. To determine if a host is a FreeIPA server or not it is checked if there is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately this requires an additional LDAP lookup. But since TGS-REQs for hosts should be rare I think it is acceptable for the time being. Fixes https://fedorahosted.org/freeipa/ticket/3651 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 154 ++++++++++++++++++++++++++++++---------- 1 file changed, 115 insertions(+), 39 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 2662b947bd589074faa1acf6a9bb97748161cb05..92dc8dd7fa6c51d9edfc4d73cef23b3129c01192 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -58,6 +58,7 @@ static char *user_pac_attrs[] = { "objectClass", "uid", "cn", + "fqdn", "gidNumber", "krbPrincipalName", "krbCanonicalName", @@ -358,6 +359,29 @@ static int sid_split_rid(struct dom_sid *sid, uint32_t *rid) return 0; } +static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn) +{ + int ret; + char *master_host_base = NULL; + LDAPMessage *result = NULL; + krb5_error_code err; + + ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", + fqdn, ipactx->base); + if (ret == -1) { + return false; + } + err = ipadb_simple_search(ipactx, master_host_base, LDAP_SCOPE_BASE, + NULL, NULL, &result); + free(master_host_base); + ldap_msgfree(result); + if (err == 0) { + return true; + } + + return false; +} + static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, LDAPMessage *lentry, TALLOC_CTX *memctx, @@ -371,13 +395,65 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, char *strres; int intres; int ret; + char **objectclasses = NULL; + size_t c; + bool is_host = false; + bool is_user = false; - ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); - if (ret) { - /* gidNumber is mandatory */ - return ret; + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "objectClass", + &objectclasses); + if (ret == 0 && objectclasses != NULL) { + for (c = 0; objectclasses[c] != NULL; c++) { + if (strcasecmp(objectclasses[c], "ipaHost") == 0) { + is_host = true; + } + if (strcasecmp(objectclasses[c], "ipaNTUserAttrs") == 0) { + is_user = true; + } + free(objectclasses[c]); + } + } + free(objectclasses); + + if (!is_host && !is_user) { + /* We only handle users and hosts */ + return ENOENT; + } + + if (is_host) { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "fqdn", &strres); + if (ret) { + /* fqdn is mandatory for hosts */ + return ret; + } + + /* Currently we only add a PAC to TGTs for IPA servers to allow SSSD in + * ipa_server_mode to access the AD LDAP server */ + if (!is_master_host(ipactx, strres)) { + free(strres); + return ENOENT; + } + } else { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); + if (ret) { + /* uid is mandatory */ + return ret; + } + } + + info3->base.account_name.string = talloc_strdup(memctx, strres); + free(strres); + + if (is_host) { + prigid = 515; /* Well known RID for domain computers group */ + } else { + ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); + if (ret) { + /* gidNumber is mandatory */ + return ret; + } + prigid = intres; } - prigid = intres; info3->base.logon_time = 0; /* do not have this info yet */ @@ -419,15 +495,6 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.allow_password_change = 0; info3->base.force_password_change = -1; - /* FIXME: handle computer accounts they do not use 'uid' */ - ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); - if (ret) { - /* uid is mandatory */ - return ret; - } - info3->base.account_name.string = talloc_strdup(memctx, strres); - free(strres); - ret = ipadb_ldap_attr_to_str(lcontext, lentry, "cn", &strres); switch (ret) { case 0: @@ -500,21 +567,25 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.logon_count = 0; /* we do not have this info yet */ info3->base.bad_password_count = 0; /* we do not have this info yet */ - ret = ipadb_ldap_attr_to_str(lcontext, lentry, - "ipaNTSecurityIdentifier", &strres); - if (ret) { - /* SID is mandatory */ - return ret; - } - ret = string_to_sid(strres, &sid); - free(strres); - if (ret) { - return ret; - } - - ret = sid_split_rid(&sid, &info3->base.rid); - if (ret) { - return ret; + if (is_host) { + /* Well know RID of domain controllers group */ + info3->base.rid = 516; + } else { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, + "ipaNTSecurityIdentifier", &strres); + if (ret) { + /* SID is mandatory */ + return ret; + } + ret = string_to_sid(strres, &sid); + free(strres); + if (ret) { + return ret; + } + ret = sid_split_rid(&sid, &info3->base.rid); + if (ret) { + return ret; + } } ret = ipadb_ldap_deref_results(lcontext, lentry, &deref_results); @@ -587,11 +658,15 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } if (info3->base.primary_gid == 0) { - if (ipactx->mspac->fallback_rid) { - info3->base.primary_gid = ipactx->mspac->fallback_rid; + if (is_host) { + info3->base.primary_gid = 515; /* Well known RID for domain computers group */ } else { - /* can't give a pack without a primary group rid */ - return ENOENT; + if (ipactx->mspac->fallback_rid) { + info3->base.primary_gid = ipactx->mspac->fallback_rid; + } else { + /* can't give a pack without a primary group rid */ + return ENOENT; + } } } @@ -623,8 +698,13 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, return ENOENT; } - /* we got the domain SID for the user sid */ - info3->base.domain_sid = talloc_memdup(memctx, &sid, sizeof(sid)); + if (is_host) { + info3->base.domain_sid = talloc_memdup(memctx, &ipactx->mspac->domsid, + sizeof(ipactx->mspac->domsid)); + } else { + /* we got the domain SID for the user sid */ + info3->base.domain_sid = talloc_memdup(memctx, &sid, sizeof(sid)); + } /* always zero out, not used for Krb, only NTLM */ memset(&info3->base.LMSessKey, '\0', sizeof(info3->base.key)); @@ -666,10 +746,6 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, return EINVAL; } - if (!ied->ipa_user) { - return 0; - } - tmpctx = talloc_new(NULL); if (!tmpctx) { return ENOMEM; -- 1.8.1.4 From sbose at redhat.com Wed Jul 3 15:17:13 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 3 Jul 2013 17:17:13 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls Message-ID: <20130703151713.GQ27655@localhost.localdomain> Hi, with this patch the extdom plugin, the LDAP extended operation that allows IPA clients with recent SSSD to lookup AD users and groups, will not use winbind for the lookup anymore but will use SSSD running in ipa_server_mode. Since now no plugin uses the winbind client libraries anymore, the second patch removes the related configures checks. I think for the time being we cannot remove winbind completely because it might be needed for msbd to work properly in a trusted environment. bye, Sumit -------------- next part -------------- From 14c5947a73a7c61de2b71b338ce1c7c1f6771f13 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 3 Jul 2013 14:27:14 +0200 Subject: [PATCH 117/118] extdom: replace winbind calls with POSIX/SSSD calls With the new ipa_server_mode SSSD is able to read user and group data from trusted AD domains directly and makes this data available via the NSS responder. With this mode enabled winbind is not needed anymore to lookup users and groups of trusted domains. This patch removed the calls to winbind from the extdom plugin and replaces them with standard POSIX calls like getpwnam() and calls from libsss_nss_idmap to lookup SIDs. Fixes https://fedorahosted.org/freeipa/ticket/3637 because now the extdom plugin does not need to handle idranges anymore, but everything is done inside SSSD. --- daemons/configure.ac | 1 + .../ipa-slapi-plugins/ipa-extdom-extop/Makefile.am | 6 +- .../ipa-extdom-extop/ipa_extdom.h | 34 +- .../ipa-extdom-extop/ipa_extdom_common.c | 505 +++++++++------------ .../ipa-extdom-extop/ipa_extdom_extop.c | 4 +- .../ipa-extdom-extop/ipa_extdom_tests.c | 12 +- 6 files changed, 261 insertions(+), 301 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index 21d4e7a77c98e3dc7c630724b1124f1c213d0e6f..62722d554a685e6a13642fb7171a62f7a4e38fda 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -240,6 +240,7 @@ dnl -- dirsrv is needed for the extdom unit tests -- PKG_CHECK_MODULES([DIRSRV], [dirsrv >= 1.3.0]) dnl -- sss_idmap is needed by the extdom exop -- PKG_CHECK_MODULES([SSSIDMAP], [sss_idmap]) +PKG_CHECK_MODULES([SSSNSSIDMAP], [sss_nss_idmap]) dnl --------------------------------------------------------------------------- dnl - Check for systemd unit directory diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am index 67b556a4ac6e2ca8ef72901c0d9bcaef428aeca0..df0c30562f09bf0e29464c9bb05f7befbd3997e1 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am @@ -15,9 +15,9 @@ AM_CPPFLAGS = \ -DDATADIR=\""$(datadir)"\" \ $(AM_CFLAGS) \ $(LDAP_CFLAGS) \ - $(WBCLIENT_CFLAGS) \ $(WARN_CFLAGS) \ $(SSSIDMAP_CFLAGS) \ + $(SSSNSSIDMAP_CFLAGS) \ $(NULL) plugindir = $(libdir)/dirsrv/plugins @@ -34,8 +34,8 @@ libipa_extdom_extop_la_LDFLAGS = -avoid-version libipa_extdom_extop_la_LIBADD = \ $(LDAP_LIBS) \ - $(WBCLIENT_LIBS) \ $(SSSIDMAP_LIBS) \ + $(SSSNSSIDMAP_LIBS) \ $(NULL) if HAVE_CHECK @@ -54,9 +54,9 @@ extdom_tests_LDFLAGS = \ extdom_tests_LDADD = \ $(CHECK_LIBS) \ $(LDAP_LIBS) \ - $(WBCLIENT_LIBS) \ $(DIRSRV_LIBS) \ $(SSSIDMAP_LIBS) \ + $(SSSNSSIDMAP_LIBS) \ $(NULL) appdir = $(IPA_DATA_DIR) 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 5c2eeddceb3983fa5793c1a7fa86c5001c47beba..5f834a047a579104cd2589ce417c580c1c5388d3 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -53,14 +53,15 @@ #include #include #include - -#include +#include +#include #include #include #include #include +#include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" @@ -114,18 +115,18 @@ struct extdom_res { union { char *sid; struct { - const char *domain_name; - const char *object_name; + char *domain_name; + char *object_name; } name; struct { - const char *domain_name; - const char *user_name; + char *domain_name; + char *user_name; uid_t uid; gid_t gid; } user; struct { - const char *domain_name; - const char *group_name; + char *domain_name; + char *group_name; gid_t gid; } group; } data; @@ -143,12 +144,21 @@ struct domain_info { struct sss_idmap_ctx *idmap_ctx; }; +struct pwd_grp { + enum sss_id_type id_type; + union { + struct passwd pwd; + struct group grp; + } data; +}; + int parse_request_data(struct berval *req_val, struct extdom_req **_req); +void free_req_data(struct extdom_req *req); int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, struct extdom_res **res); -int create_response(struct extdom_req *req, struct domain_info *domain_info, - const char *domain_name, - const char *name, struct wbcDomainSid *sid, - enum wbcSidType name_type, struct extdom_res **_res); +int create_response(struct extdom_req *req, struct pwd_grp *pg_data, + const char *sid_str, enum sss_id_type id_type, + const char *domain_name, struct extdom_res **_res); +void free_resp_data(struct extdom_res *res); int pack_response(struct extdom_res *res, struct berval **ret_val); #endif /* _IPA_EXTDOM_H_ */ 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 b6136ee78cb75b37d2dcf16bd1b0e7871f5f1d84..8aa22e1258a703b762236c5107a389a76b2268ee 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 @@ -47,6 +47,8 @@ #include "ipa_extdom.h" #include "util.h" +#define MAX(a,b) (((a)>(b))?(a):(b)) + int parse_request_data(struct berval *req_val, struct extdom_req **_req) { BerElement *ber = NULL; @@ -151,291 +153,194 @@ int parse_request_data(struct berval *req_val, struct extdom_req **_req) return LDAP_SUCCESS; } -static void free_domain_info(struct domain_info *domain_info) +void free_req_data(struct extdom_req *req) { - if (domain_info == NULL) { + if (req == NULL) { return; } - sss_idmap_free(domain_info->idmap_ctx); - slapi_ch_free((void **) &domain_info->guid); - slapi_ch_free((void **) &domain_info->sid); - slapi_ch_free((void **) &domain_info->flat_name); - free(domain_info); -} - -static int set_domain_range(struct ipa_extdom_ctx *ctx, const char *dom_sid_str, - struct sss_idmap_range *range) -{ - Slapi_PBlock *pb = NULL; - Slapi_Entry **e = NULL; - char *filter = NULL; - int ret; - unsigned long ulong_val; - - pb = slapi_pblock_new(); - if (pb == NULL) { - return ENOMEM; - } - - ret = asprintf(&filter, "(&(ipaNTTrustedDomainSID=%s)" \ - "(objectclass=ipaTrustedADDomainRange))", - dom_sid_str); - if (ret == -1) { - ret = ENOMEM; - goto done; - } - - slapi_search_internal_set_pb(pb, ctx->base_dn, - LDAP_SCOPE_SUBTREE, filter, - NULL, 0, NULL, NULL, ctx->plugin_id, 0); - - slapi_search_internal_pb(pb); - slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &ret); - - if (ret != EOK) { - ret = ENOENT; - goto done; - } - - slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &e); - if (!e || !e[0]) { - /* no matches */ - ret = ENOENT; - goto done; - } - - /* TODO: handle more than one range per domain */ - ulong_val = slapi_entry_attr_get_ulong(e[0], "ipaBaseID"); - if (ulong_val >= UINT32_MAX) { - ret = EINVAL; - goto done; - } - range->min = (uint32_t) ulong_val; - - ulong_val = slapi_entry_attr_get_ulong(e[0], "ipaIDRangeSize"); - if ((range->min + ulong_val -1) >= UINT32_MAX) { - ret = EINVAL; - goto done; - } - range->max = (range->min + ulong_val -1); - - ret = 0; - -done: - slapi_free_search_results_internal(pb); - slapi_pblock_destroy(pb); - free(filter); - - return ret; -} - -/* TODO: A similar call is used in ipa_cldap_netlogon.c, maybe a candidate for - * a common library */ -static int get_domain_info(struct ipa_extdom_ctx *ctx, const char *domain_name, - struct domain_info **_domain_info) -{ - struct domain_info *domain_info = NULL; - Slapi_PBlock *pb = NULL; - Slapi_Entry **e = NULL; - char *filter = NULL; - int ret; - enum idmap_error_code err; - struct sss_idmap_range range; - - pb = slapi_pblock_new(); - if (pb == NULL) { - return ENOMEM; - } - - ret = asprintf(&filter, "(&(|(cn=%s)(ipaNTTrustPartner=%s)(ipaNTFlatName=%s))(objectclass=ipaNTTrustedDomain))", - domain_name, domain_name, domain_name); - if (ret == -1) { - ret = ENOMEM; - goto done; - } - - slapi_search_internal_set_pb(pb, ctx->base_dn, - LDAP_SCOPE_SUBTREE, filter, - NULL, 0, NULL, NULL, ctx->plugin_id, 0); - - slapi_search_internal_pb(pb); - slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &ret); - - if (ret != EOK) { - ret = ENOENT; - goto done; - } - - slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &e); - if (!e || !e[0] || e[1]) { - /* no matches or too many matches */ - ret = ENOENT; - goto done; - } - - domain_info = calloc(1, sizeof(struct domain_info)); - if (domain_info == NULL) { - ret = ENOMEM; - goto done; - } - - domain_info->guid = slapi_entry_attr_get_charptr(e[0], "ipaNTDomainGUID"); - domain_info->sid = slapi_entry_attr_get_charptr(e[0], - "ipaNTTrustedDomainSID"); - domain_info->flat_name = slapi_entry_attr_get_charptr(e[0], - "ipaNTFlatName"); - - ret = set_domain_range(ctx, domain_info->sid, &range); - if (ret != 0) { - goto done; - } - - err = sss_idmap_init(NULL, NULL, NULL, &domain_info->idmap_ctx); - if (err == IDMAP_SUCCESS) { - err = sss_idmap_add_domain(domain_info->idmap_ctx, domain_name, - domain_info->sid, &range); - } - if (err != IDMAP_SUCCESS) { - ret = EFAULT; - goto done; - } - - *_domain_info = domain_info; - - ret = 0; - -done: - slapi_free_search_results_internal(pb); - slapi_pblock_destroy(pb); - free(filter); - - if (ret != 0) { - free_domain_info(domain_info); - } - - return ret; - + switch (req->input_type) { + case INP_NAME: + ber_memfree(req->data.name.domain_name); + ber_memfree(req->data.name.object_name); + break; + case INP_SID: + ber_memfree(req->data.sid); + break; + case INP_POSIX_UID: + ber_memfree(req->data.posix_uid.domain_name); + break; + case INP_POSIX_GID: + ber_memfree(req->data.posix_gid.domain_name); + break; + } + + free(req); } int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, struct extdom_res **res) { - wbcErr werr; int ret; - struct wbcDomainSid sid; - char *domain_name; - char *name; - enum wbcSidType name_type; - struct domain_info *domain_info = NULL; - uint32_t id; - enum idmap_error_code err; - char *sid_str; - - if (req->input_type != INP_SID) { - ret = get_domain_info(ctx, req->data.name.domain_name, &domain_info); + char *domain_name = NULL; + char *sid_str = NULL; + size_t buf_len; + char *buf = NULL; + long pw_max; + long gr_max; + struct pwd_grp pg_data; + struct passwd *pwd_result = NULL; + struct group *grp_result = NULL; + enum sss_id_type id_type; + char *fq_name = NULL; + char *sep; + + + pw_max = sysconf(_SC_GETPW_R_SIZE_MAX); + gr_max = sysconf(_SC_GETGR_R_SIZE_MAX); + + if (pw_max == -1 && gr_max == -1) { + buf_len = 16384; + } else { + buf_len = MAX(pw_max, gr_max); + } + + buf = malloc(sizeof(char) * buf_len); + if (buf == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + switch (req->input_type) { + case INP_POSIX_UID: + if (req->request_type == REQ_SIMPLE) { + ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, + &id_type); + } else { + id_type = SSS_ID_TYPE_UID; + ret = getpwuid_r(req->data.posix_uid.uid, &pg_data.data.pwd, buf, + buf_len, &pwd_result); + } + + domain_name = strdup(req->data.posix_uid.domain_name); + break; + case INP_POSIX_GID: + if (req->request_type == REQ_SIMPLE) { + ret = sss_nss_getsidbyid(req->data.posix_uid.uid, &sid_str, + &id_type); + } else { + id_type = SSS_ID_TYPE_GID; + ret = getgrgid_r(req->data.posix_gid.gid, &pg_data.data.grp, buf, + buf_len, &grp_result); + } + + domain_name = strdup(req->data.posix_gid.domain_name); + break; + case INP_SID: + ret = sss_nss_getnamebysid(req->data.sid, &fq_name, &id_type); if (ret != 0) { - return LDAP_OPERATIONS_ERROR; - } - } - - if (req->input_type == INP_POSIX_UID || req->input_type == INP_POSIX_GID) { - if (req->input_type == INP_POSIX_UID) { - id = req->data.posix_uid.uid; - } else { - id = req->data.posix_gid.gid; - } - - err = sss_idmap_unix_to_sid(domain_info->idmap_ctx, id, &sid_str); - if (err != IDMAP_SUCCESS) { ret = LDAP_OPERATIONS_ERROR; goto done; } - werr = wbcStringToSid(sid_str, &sid); - free(sid_str); - if (!WBC_ERROR_IS_OK(werr)) { + sep = strrchr(fq_name, '@'); + if (sep == NULL) { ret = LDAP_OPERATIONS_ERROR; goto done; } - } else if (req->input_type == INP_SID) { - werr = wbcStringToSid(req->data.sid, &sid); - if (!WBC_ERROR_IS_OK(werr)) { + ret = asprintf(&domain_name, "%s", sep+1); + if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; + domain_name = NULL; /* content is undefined according to + asprintf(3) */ goto done; } - } - - switch (req->input_type) { - case INP_POSIX_UID: - case INP_POSIX_GID: - case INP_SID: - werr = wbcLookupSid(&sid, &domain_name, &name, &name_type); - if (!WBC_ERROR_IS_OK(werr)) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - - if (req->input_type == INP_SID) { - ret = get_domain_info(ctx, domain_name, &domain_info); - if (ret != 0) { - return LDAP_OPERATIONS_ERROR; - } - } - - ret = create_response(req, domain_info, domain_name, name, &sid, - name_type, res); - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } + switch(id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: + ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, + &pwd_result); break; - case INP_NAME: - werr = wbcLookupName(domain_info->flat_name, - req->data.name.object_name, &sid, &name_type); - if (!WBC_ERROR_IS_OK(werr)) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - - ret = create_response(req, domain_info, req->data.name.domain_name, - req->data.name.object_name, &sid, name_type, - res); - if (ret != 0) { - ret = LDAP_OPERATIONS_ERROR; - goto done; - } - + case SSS_ID_TYPE_GID: + ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, + &grp_result); break; default: - ret = LDAP_PROTOCOL_ERROR; + ret = LDAP_OPERATIONS_ERROR; goto done; + } + + domain_name = strdup(req->data.name.domain_name); + break; + case INP_NAME: + ret = asprintf(&fq_name, "%s@%s", req->data.name.object_name, + req->data.name.domain_name); + if (ret == -1) { + ret = LDAP_OPERATIONS_ERROR; + fq_name = NULL; /* content is undefined according to + asprintf(3) */ + goto done; + } + + if (req->request_type == REQ_SIMPLE) { + ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); + } else { + id_type = SSS_ID_TYPE_UID; + ret = getpwnam_r(fq_name, &pg_data.data.pwd, buf, buf_len, + &pwd_result); + if (ret == 0 && pwd_result == NULL) { /* no user entry found */ + id_type = SSS_ID_TYPE_GID; + ret = getgrnam_r(fq_name, &pg_data.data.grp, buf, buf_len, + &grp_result); + } + } + break; + default: + ret = LDAP_PROTOCOL_ERROR; + goto done; + } + + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } else if (ret == 0 && pwd_result == NULL && grp_result == NULL && + sid_str == NULL) { + ret = LDAP_NO_SUCH_OBJECT; + goto done; + } + + if (domain_name == NULL) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = create_response(req, &pg_data, sid_str, id_type, domain_name, res); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; } + ret = LDAP_SUCCESS; done: - free_domain_info(domain_info); + free(buf); + free(fq_name); + free(domain_name); + free(sid_str); return ret; } -int create_response(struct extdom_req *req, struct domain_info *domain_info, - const char *domain_name, - const char *name, struct wbcDomainSid *sid, - enum wbcSidType name_type, struct extdom_res **_res) +int create_response(struct extdom_req *req, struct pwd_grp *pg_data, + const char *sid_str, enum sss_id_type id_type, + const char *domain_name, struct extdom_res **_res) { int ret = EFAULT; - int len; struct extdom_res *res; - uint32_t id; - enum idmap_error_code err; - char *sid_str; - wbcErr werr; - res = malloc(sizeof(struct extdom_res)); + res = calloc(1, sizeof(struct extdom_res)); if (res == NULL) { return ENOMEM; } @@ -445,21 +350,37 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, switch (req->input_type) { case INP_SID: res->response_type = RESP_NAME; - res->data.name.domain_name = domain_name; - res->data.name.object_name = name; + res->data.name.domain_name = strdup(domain_name); + switch(id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: + res->data.name.object_name = + strdup(pg_data->data.pwd.pw_name); + break; + case SSS_ID_TYPE_GID: + res->data.name.object_name = + strdup(pg_data->data.grp.gr_name); + break; + default: + ret = EINVAL; + goto done; + } + + if (res->data.name.domain_name == NULL + || res->data.name.object_name == NULL) { + ret = ENOMEM; + goto done; + } break; case INP_NAME: case INP_POSIX_UID: case INP_POSIX_GID: res->response_type = RESP_SID; - - werr = wbcSidToString(sid, &sid_str); - if (!WBC_ERROR_IS_OK(werr)) { - ret = EINVAL; + res->data.sid = strdup(sid_str); + if (res->data.sid == NULL) { + ret = ENOMEM; goto done; } - - res->data.sid = sid_str; break; default: ret = EINVAL; @@ -467,35 +388,36 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, } break; case REQ_FULL: - len = wbcSidToString(sid, &sid_str); - if (!WBC_ERROR_IS_OK(werr)) { - ret = EINVAL; - goto done; - } - - err = sss_idmap_sid_to_unix(domain_info->idmap_ctx, sid_str, &id); - wbcFreeMemory(sid_str); - if (err != IDMAP_SUCCESS) { - ret = EINVAL; - goto done; - } - switch (name_type) { - case WBC_SID_NAME_USER: + switch (id_type) { + case SSS_ID_TYPE_UID: + case SSS_ID_TYPE_BOTH: res->response_type = RESP_USER; - res->data.user.domain_name = domain_name; - res->data.user.user_name = name; + res->data.user.domain_name = strdup(domain_name); + res->data.user.user_name = + strdup(pg_data->data.pwd.pw_name); - res->data.user.uid = (uid_t) id; + if (res->data.user.domain_name == NULL + || res->data.user.user_name == NULL) { + ret = ENOMEM; + goto done; + } - /* We use MPGs for external users */ - res->data.user.gid = (gid_t) id; + res->data.user.uid = pg_data->data.pwd.pw_uid; + res->data.user.gid = pg_data->data.pwd.pw_gid; break; - case WBC_SID_NAME_DOM_GRP: + case SSS_ID_TYPE_GID: res->response_type = RESP_GROUP; - res->data.group.domain_name = domain_name; - res->data.group.group_name = name; + res->data.group.domain_name = strdup(domain_name); + res->data.group.group_name = + strdup(pg_data->data.grp.gr_name); - res->data.group.gid = (gid_t) id; + if (res->data.group.domain_name == NULL + || res->data.group.group_name == NULL) { + ret = ENOMEM; + goto done; + } + + res->data.group.gid = pg_data->data.grp.gr_gid; break; default: ret = EINVAL; @@ -513,12 +435,40 @@ done: if (ret == 0) { *_res = res; } else { - free(res); + free_resp_data(res); } return ret; } +void free_resp_data(struct extdom_res *res) +{ + if (res == NULL) { + return; + } + + switch (res->response_type) { + case RESP_SID: + free(res->data.sid); + break; + case RESP_NAME: + free(res->data.name.domain_name); + free(res->data.name.object_name); + break; + case RESP_USER: + free(res->data.user.domain_name); + free(res->data.user.user_name); + break; + case RESP_GROUP: + free(res->data.group.domain_name); + free(res->data.group.group_name); + break; + } + + free(res); +} + + int pack_response(struct extdom_res *res, struct berval **ret_val) { BerElement *ber = NULL; @@ -569,7 +519,6 @@ int pack_response(struct extdom_res *res, struct berval **ret_val) switch (res->response_type) { case RESP_SID: ret = ber_printf(ber,"{es}", res->response_type, res->data.sid); - wbcFreeMemory(res->data.sid); break; case RESP_NAME: ret = ber_printf(ber,"{e{ss}}", res->response_type, diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index 37a4b1dce13b824cd073e7df180df511b477c894..9315da260ee3de660ea8ff708950945110da37e3 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -138,8 +138,8 @@ static int ipa_extdom_extop(Slapi_PBlock *pb) rc = LDAP_SUCCESS; done: - free(req); - free(res); + free_req_data(req); + free_resp_data(res); if (err_msg != NULL) { LOG("%s", err_msg); } diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c index acb6ae2844eafe938a293a964efa2afe31e32b9e..1467e256619f827310408d558d48c580118d9a32 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c @@ -85,7 +85,7 @@ START_TEST(test_encode) fail_unless(sizeof(res_sid) == resp_val->bv_len && memcmp(res_sid, resp_val->bv_val, resp_val->bv_len) == 0, "Unexpected BER blob."); - ber_memfree(resp_val); + ber_bvfree(resp_val); res.response_type = RESP_NAME; res.data.name.domain_name = TEST_DOMAIN_NAME; @@ -97,7 +97,7 @@ START_TEST(test_encode) fail_unless(sizeof(res_nam) == resp_val->bv_len && memcmp(res_nam, resp_val->bv_val, resp_val->bv_len) == 0, "Unexpected BER blob."); - ber_memfree(resp_val); + ber_bvfree(resp_val); } END_TEST @@ -119,7 +119,7 @@ START_TEST(test_decode) "parse_request_data() returned unexpected request type"); fail_unless(strcmp(req->data.sid, "S-1-2-3-4") == 0, "parse_request_data() returned unexpected sid"); - free(req); + free_req_data(req); req_val.bv_val = req_nam; req_val.bv_len = sizeof(req_nam); @@ -136,7 +136,7 @@ START_TEST(test_decode) "parse_request_data() returned unexpected domain name"); fail_unless(strcmp(req->data.name.object_name, "test") == 0, "parse_request_data() returned unexpected object name"); - free(req); + free_req_data(req); req_val.bv_val = req_uid; req_val.bv_len = sizeof(req_uid); @@ -154,7 +154,7 @@ START_TEST(test_decode) fail_unless(req->data.posix_uid.uid == 12345, "parse_request_data() returned unexpected uid [%d]", req->data.posix_uid.uid); - free(req); + free_req_data(req); req_val.bv_val = req_gid; req_val.bv_len = sizeof(req_gid); @@ -172,7 +172,7 @@ START_TEST(test_decode) fail_unless(req->data.posix_gid.gid == 54321, "parse_request_data() returned unexpected gid [%d]", req->data.posix_gid.gid); - free(req); + free_req_data(req); } END_TEST -- 1.8.1.4 -------------- next part -------------- From 012e52d16ff6c5a663081770b99d4e4ff67ca773 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 3 Jul 2013 14:24:23 +0200 Subject: [PATCH 118/118] Remove winbind client configure check With the replacement of the winbind calls in the extdom plugin none of the plugins is using the winbind client libraries anymore. --- daemons/configure.ac | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index 62722d554a685e6a13642fb7171a62f7a4e38fda..f0f9ea80f17d12a97d7fa4b46b4d63e2c921af08 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -167,17 +167,6 @@ PKG_CHECK_MODULES([NDR], [ndr]) PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba" AC_SUBST(SAMBA40EXTRA_LIBPATH) -AC_CHECK_HEADERS([samba-4.0/wbclient.h], - , - [AC_MSG_ERROR([samba-4.0/wbclient.h not found])], - [#include - #include ]) -AC_CHECK_LIB([wbclient], - [wbcLookupSid], - [WBCLIENT_LIBS="$SAMBA40EXTRA_LIBPATH -lwbclient"], - [AC_MSG_ERROR([libwbclient does not have wbcLookupSid])], - [$SAMBA40EXTRA_LIBPATH]) -AC_SUBST(WBCLIENT_LIBS) AC_CHECK_LIB([pdb], [make_pdb_method], -- 1.8.1.4 From npmccallum at redhat.com Wed Jul 3 20:11:54 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 03 Jul 2013 16:11:54 -0400 Subject: [Freeipa-devel] [PATCH] Fix client install exception if /etc/ssh is missing Message-ID: <1372882314.27700.3.camel@localhost.localdomain> https://fedorahosted.org/freeipa/ticket/3766 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0010-Fix-client-install-exception-if-etc-ssh-is-missing.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 4 09:20:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Jul 2013 11:20:12 +0200 Subject: [Freeipa-devel] [PATCH] Fix client install exception if /etc/ssh is missing In-Reply-To: <1372882314.27700.3.camel@localhost.localdomain> References: <1372882314.27700.3.camel@localhost.localdomain> Message-ID: <51D53E4C.9030509@redhat.com> On 3.7.2013 22:11, Nathaniel McCallum wrote: > https://fedorahosted.org/freeipa/ticket/3766 > If the directory doesn't exist, update_ssh_keys is no-op, so I would prefer if not os.path.isdir(ssh_dir): return at the beginning of update_ssh_keys instead. Honza -- Jan Cholasta From lslebodn at redhat.com Thu Jul 4 09:49:07 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 4 Jul 2013 11:49:07 +0200 Subject: [Freeipa-devel] [PATCH] Use pkg-config to detect cmocka Message-ID: <20130704094906.GB26182@mail.corp.redhat.com> ehlo, libcmocka-0.3 was released and package is available in fedore >= 18. libcmocka-devel contains pkg-config file, therefore it is better to use pkg-config to detect this library. Patch is attached. LS -------------- next part -------------- >From d1460ea58256d96a6cb834097a31d5235c7c0943 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Wed, 3 Jul 2013 22:32:12 +0200 Subject: [PATCH] Use pkg-config to detect cmocka --- daemons/configure.ac | 37 ++++++++++++------------------------- 1 file changed, 12 insertions(+), 25 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index 21d4e7a..8219f2c 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -207,33 +207,20 @@ AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) dnl --------------------------------------------------------------------------- dnl - Check for cmocka unit test framework http://cmocka.cryptomilk.org/ -dnl This will be simplified when cmocka carries a .pc file. dnl --------------------------------------------------------------------------- -AC_SUBST(CMOCKA_LIBS) -AC_SUBST(CMOCKA_CFLAGS) - -AC_CHECK_HEADERS( - [setjmp.h cmocka.h],,, - [[ #include - # include - #ifdef HAVE_SETJMP_H - # include - #endif - ]] +PKG_CHECK_EXISTS(cmocka, + [AC_CHECK_HEADERS([stdarg.h stddef.h setjmp.h], + [], dnl We are only intrested in action-if-not-found + [AC_MSG_WARN([Header files stdarg.h stddef.h setjmp.h are required by cmocka]) + cmocka_required_headers="no" + ] + ) + AS_IF([test x"$cmocka_required_headers" != x"no"], + [PKG_CHECK_MODULES([CMOCKA], [cmocka], [have_cmocka="yes"])] + )], + dnl PKG_CHECK_EXISTS ACTION-IF-NOT-FOUND + [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be built])] ) - -if test "x$ac_cv_header_setjmp_h" = "xyes" && test "x$ac_cv_header_cmocka_h" = "xyes" ; then - AC_CHECK_LIB([cmocka], [_will_return], - [ CMOCKA_LIBS="-lcmocka" - AC_MSG_RESULT([libcmocka available, cmocka tests will be build]) - have_cmocka="yes" ], - [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be build]) - have_cmocka="no" ]) -else - AC_MSG_WARN([Required header files for libcmocka are missing, cmocka tests will not be build]) - have_cmocka="no" -fi - AM_CONDITIONAL([HAVE_CMOCKA], [test x$have_cmocka = xyes]) dnl -- dirsrv is needed for the extdom unit tests -- -- 1.8.3.1 From lslebodn at redhat.com Thu Jul 4 11:49:35 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 4 Jul 2013 13:49:35 +0200 Subject: [Freeipa-devel] [PATCH] Use pkg-config to detect cmocka In-Reply-To: <20130704101054.GA3956@redhat.com> References: <20130704094906.GB26182@mail.corp.redhat.com> <20130704101054.GA3956@redhat.com> Message-ID: <20130704114935.GD26182@mail.corp.redhat.com> On (04/07/13 13:10), Alexander Bokovoy wrote: >On Thu, 04 Jul 2013, Lukas Slebodnik wrote: >>ehlo, >> >>libcmocka-0.3 was released and package is available in fedore >= 18. >>libcmocka-devel contains pkg-config file, >>therefore it is better to use pkg-config to detect this library. >> >>Patch is attached. >Few comments. > >0. Please follow https://fedorahosted.org/freeipa/wiki/PatchFormat changed >1. It would be nice to have a ticket in the FreeIPA trac. Could ticket#3434 be used? I know that ticket is fixed. https://fedorahosted.org/freeipa/ticket/3434 Funcionality of patch is the same as Sumit's version. >2. I think at this point we need to decide whether we want to have > BuildRequires: libcmocka-devel > in freeipa.spec.in. Given the change, older version would become > unsupported but we don't really have any packaging dependency yet. At the moment, there isnot any cmocka test in freeipa source repo. LS -------------- next part -------------- >From 17d5b40e51ae4f4ac1a8689aabfdba389568e9ab Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Wed, 3 Jul 2013 22:32:12 +0200 Subject: [PATCH] Use pkg-config to detect cmocka https://fedorahosted.org/freeipa/ticket/3434 --- daemons/configure.ac | 37 ++++++++++++------------------------- 1 file changed, 12 insertions(+), 25 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index 21d4e7a..8219f2c 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -207,33 +207,20 @@ AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) dnl --------------------------------------------------------------------------- dnl - Check for cmocka unit test framework http://cmocka.cryptomilk.org/ -dnl This will be simplified when cmocka carries a .pc file. dnl --------------------------------------------------------------------------- -AC_SUBST(CMOCKA_LIBS) -AC_SUBST(CMOCKA_CFLAGS) - -AC_CHECK_HEADERS( - [setjmp.h cmocka.h],,, - [[ #include - # include - #ifdef HAVE_SETJMP_H - # include - #endif - ]] +PKG_CHECK_EXISTS(cmocka, + [AC_CHECK_HEADERS([stdarg.h stddef.h setjmp.h], + [], dnl We are only intrested in action-if-not-found + [AC_MSG_WARN([Header files stdarg.h stddef.h setjmp.h are required by cmocka]) + cmocka_required_headers="no" + ] + ) + AS_IF([test x"$cmocka_required_headers" != x"no"], + [PKG_CHECK_MODULES([CMOCKA], [cmocka], [have_cmocka="yes"])] + )], + dnl PKG_CHECK_EXISTS ACTION-IF-NOT-FOUND + [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be built])] ) - -if test "x$ac_cv_header_setjmp_h" = "xyes" && test "x$ac_cv_header_cmocka_h" = "xyes" ; then - AC_CHECK_LIB([cmocka], [_will_return], - [ CMOCKA_LIBS="-lcmocka" - AC_MSG_RESULT([libcmocka available, cmocka tests will be build]) - have_cmocka="yes" ], - [AC_MSG_WARN([No libcmocka library found, cmocka tests will not be build]) - have_cmocka="no" ]) -else - AC_MSG_WARN([Required header files for libcmocka are missing, cmocka tests will not be build]) - have_cmocka="no" -fi - AM_CONDITIONAL([HAVE_CMOCKA], [test x$have_cmocka = xyes]) dnl -- dirsrv is needed for the extdom unit tests -- -- 1.8.3.1 From pspacek at redhat.com Thu Jul 4 13:23:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Jul 2013 15:23:16 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration Message-ID: <51D57744.5080807@redhat.com> Hello, several warnings from autotools popped up after upgrade to Fedora 19. Attached patches should make autotools configuration more modern. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0169-Add-missing-ar-check-to-configure.ac.patch Type: text/x-patch Size: 632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0170-Put-m4-macros-from-autotools-to-separate-sub-directo.patch Type: text/x-patch Size: 1006 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jul 5 16:20:18 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 05 Jul 2013 12:20:18 -0400 Subject: [Freeipa-devel] [PATCH] Fix client install exception if /etc/ssh is missing In-Reply-To: <51D53E4C.9030509@redhat.com> References: <1372882314.27700.3.camel@localhost.localdomain> <51D53E4C.9030509@redhat.com> Message-ID: <1373041218.27700.14.camel@localhost.localdomain> On Thu, 2013-07-04 at 11:20 +0200, Jan Cholasta wrote: > On 3.7.2013 22:11, Nathaniel McCallum wrote: > > https://fedorahosted.org/freeipa/ticket/3766 > > > > If the directory doesn't exist, update_ssh_keys is no-op, so I would prefer > > if not os.path.isdir(ssh_dir): > return > > at the beginning of update_ssh_keys instead. Attached. I don't care which version of the patch gets merged... -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0010-2-Fix-client-install-exception-if-etc-ssh-is-missing.patch Type: text/x-patch Size: 1001 bytes Desc: not available URL: From jcholast at redhat.com Mon Jul 8 05:12:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Jul 2013 07:12:13 +0200 Subject: [Freeipa-devel] [PATCH] 148 Skip cert issuer validation in service and host commands in CA-less install Message-ID: <51DA4A2D.1060406@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-148-Skip-cert-issuer-validation-in-service-and-host-comm.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 8 06:32:56 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 09:32:56 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <51C31C1F.2040307@redhat.com> References: <51C31C1F.2040307@redhat.com> Message-ID: <20130708063256.GE3956@redhat.com> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >Hello, > >Attached patches fix systemd and ipactl related bugs: > >https://fedorahosted.org/freeipa/ticket/3730 >https://fedorahosted.org/freeipa/ticket/3729 NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on upgrade properly and everything else has failed afterwards. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 07:20:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 10:20:04 +0300 Subject: [Freeipa-devel] [PATCH] 0041 Fix bug in adtrustinstance In-Reply-To: <51C9A246.1020201@redhat.com> References: <51C9A246.1020201@redhat.com> Message-ID: <20130708072004.GF3956@redhat.com> On Tue, 25 Jun 2013, Ana Krivokapic wrote: >Hello, > >Attached patch fixes https://fedorahosted.org/freeipa/ticket/3746. > >-- >Regards, > >Ana Krivokapic >Associate Software Engineer >FreeIPA team >Red Hat Inc. > >From 548f1626dbf9edf45bfcab358b28e510d1ec5757 Mon Sep 17 00:00:00 2001 >From: Ana Krivokapic >Date: Tue, 25 Jun 2013 15:52:29 +0200 >Subject: [PATCH] Fix bug in adtrustinstance > >Incorrect tuple unpacking in adtrustinstance was causing ipa-adtrust-install >to fail when IPA was installed with no DNS. > >https://fedorahosted.org/freeipa/ticket/3746 >--- > ipaserver/install/adtrustinstance.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py >index d2929801b431625764e5b949349ab63d2caaf696..4eb20d9517906df0b1952fe5033a050f3b55a797 100644 >--- a/ipaserver/install/adtrustinstance.py >+++ b/ipaserver/install/adtrustinstance.py >@@ -535,9 +535,9 @@ def __add_dns_service_records(self): > self.print_msg(err_msg) > self.print_msg("Add the following service records to your DNS " \ > "server for DNS zone %s: " % zone) >- for (srv, rdata) in ipa_srv_rec: >+ for srv in ipa_srv_rec: > for suff in win_srv_suffix: >- self.print_msg(" - %s%s" % (srv, suff)) >+ self.print_msg(" - %s%s" % (srv[0], suff)) > return > > for (srv, rdata, port) in ipa_srv_rec: ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 07:22:54 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 10:22:54 +0300 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51CC617F.9090305@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> Message-ID: <20130708072254.GG3956@redhat.com> On Thu, 27 Jun 2013, Jan Cholasta wrote: >On 27.6.2013 17:34, Rich Megginson wrote: >>On 06/27/2013 09:31 AM, Jan Cholasta wrote: >>>The search is hard-coded in the referint plugin, see >>>. >>> >> >>Not sure if it makes sense to do a wildcard/substr search here - please >>file a ticket with 389 to investigate. > >https://fedorahosted.org/389/ticket/47411 So, should we merge this patchset or wait until 389-ds analyzes 47411? To me it looks like we can use this one as an interim solution, once Web UI performance is checked through. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 07:23:43 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 10:23:43 +0300 Subject: [Freeipa-devel] [PATCH] 427 Disable checkboxes and radios for readonly attributes In-Reply-To: <51CD88ED.3040600@redhat.com> References: <51CD88ED.3040600@redhat.com> Message-ID: <20130708072343.GH3956@redhat.com> On Fri, 28 Jun 2013, Petr Vobornik wrote: >https://fedorahosted.org/freeipa/ticket/3764 ACK -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 07:26:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 10:26:01 +0300 Subject: [Freeipa-devel] F19 is broken w.r.t. user password change In-Reply-To: <1372525419.31944.13.camel@willson.li.ssimo.org> References: <20130628191653.GA24422@redhat.com> <20130629044650.GE24422@redhat.com> <1372525419.31944.13.camel@willson.li.ssimo.org> Message-ID: <20130708072601.GI3956@redhat.com> On Sat, 29 Jun 2013, Simo Sorce wrote: >On Sat, 2013-06-29 at 07:46 +0300, Alexander Bokovoy wrote: >> On Fri, 28 Jun 2013, Alexander Bokovoy wrote: >> >Hi! >> > >> >Found today when preparing my talk at LVEE conference: >> > >> >When running 'ipa passwd ' or 'kinit ' for the first time >> >(i.e. forcing a password change), ipa-pwd-extop causes denial of >> >password change: >> > >> >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Received extended operation request with OID 1.3.6.1.4.1.4203.1.11.1 >> >.... >> >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Pre-Encoded passwords are not valid >> >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_post_op >> >[28/Jun/2013:22:02:43 +0300] roles-plugin - --> roles_cache_change_notify >> >[28/Jun/2013:22:02:43 +0300] roles-plugin - <-- roles_post_op >> >[28/Jun/2013:22:02:43 +0300] ipa-pwd-extop - Failed to update password >> > >> >Apparently, we receive password encoded as {SSHA} scheme and it breaks >> >any password change. Appropriate code checks are in >> >daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:719-738 >> > >> >I've reproduced it with Fedora 19 RC2 ISO, with git master rpms, and >> >with freeipa-devel repo. Basically, this is release blocker for 3.3 >> >right now. >> Thanks to Nathan to point out to this change in 389-ds-base: >> http://directory.fedoraproject.org/wiki/Password_Administrator >> >> I added >> >> passwordAdminDn: cn=admins,cn=groups,cn=accounts,$SUFFIX >> >> to cn=config and got it fixed for stock FreeIPA configuration. >> However, the change like this would not be enough for delegated roles. >> >> Patch that fixes basic problem is attached, please review. > >Although the patch 'fixes' the problem for the admin group it break s >the IPA model. >We need to get a way to disable this behavior in 389DS (we already do >our own checks since long), and work for a long term solution where >policy checks can be delegated to a plugin. > >It is a priority to revert the new logic in 389DS immediately, and work >on a plan. 389-ds team (thanks Nathan and Noriko!) released fixed version and it is now available in Fedora 19. I've checked 1.3.1.3-1.fc19 and it fixes the issue without additional changes to FreeIPA. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 07:30:53 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 10:30:53 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130703151713.GQ27655@localhost.localdomain> References: <20130703151713.GQ27655@localhost.localdomain> Message-ID: <20130708073053.GJ3956@redhat.com> On Wed, 03 Jul 2013, Sumit Bose wrote: >Hi, > >with this patch the extdom plugin, the LDAP extended operation that >allows IPA clients with recent SSSD to lookup AD users and groups, will >not use winbind for the lookup anymore but will use SSSD running in >ipa_server_mode. > >Since now no plugin uses the winbind client libraries anymore, the >second patch removes the related configures checks. > >I think for the time being we cannot remove winbind completely because >it might be needed for msbd to work properly in a trusted environment. s/msbd/smbd/ ACK. I need to add 'ipa_server_mode = True' support to the installer code and then these patches can go in. -- / Alexander Bokovoy From pspacek at redhat.com Mon Jul 8 08:51:41 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Jul 2013 10:51:41 +0200 Subject: [Freeipa-devel] [PATCH 0171-0172] Fix potential problems found by Clang static analyzer Message-ID: <51DA7D9D.3060201@redhat.com> Hello, several warnings from Clang static analyzer popped up after upgrade to Fedora 19. Attached patches should fix all problems found by clang-analyzer-3.3-0.6.rc3.fc19.x86_64. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0171-Remove-false-positive-NULL-dereference-reported-by-C.patch Type: text/x-patch Size: 1135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0172-Modify-ldap_pool_destroy-to-handle-partially-allocat.patch Type: text/x-patch Size: 1479 bytes Desc: not available URL: From simo at redhat.com Mon Jul 8 13:09:24 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Jul 2013 09:09:24 -0400 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <51C31C1F.2040307@redhat.com> References: <51C31C1F.2040307@redhat.com> Message-ID: <1373288964.30537.161.camel@willson.li.ssimo.org> On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: > -After=network.target > +After=network.target dirsrv.target > pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service > httpd.service krb5kdc.service messagebus.service nslcd.service > nscd.service ntpd.service portmap.service rpcbind.service > kadmin.service sshd.service autofs.service rpcgssd.service > rpcidmapd.service chronyd.service > Won't this cause ipa.service to try to restart things twice ? Also this will unconditionally try to start the CA even if not installed. NACK, please let ipa.service handle starting and stopping daemons. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jul 8 13:15:39 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 16:15:39 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130708073053.GJ3956@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> Message-ID: <20130708131539.GK3956@redhat.com> On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >On Wed, 03 Jul 2013, Sumit Bose wrote: >>Hi, >> >>with this patch the extdom plugin, the LDAP extended operation that >>allows IPA clients with recent SSSD to lookup AD users and groups, will >>not use winbind for the lookup anymore but will use SSSD running in >>ipa_server_mode. >> >>Since now no plugin uses the winbind client libraries anymore, the >>second patch removes the related configures checks. >> >>I think for the time being we cannot remove winbind completely because >>it might be needed for msbd to work properly in a trusted environment. >s/msbd/smbd/ > >ACK. I need to add 'ipa_server_mode = True' support to >the installer code and then these patches can go in. Actually, the code still doesn't work due to some bug in sssd which fails to respond properly to getsidbyname() request in libsss_nss_idmap. Additionally I've found one missing treatment of domain_name for INP_NAME requests. We are working with Jakub on tracking down what's wrong on SSSD side. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 8 13:18:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 16:18:44 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <1373288964.30537.161.camel@willson.li.ssimo.org> References: <51C31C1F.2040307@redhat.com> <1373288964.30537.161.camel@willson.li.ssimo.org> Message-ID: <20130708131844.GL3956@redhat.com> On Mon, 08 Jul 2013, Simo Sorce wrote: >On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: >> -After=network.target >> +After=network.target dirsrv.target >> pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service >> httpd.service krb5kdc.service messagebus.service nslcd.service >> nscd.service ntpd.service portmap.service rpcbind.service >> kadmin.service sshd.service autofs.service rpcgssd.service >> rpcidmapd.service chronyd.service >> >Won't this cause ipa.service to try to restart things twice ? >Also this will unconditionally try to start the CA even if not >installed. No, this is for dependency ordering only, not for actual start/stop dependency action. >From systemd.unit(5): Note that this setting is independent of and orthogonal to the requirement dependencies as configured by Requires=. It is a common pattern to include a unit name in both the After= and Requires= option in which case the unit listed will be started before the unit that is configured with these options. This option may be specified more than once, in which case ordering dependencies for all listed names are created. -- / Alexander Bokovoy From simo at redhat.com Mon Jul 8 13:25:43 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 08 Jul 2013 09:25:43 -0400 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130708131844.GL3956@redhat.com> References: <51C31C1F.2040307@redhat.com> <1373288964.30537.161.camel@willson.li.ssimo.org> <20130708131844.GL3956@redhat.com> Message-ID: <1373289943.30537.169.camel@willson.li.ssimo.org> On Mon, 2013-07-08 at 16:18 +0300, Alexander Bokovoy wrote: > On Mon, 08 Jul 2013, Simo Sorce wrote: > >On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: > >> -After=network.target > >> +After=network.target dirsrv.target > >> pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service > >> httpd.service krb5kdc.service messagebus.service nslcd.service > >> nscd.service ntpd.service portmap.service rpcbind.service > >> kadmin.service sshd.service autofs.service rpcgssd.service > >> rpcidmapd.service chronyd.service > >> > >Won't this cause ipa.service to try to restart things twice ? > >Also this will unconditionally try to start the CA even if not > >installed. > No, this is for dependency ordering only, not for actual start/stop > dependency action. > > From systemd.unit(5): > > Note that this setting is independent of and orthogonal to the > requirement dependencies as configured by Requires=. It is a common > pattern to include a unit name in both the After= and Requires= option > in which case the unit listed will be started before the unit that is > configured with these options. This option may be specified more than > once, in which case ordering dependencies for all listed names are > created. Yes but what is the point of "starting" ipa.service "after" its own components ? I can understand putting there the following: * network.target * certmonger.service * messagebus.service I do not understand putting there these: * dirsrv.target * pki-tomcatd at pki-tomcat.service * pki-cad.target * httpd.service * krb5kdc.service * kadmin.service * ntpd.service As these are started by ipa.service itself I am not sure why these are put there either: * nslcd.service * nscd.service * portmap.service * rpcbind.service * sshd.service * autofs.service * rpcgssd.service * rpcidmapd.service * chronyd.service Why do we need to be started after these ? We have no direct dependency. Besides we do not use nslcd, nscd, chronyd at all when installing freeipa as we replace all of them with sssd (actually not listed at all) and ntpd Also why nfs and the rpc stuff should be started earlier ? rpcgssd in particular may try to kinit with the nfs keytab, so starting it before the kdc wouldn't work well. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Mon Jul 8 14:17:36 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 8 Jul 2013 16:17:36 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130708131539.GK3956@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> Message-ID: <20130708141736.GI17598@hendrix.redhat.com> On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: > On Mon, 08 Jul 2013, Alexander Bokovoy wrote: > >On Wed, 03 Jul 2013, Sumit Bose wrote: > >>Hi, > >> > >>with this patch the extdom plugin, the LDAP extended operation that > >>allows IPA clients with recent SSSD to lookup AD users and groups, will > >>not use winbind for the lookup anymore but will use SSSD running in > >>ipa_server_mode. > >> > >>Since now no plugin uses the winbind client libraries anymore, the > >>second patch removes the related configures checks. > >> > >>I think for the time being we cannot remove winbind completely because > >>it might be needed for msbd to work properly in a trusted environment. > >s/msbd/smbd/ > > > >ACK. I need to add 'ipa_server_mode = True' support to > >the installer code and then these patches can go in. > Actually, the code still doesn't work due to some bug in sssd which > fails to respond properly to getsidbyname() request in libsss_nss_idmap. > > Additionally I've found one missing treatment of domain_name for > INP_NAME requests. > > We are working with Jakub on tracking down what's wrong on SSSD side. Indeed, there was a casing issue in sysdb. You can continue testing with lowercase user names in the meantime. A patch is already on the SSSD list. From akrivoka at redhat.com Mon Jul 8 14:58:18 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 08 Jul 2013 16:58:18 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51C9B709.9030707@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> <51937353.3090501@redhat.com> <51B19888.2050803@redhat.com> <51B5E43F.809@redhat.com> <1370961745.2400.96.camel@aleeredhat.laptop> <51C83B1A.40000@redhat.com> <51C9B709.9030707@redhat.com> Message-ID: <51DAD38A.1030209@redhat.com> On 06/25/2013 05:28 PM, Ana Krivokapic wrote: > On 06/24/2013 02:27 PM, Tomas Babej wrote: >> On 06/11/2013 04:42 PM, Ade Lee wrote: >> [snip] >>> Just FYI, we plan to do a new release of pki-core today (pki-core-10.0.3-2) >>> to address this issue. >>>> -- >>>> Regards, >>>> >>>> Ana Krivokapic >>>> Associate Software Engineer >>>> FreeIPA team >>>> Red Hat Inc. >> Ok, so I tested the patch, since pki-core has the PkiExport command fixed now. >> >> I'm getting a little bit further now. >> >> [tbabej at vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129 >> vm-129.idm.lab.eng.brq.redhat.com >> Directory Manager (existing master) password: >> >> Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from >> vm-127.idm.lab.eng.brq.redhat.com >> Constraint violation: Failed to update password >> >> With debug output, I get (snipped out irrelevant parts): >> >> Directory Manager (existing master) password: >> >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection >> context.ldap2_57668944 >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >> conn= >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection >> context.ldap2_57668944 >> ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com >> ipa: DEBUG: Search failed: [Errno -2] Name or service not known >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >> conn= >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not logging >> to a file >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: >> ipa-replica-prepare was invoked with arguments >> ['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None, >> 'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin': None, >> 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None, 'ca_file': >> '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12': None, 'password': >> None, 'ip_address': CheckedIPAddress('10.34.47.129'), 'dirsrv_pin': None, >> 'pkinit_pin': None} >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO: Preparing >> replica for vm-129.idm.lab.eng.brq.redhat.com from >> vm-127.idm.lab.eng.brq.redhat.com >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket >> conn= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p >> /tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12 >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection >> context.ldap2_139884970376144 >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", >> line 245, in run >> self.copy_ds_certificate() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", >> line 281, in copy_ds_certificate >> self.update_pki_admin_password() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", >> line 520, in update_pki_admin_password >> ldap.modify_password(dn, self.dirman_password) >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line >> 332, in modify_password >> self.conn.passwd_s(dn, old_pass, new_pass) >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 919, in >> error_handler >> raise errors.DatabaseError(desc=desc, info=info) >> >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The >> ipa-replica-prepare command failed, exception: DatabaseError: Constraint >> violation: Failed to update password >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint >> violation: Failed to update password >> >> Tomas > It seems that this time the culprit is 389-ds-base packages. The password change > is rejected when using the latest version of 389-ds-base > (389-ds-base-1.3.1.2-1.fc19.x86_64). I tried testing it with a previous version > (389-ds-base-1.3.0.5-1.fc19.x86_64) and it works. > > I open an upstream ticket for the 389 DS project: > https://fedorahosted.org/389/ticket/47406. > The password change rejection problem has been fixed in the new version of 389-ds-base: 389-ds-base-1.3.1.3-1.fc19. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From abokovoy at redhat.com Mon Jul 8 16:32:41 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Jul 2013 19:32:41 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130708141736.GI17598@hendrix.redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> Message-ID: <20130708163241.GM3956@redhat.com> On Mon, 08 Jul 2013, Jakub Hrozek wrote: >On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: >> On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >> >On Wed, 03 Jul 2013, Sumit Bose wrote: >> >>Hi, >> >> >> >>with this patch the extdom plugin, the LDAP extended operation that >> >>allows IPA clients with recent SSSD to lookup AD users and groups, will >> >>not use winbind for the lookup anymore but will use SSSD running in >> >>ipa_server_mode. >> >> >> >>Since now no plugin uses the winbind client libraries anymore, the >> >>second patch removes the related configures checks. >> >> >> >>I think for the time being we cannot remove winbind completely because >> >>it might be needed for msbd to work properly in a trusted environment. >> >s/msbd/smbd/ >> > >> >ACK. I need to add 'ipa_server_mode = True' support to >> >the installer code and then these patches can go in. >> Actually, the code still doesn't work due to some bug in sssd which >> fails to respond properly to getsidbyname() request in libsss_nss_idmap. >> >> Additionally I've found one missing treatment of domain_name for >> INP_NAME requests. >> >> We are working with Jakub on tracking down what's wrong on SSSD side. > >Indeed, there was a casing issue in sysdb. You can continue testing with >lowercase user names in the meantime. A patch is already on the SSSD >list. In addition, we need to disqualify user name when returning back a packet from extdom operation as this is what SSSD expects. Attached patch does it for all types of requests. -- / Alexander Bokovoy -------------- next part -------------- >From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 8 Jul 2013 19:19:56 +0300 Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as sssd expects extdom plugin handles external operation over which SSSD asks IPA server about trusted domain users not found through normal paths but detected to belong to the trusted domains associated with IPA realm. SSSD expects that user or group name in the response will be unqualified because domain name for the user or group is also included in the response. Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully qualified name which includes the domain name we are asked to handle. The code already expects that fully-qualified names are following user at domain convention so we are simply tracking whether '@' symbol is present and is followed by the domain name. --- .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) 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 8aa22e1..290da4e 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 @@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, &grp_result); } } + domain_name = strdup(req->data.name.domain_name); break; default: ret = LDAP_PROTOCOL_ERROR; @@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, const char *domain_name, struct extdom_res **_res) { int ret = EFAULT; + char *locat = NULL; struct extdom_res *res; res = calloc(1, sizeof(struct extdom_res)); @@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, switch(id_type) { case SSS_ID_TYPE_UID: case SSS_ID_TYPE_BOTH: + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { + if (strstr(locat, domain_name) != NULL ) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.pwd.pw_name); break; case SSS_ID_TYPE_GID: + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { + if (strstr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.grp.gr_name); break; @@ -393,6 +405,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_BOTH: res->response_type = RESP_USER; res->data.user.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { + if (strstr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.user.user_name = strdup(pg_data->data.pwd.pw_name); @@ -408,6 +425,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_GID: res->response_type = RESP_GROUP; res->data.group.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { + if (strstr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.group.group_name = strdup(pg_data->data.grp.gr_name); @@ -438,6 +460,10 @@ done: free_resp_data(res); } + if (locat != NULL) { + locat[0] = '@'; + } + return ret; } -- 1.8.3.1 From jhrozek at redhat.com Mon Jul 8 20:57:38 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 8 Jul 2013 22:57:38 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130708163241.GM3956@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> Message-ID: <20130708205738.GL17598@hendrix.redhat.com> On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: > On Mon, 08 Jul 2013, Jakub Hrozek wrote: > >On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: > >>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: > >>>On Wed, 03 Jul 2013, Sumit Bose wrote: > >>>>Hi, > >>>> > >>>>with this patch the extdom plugin, the LDAP extended operation that > >>>>allows IPA clients with recent SSSD to lookup AD users and groups, will > >>>>not use winbind for the lookup anymore but will use SSSD running in > >>>>ipa_server_mode. > >>>> > >>>>Since now no plugin uses the winbind client libraries anymore, the > >>>>second patch removes the related configures checks. > >>>> > >>>>I think for the time being we cannot remove winbind completely because > >>>>it might be needed for msbd to work properly in a trusted environment. > >>>s/msbd/smbd/ > >>> > >>>ACK. I need to add 'ipa_server_mode = True' support to > >>>the installer code and then these patches can go in. > >>Actually, the code still doesn't work due to some bug in sssd which > >>fails to respond properly to getsidbyname() request in libsss_nss_idmap. > >> > >>Additionally I've found one missing treatment of domain_name for > >>INP_NAME requests. > >> > >>We are working with Jakub on tracking down what's wrong on SSSD side. > > > >Indeed, there was a casing issue in sysdb. You can continue testing with > >lowercase user names in the meantime. A patch is already on the SSSD > >list. > In addition, we need to disqualify user name when returning back a > packet from extdom operation as this is what SSSD expects. > > Attached patch does it for all types of requests. > > -- > / Alexander Bokovoy > >From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Mon, 8 Jul 2013 19:19:56 +0300 > Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as > sssd expects > > extdom plugin handles external operation over which SSSD asks IPA server about > trusted domain users not found through normal paths but detected to belong > to the trusted domains associated with IPA realm. > > SSSD expects that user or group name in the response will be unqualified > because domain name for the user or group is also included in the response. > Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully > qualified name which includes the domain name we are asked to handle. > > The code already expects that fully-qualified names are following user at domain > convention so we are simply tracking whether '@' symbol is present and is followed > by the domain name. > --- > .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > 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 8aa22e1..290da4e 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 > @@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > &grp_result); > } > } > + domain_name = strdup(req->data.name.domain_name); I would prefer if this was a separate patch. But this is a correct change. > break; > default: > ret = LDAP_PROTOCOL_ERROR; > @@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > const char *domain_name, struct extdom_res **_res) > { > int ret = EFAULT; > + char *locat = NULL; > struct extdom_res *res; > > res = calloc(1, sizeof(struct extdom_res)); > @@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > switch(id_type) { > case SSS_ID_TYPE_UID: > case SSS_ID_TYPE_BOTH: > + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > + if (strstr(locat, domain_name) != NULL ) { strstr doesn't work correctly in my case. In SSSD, the domain names are case-insensitive, so you can use strcasestr here. In my case, the condition is never hit as the domain case differs: 407 res->data.user.domain_name = strdup(domain_name); (gdb) 408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { (gdb) n 409 if (strstr(locat, domain_name) != NULL) { (gdb) 414 strdup(pg_data->data.pwd.pw_name); (gdb) p domain_name $1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" (gdb) p locat $2 = 0x7f2e8006500d "@ad.example.com" Also, this is good enough for the beta or when the default values are used, but in theory, the admin could configure the fully qualified name format to not include the @-sign (see full_name_format in sssd.conf) at all. It's not very likely, but I think we should account for that case eventually. I'm not exactly sure how yet as the full_name_format is pretty free-form, maybe we could simply disallow setting it if server_mode was set to True. > + locat[0] = 0; > + } > + } > res->data.name.object_name = > strdup(pg_data->data.pwd.pw_name); > break; > case SSS_ID_TYPE_GID: > + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { > + if (strstr(locat, domain_name) != NULL) { > + locat[0] = 0; > + } > + } > res->data.name.object_name = > strdup(pg_data->data.grp.gr_name); > break; > @@ -393,6 +405,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > case SSS_ID_TYPE_BOTH: > res->response_type = RESP_USER; > res->data.user.domain_name = strdup(domain_name); > + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > + if (strstr(locat, domain_name) != NULL) { > + locat[0] = 0; > + } > + } > res->data.user.user_name = > strdup(pg_data->data.pwd.pw_name); > > @@ -408,6 +425,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > case SSS_ID_TYPE_GID: > res->response_type = RESP_GROUP; > res->data.group.domain_name = strdup(domain_name); > + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { > + if (strstr(locat, domain_name) != NULL) { > + locat[0] = 0; > + } > + } > res->data.group.group_name = > strdup(pg_data->data.grp.gr_name); > > @@ -438,6 +460,10 @@ done: > free_resp_data(res); > } > > + if (locat != NULL) { > + locat[0] = '@'; > + } > + > return ret; > } > > -- > 1.8.3.1 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Tue Jul 9 07:33:19 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Jul 2013 10:33:19 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130708205738.GL17598@hendrix.redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> Message-ID: <20130709073319.GA5205@redhat.com> On Mon, 08 Jul 2013, Jakub Hrozek wrote: >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: >> On Mon, 08 Jul 2013, Jakub Hrozek wrote: >> >On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: >> >>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >> >>>On Wed, 03 Jul 2013, Sumit Bose wrote: >> >>>>Hi, >> >>>> >> >>>>with this patch the extdom plugin, the LDAP extended operation that >> >>>>allows IPA clients with recent SSSD to lookup AD users and groups, will >> >>>>not use winbind for the lookup anymore but will use SSSD running in >> >>>>ipa_server_mode. >> >>>> >> >>>>Since now no plugin uses the winbind client libraries anymore, the >> >>>>second patch removes the related configures checks. >> >>>> >> >>>>I think for the time being we cannot remove winbind completely because >> >>>>it might be needed for msbd to work properly in a trusted environment. >> >>>s/msbd/smbd/ >> >>> >> >>>ACK. I need to add 'ipa_server_mode = True' support to >> >>>the installer code and then these patches can go in. >> >>Actually, the code still doesn't work due to some bug in sssd which >> >>fails to respond properly to getsidbyname() request in libsss_nss_idmap. >> >> >> >>Additionally I've found one missing treatment of domain_name for >> >>INP_NAME requests. >> >> >> >>We are working with Jakub on tracking down what's wrong on SSSD side. >> > >> >Indeed, there was a casing issue in sysdb. You can continue testing with >> >lowercase user names in the meantime. A patch is already on the SSSD >> >list. >> In addition, we need to disqualify user name when returning back a >> packet from extdom operation as this is what SSSD expects. >> >> Attached patch does it for all types of requests. >> >> -- >> / Alexander Bokovoy > >> >From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 >> From: Alexander Bokovoy >> Date: Mon, 8 Jul 2013 19:19:56 +0300 >> Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as >> sssd expects >> >> extdom plugin handles external operation over which SSSD asks IPA server about >> trusted domain users not found through normal paths but detected to belong >> to the trusted domains associated with IPA realm. >> >> SSSD expects that user or group name in the response will be unqualified >> because domain name for the user or group is also included in the response. >> Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully >> qualified name which includes the domain name we are asked to handle. >> >> The code already expects that fully-qualified names are following user at domain >> convention so we are simply tracking whether '@' symbol is present and is followed >> by the domain name. >> --- >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> >> 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 8aa22e1..290da4e 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 >> @@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, >> &grp_result); >> } >> } >> + domain_name = strdup(req->data.name.domain_name); > >I would prefer if this was a separate patch. But this is a correct >change. Separated. > >> break; >> default: >> ret = LDAP_PROTOCOL_ERROR; >> @@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> const char *domain_name, struct extdom_res **_res) >> { >> int ret = EFAULT; >> + char *locat = NULL; >> struct extdom_res *res; >> >> res = calloc(1, sizeof(struct extdom_res)); >> @@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> switch(id_type) { >> case SSS_ID_TYPE_UID: >> case SSS_ID_TYPE_BOTH: >> + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >> + if (strstr(locat, domain_name) != NULL ) { > >strstr doesn't work correctly in my case. In SSSD, the domain names are >case-insensitive, so you can use strcasestr here. In my case, the >condition is never hit as the domain case differs: > >407 res->data.user.domain_name = strdup(domain_name); >(gdb) >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >(gdb) n >409 if (strstr(locat, domain_name) != NULL) { >(gdb) >414 strdup(pg_data->data.pwd.pw_name); >(gdb) p domain_name >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" >(gdb) p locat >$2 = 0x7f2e8006500d "@ad.example.com" Replaced by strcasestr. > >Also, this is good enough for the beta or when the default values are used, but >in theory, the admin could configure the fully qualified name format to not >include the @-sign (see full_name_format in sssd.conf) at all. > >It's not very likely, but I think we should account for that case >eventually. I'm not exactly sure how yet as the full_name_format is pretty >free-form, maybe we could simply disallow setting it if server_mode was >set to True. I'd prefer the latter indeed. Given that you can have full_name_format varying between servers and clients, this is simply asking for disaster. I'd preper concentrating our effort on making default configuration working so well that you never need to modify these parameters. After all, we are talking about SSSD use as FreeIPA client with trusts enabled. SSSD configuration is dictated by ipa-client-install in this case for all clients. -- / Alexander Bokovoy -------------- next part -------------- >From e6b2fc7c5c03b52281de51f22251ece77354f337 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 10:25:51 +0300 Subject: [PATCH 15/16] Make sure domain_name is also set when processing INP_NAME requests --- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 1 + 1 file changed, 1 insertion(+) 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 8aa22e1..823745e 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 @@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, &grp_result); } } + domain_name = strdup(req->data.name.domain_name); break; default: ret = LDAP_PROTOCOL_ERROR; -- 1.8.3.1 -------------- next part -------------- >From bff4b5cd1d3eb49a25c1072bb0baf6aecd719e20 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 10:26:22 +0300 Subject: [PATCH 16/16] Fix extdom plugin to provide unqualified name in response as sssd expects extdom plugin handles external operation over which SSSD asks IPA server about trusted domain users not found through normal paths but detected to belong to the trusted domains associated with IPA realm. SSSD expects that user or group name in the response will be unqualified because domain name for the user or group is also included in the response. Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully qualified name which includes the domain name we are asked to handle. The code already expects that fully-qualified names are following user at domain convention so we are simply tracking whether '@' symbol is present and is followed by the domain name. --- .../ipa-extdom-extop/ipa_extdom_common.c | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) 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 823745e..4b2abc2 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 @@ -339,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, const char *domain_name, struct extdom_res **_res) { int ret = EFAULT; + char *locat = NULL; struct extdom_res *res; res = calloc(1, sizeof(struct extdom_res)); @@ -355,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, switch(id_type) { case SSS_ID_TYPE_UID: case SSS_ID_TYPE_BOTH: + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { + if (strcasestr(locat, domain_name) != NULL ) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.pwd.pw_name); break; case SSS_ID_TYPE_GID: + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { + if (strcasestr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.grp.gr_name); break; @@ -394,6 +405,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_BOTH: res->response_type = RESP_USER; res->data.user.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { + if (strcasestr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.user.user_name = strdup(pg_data->data.pwd.pw_name); @@ -409,6 +425,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_GID: res->response_type = RESP_GROUP; res->data.group.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.grp.gr_name, '@')) != NULL) { + if (strcasestr(locat, domain_name) != NULL) { + locat[0] = 0; + } + } res->data.group.group_name = strdup(pg_data->data.grp.gr_name); @@ -439,6 +460,10 @@ done: free_resp_data(res); } + if (locat != NULL) { + locat[0] = '@'; + } + return ret; } -- 1.8.3.1 From jhrozek at redhat.com Tue Jul 9 09:42:00 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 9 Jul 2013 11:42:00 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130709073319.GA5205@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> Message-ID: <20130709094200.GH6481@hendrix.brq.redhat.com> On Tue, Jul 09, 2013 at 10:33:19AM +0300, Alexander Bokovoy wrote: > On Mon, 08 Jul 2013, Jakub Hrozek wrote: > >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: > >>On Mon, 08 Jul 2013, Jakub Hrozek wrote: > >>>On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: > >>>>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: > >>>>>On Wed, 03 Jul 2013, Sumit Bose wrote: > >>>>>>Hi, > >>>>>> > >>>>>>with this patch the extdom plugin, the LDAP extended operation that > >>>>>>allows IPA clients with recent SSSD to lookup AD users and groups, will > >>>>>>not use winbind for the lookup anymore but will use SSSD running in > >>>>>>ipa_server_mode. > >>>>>> > >>>>>>Since now no plugin uses the winbind client libraries anymore, the > >>>>>>second patch removes the related configures checks. > >>>>>> > >>>>>>I think for the time being we cannot remove winbind completely because > >>>>>>it might be needed for msbd to work properly in a trusted environment. > >>>>>s/msbd/smbd/ > >>>>> > >>>>>ACK. I need to add 'ipa_server_mode = True' support to > >>>>>the installer code and then these patches can go in. > >>>>Actually, the code still doesn't work due to some bug in sssd which > >>>>fails to respond properly to getsidbyname() request in libsss_nss_idmap. > >>>> > >>>>Additionally I've found one missing treatment of domain_name for > >>>>INP_NAME requests. > >>>> > >>>>We are working with Jakub on tracking down what's wrong on SSSD side. > >>> > >>>Indeed, there was a casing issue in sysdb. You can continue testing with > >>>lowercase user names in the meantime. A patch is already on the SSSD > >>>list. > >>In addition, we need to disqualify user name when returning back a > >>packet from extdom operation as this is what SSSD expects. > >> > >>Attached patch does it for all types of requests. > >> > >>-- > >>/ Alexander Bokovoy > > > >>>From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 > >>From: Alexander Bokovoy > >>Date: Mon, 8 Jul 2013 19:19:56 +0300 > >>Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as > >> sssd expects > >> > >>extdom plugin handles external operation over which SSSD asks IPA server about > >>trusted domain users not found through normal paths but detected to belong > >>to the trusted domains associated with IPA realm. > >> > >>SSSD expects that user or group name in the response will be unqualified > >>because domain name for the user or group is also included in the response. > >>Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully > >>qualified name which includes the domain name we are asked to handle. > >> > >>The code already expects that fully-qualified names are following user at domain > >>convention so we are simply tracking whether '@' symbol is present and is followed > >>by the domain name. > >>--- > >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ > >> 1 file changed, 26 insertions(+) > >> > >>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 8aa22e1..290da4e 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 > >>@@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > >> &grp_result); > >> } > >> } > >>+ domain_name = strdup(req->data.name.domain_name); > > > >I would prefer if this was a separate patch. But this is a correct > >change. > Separated. > Ack to this patch. > > > >> break; > >> default: > >> ret = LDAP_PROTOCOL_ERROR; > >>@@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > >> const char *domain_name, struct extdom_res **_res) > >> { > >> int ret = EFAULT; > >>+ char *locat = NULL; > >> struct extdom_res *res; > >> > >> res = calloc(1, sizeof(struct extdom_res)); > >>@@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > >> switch(id_type) { > >> case SSS_ID_TYPE_UID: > >> case SSS_ID_TYPE_BOTH: > >>+ if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > >>+ if (strstr(locat, domain_name) != NULL ) { > > > >strstr doesn't work correctly in my case. In SSSD, the domain names are > >case-insensitive, so you can use strcasestr here. In my case, the > >condition is never hit as the domain case differs: > > > >407 res->data.user.domain_name = strdup(domain_name); > >(gdb) > >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > >(gdb) n > >409 if (strstr(locat, domain_name) != NULL) { > >(gdb) > >414 strdup(pg_data->data.pwd.pw_name); > >(gdb) p domain_name > >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" > >(gdb) p locat > >$2 = 0x7f2e8006500d "@ad.example.com" > Replaced by strcasestr. > > > > > >Also, this is good enough for the beta or when the default values are used, but > >in theory, the admin could configure the fully qualified name format to not > >include the @-sign (see full_name_format in sssd.conf) at all. > > > >It's not very likely, but I think we should account for that case > >eventually. I'm not exactly sure how yet as the full_name_format is pretty > >free-form, maybe we could simply disallow setting it if server_mode was > >set to True. > I'd prefer the latter indeed. Given that you can have full_name_format > varying between servers and clients, this is simply asking for disaster. > > I'd preper concentrating our effort on making default configuration > working so well that you never need to modify these parameters. After > all, we are talking about SSSD use as FreeIPA client with trusts > enabled. SSSD configuration is dictated by ipa-client-install in this > case for all clients. And Ack to the second patch as well. I opened https://fedorahosted.org/sssd/ticket/2009 on the SSSD side to make the behaviour more predictable and robust. From jhrozek at redhat.com Tue Jul 9 09:56:50 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 9 Jul 2013 11:56:50 +0200 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130703125355.GO27655@localhost.localdomain> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> Message-ID: <20130709095650.GI6481@hendrix.brq.redhat.com> On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: > On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: > > On Mon, 01 Jul 2013, Sumit Bose wrote: > > >Hi, > > > > > >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only > > >to allow SSSD running on a FreeIPA server to access the AD LDAP server. > > >In the ticket a more generic solution is described but since there is no > > >other use case so far I think this patch is sufficient for the time > > >being. > > > > > >bye, > > >Sumit > > > > >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 > > >From: Sumit Bose > > >Date: Mon, 1 Jul 2013 13:47:22 +0200 > > >Subject: [PATCH] Add PAC to master host TGTs > > > > > >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is > > >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server > > >of a trusted domain with the credentials of a FreeIPA server host a > > >PAC must be added to the TGT for the host. > > s/SALS/SASL/ > > Thank you for the review, I've fixed the typo and added the numerical > values for the well-known RIDs to the commit message. > > > > > > > >To determine if a host is a FreeIPA server or not it is checked if there > > >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately > > >this requires an additional LDAP lookup. But since TGS-REQs for hosts > > >should be rare I think it is acceptable for the time being. > > I think it is better to change this lookup to > > "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would > > explicitly limit us to the IPA masters running AD trusts. > > I'm not sure if this restriction is needed. With SSSD's ipa_server_mode > any IPA master (which networkwise can access an AD server of the trusted > domain) can read AD user and group data, no running smbd or winbind is > required. So it would be possible to run the extdom plugin or the compat > plugin for the legacy clients on any IPA server which would allow a much > better load balancing. > > If there are other concerns I'm happy to add the restriction. > > bye, > Sumit I don't think I know the code good enough to provide a full review, but the patch enables the lookups from an IPA master without any additional hacks. So ack on functionality at least. From jhrozek at redhat.com Tue Jul 9 10:01:33 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 9 Jul 2013 12:01:33 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130709094200.GH6481@hendrix.brq.redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> <20130709094200.GH6481@hendrix.brq.redhat.com> Message-ID: <20130709100133.GJ6481@hendrix.brq.redhat.com> On Tue, Jul 09, 2013 at 11:42:00AM +0200, Jakub Hrozek wrote: > On Tue, Jul 09, 2013 at 10:33:19AM +0300, Alexander Bokovoy wrote: > > On Mon, 08 Jul 2013, Jakub Hrozek wrote: > > >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: > > >>On Mon, 08 Jul 2013, Jakub Hrozek wrote: > > >>>On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: > > >>>>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: > > >>>>>On Wed, 03 Jul 2013, Sumit Bose wrote: > > >>>>>>Hi, > > >>>>>> > > >>>>>>with this patch the extdom plugin, the LDAP extended operation that > > >>>>>>allows IPA clients with recent SSSD to lookup AD users and groups, will > > >>>>>>not use winbind for the lookup anymore but will use SSSD running in > > >>>>>>ipa_server_mode. > > >>>>>> > > >>>>>>Since now no plugin uses the winbind client libraries anymore, the > > >>>>>>second patch removes the related configures checks. > > >>>>>> > > >>>>>>I think for the time being we cannot remove winbind completely because > > >>>>>>it might be needed for msbd to work properly in a trusted environment. > > >>>>>s/msbd/smbd/ > > >>>>> > > >>>>>ACK. I need to add 'ipa_server_mode = True' support to > > >>>>>the installer code and then these patches can go in. > > >>>>Actually, the code still doesn't work due to some bug in sssd which > > >>>>fails to respond properly to getsidbyname() request in libsss_nss_idmap. > > >>>> > > >>>>Additionally I've found one missing treatment of domain_name for > > >>>>INP_NAME requests. > > >>>> > > >>>>We are working with Jakub on tracking down what's wrong on SSSD side. > > >>> > > >>>Indeed, there was a casing issue in sysdb. You can continue testing with > > >>>lowercase user names in the meantime. A patch is already on the SSSD > > >>>list. > > >>In addition, we need to disqualify user name when returning back a > > >>packet from extdom operation as this is what SSSD expects. > > >> > > >>Attached patch does it for all types of requests. > > >> > > >>-- > > >>/ Alexander Bokovoy > > > > > >>>From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 > > >>From: Alexander Bokovoy > > >>Date: Mon, 8 Jul 2013 19:19:56 +0300 > > >>Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as > > >> sssd expects > > >> > > >>extdom plugin handles external operation over which SSSD asks IPA server about > > >>trusted domain users not found through normal paths but detected to belong > > >>to the trusted domains associated with IPA realm. > > >> > > >>SSSD expects that user or group name in the response will be unqualified > > >>because domain name for the user or group is also included in the response. > > >>Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully > > >>qualified name which includes the domain name we are asked to handle. > > >> > > >>The code already expects that fully-qualified names are following user at domain > > >>convention so we are simply tracking whether '@' symbol is present and is followed > > >>by the domain name. > > >>--- > > >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ > > >> 1 file changed, 26 insertions(+) > > >> > > >>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 8aa22e1..290da4e 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 > > >>@@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > > >> &grp_result); > > >> } > > >> } > > >>+ domain_name = strdup(req->data.name.domain_name); > > > > > >I would prefer if this was a separate patch. But this is a correct > > >change. > > Separated. > > > > Ack to this patch. > > > > > > >> break; > > >> default: > > >> ret = LDAP_PROTOCOL_ERROR; > > >>@@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > > >> const char *domain_name, struct extdom_res **_res) > > >> { > > >> int ret = EFAULT; > > >>+ char *locat = NULL; > > >> struct extdom_res *res; > > >> > > >> res = calloc(1, sizeof(struct extdom_res)); > > >>@@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > > >> switch(id_type) { > > >> case SSS_ID_TYPE_UID: > > >> case SSS_ID_TYPE_BOTH: > > >>+ if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > > >>+ if (strstr(locat, domain_name) != NULL ) { > > > > > >strstr doesn't work correctly in my case. In SSSD, the domain names are > > >case-insensitive, so you can use strcasestr here. In my case, the > > >condition is never hit as the domain case differs: > > > > > >407 res->data.user.domain_name = strdup(domain_name); > > >(gdb) > > >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > > >(gdb) n > > >409 if (strstr(locat, domain_name) != NULL) { > > >(gdb) > > >414 strdup(pg_data->data.pwd.pw_name); > > >(gdb) p domain_name > > >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" > > >(gdb) p locat > > >$2 = 0x7f2e8006500d "@ad.example.com" > > Replaced by strcasestr. > > > > > > > > > >Also, this is good enough for the beta or when the default values are used, but > > >in theory, the admin could configure the fully qualified name format to not > > >include the @-sign (see full_name_format in sssd.conf) at all. > > > > > >It's not very likely, but I think we should account for that case > > >eventually. I'm not exactly sure how yet as the full_name_format is pretty > > >free-form, maybe we could simply disallow setting it if server_mode was > > >set to True. > > I'd prefer the latter indeed. Given that you can have full_name_format > > varying between servers and clients, this is simply asking for disaster. > > > > I'd preper concentrating our effort on making default configuration > > working so well that you never need to modify these parameters. After > > all, we are talking about SSSD use as FreeIPA client with trusts > > enabled. SSSD configuration is dictated by ipa-client-install in this > > case for all clients. > > And Ack to the second patch as well. > > I opened https://fedorahosted.org/sssd/ticket/2009 on the SSSD side to > make the behaviour more predictable and robust. btw of course I tested with Sumit's patches applied before these two. They are quite large and I don't think I can review them, but from purely functional point of view, ack. From abokovoy at redhat.com Tue Jul 9 11:12:33 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 9 Jul 2013 14:12:33 +0300 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130709095650.GI6481@hendrix.brq.redhat.com> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> Message-ID: <20130709111233.GB5205@redhat.com> On Tue, 09 Jul 2013, Jakub Hrozek wrote: >On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: >> On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: >> > On Mon, 01 Jul 2013, Sumit Bose wrote: >> > >Hi, >> > > >> > >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only >> > >to allow SSSD running on a FreeIPA server to access the AD LDAP server. >> > >In the ticket a more generic solution is described but since there is no >> > >other use case so far I think this patch is sufficient for the time >> > >being. >> > > >> > >bye, >> > >Sumit >> > >> > >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 >> > >From: Sumit Bose >> > >Date: Mon, 1 Jul 2013 13:47:22 +0200 >> > >Subject: [PATCH] Add PAC to master host TGTs >> > > >> > >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is >> > >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server >> > >of a trusted domain with the credentials of a FreeIPA server host a >> > >PAC must be added to the TGT for the host. >> > s/SALS/SASL/ >> >> Thank you for the review, I've fixed the typo and added the numerical >> values for the well-known RIDs to the commit message. >> >> > >> > >> > >To determine if a host is a FreeIPA server or not it is checked if there >> > >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately >> > >this requires an additional LDAP lookup. But since TGS-REQs for hosts >> > >should be rare I think it is acceptable for the time being. >> > I think it is better to change this lookup to >> > "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would >> > explicitly limit us to the IPA masters running AD trusts. >> >> I'm not sure if this restriction is needed. With SSSD's ipa_server_mode >> any IPA master (which networkwise can access an AD server of the trusted >> domain) can read AD user and group data, no running smbd or winbind is >> required. So it would be possible to run the extdom plugin or the compat >> plugin for the legacy clients on any IPA server which would allow a much >> better load balancing. >> >> If there are other concerns I'm happy to add the restriction. >> >> bye, >> Sumit > >I don't think I know the code good enough to provide a full review, but >the patch enables the lookups from an IPA master without any additional >hacks. So ack on functionality at least. Ok. I've extended this functionality to generate MS-PAC also for services running on IPA masters. Patch attached. This is needed to finally get rid of access to trust auth material for IPA python code. HTTP/fqdn at REALM will now be able to authenticate against AD LDAP server and look up needed information directly, without elevating privileges to trust admins. This should also help for AD range discovery Tomas is working on. -- / Alexander Bokovoy -------------- next part -------------- >From 0d377b563edbc31342f1a026deac660b55322f86 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 14:05:02 +0300 Subject: [PATCH 17/17] Generate syntethic MS-PAC for all services running on IPA master MS-PAC is required to be present in TGT if one wants to connect to AD services using this TGT. Users get MS-PAC by default, SSSD in ipa_server_mode uses host/fqdn at REALM principal to talk to AD LDAP. This patch enables other services running on IPA master to connect to AD services. This is required for IPA python code doing discovery of remote AD domain settings shortly after IPA-AD trust has been established. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 56 +++++++++++++++++++++++++++++++++-------- 1 file changed, 46 insertions(+), 10 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 92dc8dd..f1df022 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -60,6 +60,7 @@ static char *user_pac_attrs[] = { "cn", "fqdn", "gidNumber", + "managedBy", "krbPrincipalName", "krbCanonicalName", "krbTicketPolicyReference", @@ -359,15 +360,33 @@ static int sid_split_rid(struct dom_sid *sid, uint32_t *rid) return 0; } -static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn) +static bool is_master_host(struct ipadb_context *ipactx, const char *fqdn, bool managedby) { int ret; char *master_host_base = NULL; + char *master_fqdn = NULL; LDAPMessage *result = NULL; krb5_error_code err; - ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", - fqdn, ipactx->base); + if (managedby) { + err = ipadb_simple_search(ipactx, (char*) fqdn, LDAP_SCOPE_BASE, + NULL, NULL, &result); + if (err == 0) { + ret = ipadb_ldap_attr_to_str(ipactx->lcontext, result, "fqdn", &master_fqdn); + if (ret == 0) { + ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", + master_fqdn, ipactx->base); + } + free(master_fqdn); + ldap_msgfree(result); + } else { + ldap_msgfree(result); + return false; + } + } else { + ret = asprintf(&master_host_base, "cn=%s,cn=masters,cn=ipa,cn=etc,%s", + fqdn, ipactx->base); + } if (ret == -1) { return false; } @@ -399,6 +418,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, size_t c; bool is_host = false; bool is_user = false; + bool is_service = false; ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "objectClass", &objectclasses); @@ -407,6 +427,9 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, if (strcasecmp(objectclasses[c], "ipaHost") == 0) { is_host = true; } + if (strcasecmp(objectclasses[c], "ipaService") == 0) { + is_service = true; + } if (strcasecmp(objectclasses[c], "ipaNTUserAttrs") == 0) { is_user = true; } @@ -415,8 +438,8 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } free(objectclasses); - if (!is_host && !is_user) { - /* We only handle users and hosts */ + if (!is_host && !is_user && !is_service) { + /* We only handle users and hosts, and services */ return ENOENT; } @@ -429,7 +452,20 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, /* Currently we only add a PAC to TGTs for IPA servers to allow SSSD in * ipa_server_mode to access the AD LDAP server */ - if (!is_master_host(ipactx, strres)) { + if (!is_master_host(ipactx, strres, false)) { + free(strres); + return ENOENT; + } + } else if (is_service) { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "managedBy", &strres); + if (ret) { + /* managedby is mandatory for services */ + return ret; + } + + /* Only add PAC to TGT to services on IPA masters to allow querying + * AD LDAP server */ + if (!is_master_host(ipactx, strres, true)) { free(strres); return ENOENT; } @@ -444,7 +480,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.account_name.string = talloc_strdup(memctx, strres); free(strres); - if (is_host) { + if (is_host || is_service) { prigid = 515; /* Well known RID for domain computers group */ } else { ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); @@ -567,7 +603,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.logon_count = 0; /* we do not have this info yet */ info3->base.bad_password_count = 0; /* we do not have this info yet */ - if (is_host) { + if (is_host || is_service) { /* Well know RID of domain controllers group */ info3->base.rid = 516; } else { @@ -658,7 +694,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } if (info3->base.primary_gid == 0) { - if (is_host) { + if (is_host || is_service) { info3->base.primary_gid = 515; /* Well known RID for domain computers group */ } else { if (ipactx->mspac->fallback_rid) { @@ -698,7 +734,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, return ENOENT; } - if (is_host) { + if (is_host || is_service) { info3->base.domain_sid = talloc_memdup(memctx, &ipactx->mspac->domsid, sizeof(ipactx->mspac->domsid)); } else { -- 1.8.3.1 From jcholast at redhat.com Tue Jul 9 12:32:03 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 09 Jul 2013 14:32:03 +0200 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively Message-ID: <51DC02C3.8040507@redhat.com> Hi, the attached patches fix . Also added a small patch to fix a formatting issue with installutils.read_password. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-149-Ask-for-PKCS-12-password-interactively-in-ipa-server.patch Type: text/x-patch Size: 4911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-150-Ask-for-PKCS-12-password-interactively-in-ipa-replic.patch Type: text/x-patch Size: 3757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-151-Print-newline-after-receiving-EOF-in-installutils.re.patch Type: text/x-patch Size: 8163 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jul 9 15:37:02 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 09 Jul 2013 17:37:02 +0200 Subject: [Freeipa-devel] Web UI integration tests In-Reply-To: <51C41530.7000300@redhat.com> References: <51C41530.7000300@redhat.com> Message-ID: <51DC2E1E.2080005@redhat.com> On 06/21/2013 10:56 AM, Petr Vobornik wrote: > Sending an initial implementation of Web UI integration tests. The effort is > documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . > > The coverage is not complete but rather basic. Sending it now as this is > ongoing task. > > Currently it tries to open all facets and dialogs and perform > add,mod,find,delete,add/remove associations for every entity except trusts (to > be implemented). > > First two attached patches are changing Web UI to be little more test-friendly > - they add some names to element and such. Tests are in the last patch. > > https://fedorahosted.org/freeipa/ticket/3744 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I tried setting up and running the new tests, and overall it works really well. The documentation page is very clear and to the point, and the setup script is especially handy. Thanks! Below are some comments (mostly related to the python code in ui_driver.py). - I got whitespace warnings when applying patch 424 - ui_driver.py:110 - Should be 'except IOError, e', as you use 'e' within the except clause. - ui_driver.py:110 - There's too much code in the try block. We should have as little code as possible in the try block (ideally only the code that could actually raise the exception). - ui_driver.py:200 - It says 'single' in the docstring, but the argument name is 'all'. - ui_driver.py:205 - Instead of raising ValueError, I would prefer something like: assert expression, 'expression is missing' - ui_driver.py:643 - There's a print statement, I assume a leftover from some debugging. :) -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Jul 9 15:45:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jul 2013 11:45:58 -0400 Subject: [Freeipa-devel] [PATCH] 0041 Fix bug in adtrustinstance In-Reply-To: <20130708072004.GF3956@redhat.com> References: <51C9A246.1020201@redhat.com> <20130708072004.GF3956@redhat.com> Message-ID: <51DC3036.5080104@redhat.com> Alexander Bokovoy wrote: > On Tue, 25 Jun 2013, Ana Krivokapic wrote: >> Hello, >> >> Attached patch fixes https://fedorahosted.org/freeipa/ticket/3746. >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> > >> From 548f1626dbf9edf45bfcab358b28e510d1ec5757 Mon Sep 17 00:00:00 2001 >> From: Ana Krivokapic >> Date: Tue, 25 Jun 2013 15:52:29 +0200 >> Subject: [PATCH] Fix bug in adtrustinstance >> >> Incorrect tuple unpacking in adtrustinstance was causing >> ipa-adtrust-install >> to fail when IPA was installed with no DNS. >> >> https://fedorahosted.org/freeipa/ticket/3746 >> --- >> ipaserver/install/adtrustinstance.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipaserver/install/adtrustinstance.py >> b/ipaserver/install/adtrustinstance.py >> index >> d2929801b431625764e5b949349ab63d2caaf696..4eb20d9517906df0b1952fe5033a050f3b55a797 >> 100644 >> --- a/ipaserver/install/adtrustinstance.py >> +++ b/ipaserver/install/adtrustinstance.py >> @@ -535,9 +535,9 @@ def __add_dns_service_records(self): >> self.print_msg(err_msg) >> self.print_msg("Add the following service records to your >> DNS " \ >> "server for DNS zone %s: " % zone) >> - for (srv, rdata) in ipa_srv_rec: >> + for srv in ipa_srv_rec: >> for suff in win_srv_suffix: >> - self.print_msg(" - %s%s" % (srv, suff)) >> + self.print_msg(" - %s%s" % (srv[0], suff)) >> return >> >> for (srv, rdata, port) in ipa_srv_rec: > ACK. > > pushed to master and ipa-3-2 From rcritten at redhat.com Tue Jul 9 15:49:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jul 2013 11:49:13 -0400 Subject: [Freeipa-devel] [PATCH] 427 Disable checkboxes and radios for readonly attributes In-Reply-To: <20130708072343.GH3956@redhat.com> References: <51CD88ED.3040600@redhat.com> <20130708072343.GH3956@redhat.com> Message-ID: <51DC30F9.6060509@redhat.com> Alexander Bokovoy wrote: > On Fri, 28 Jun 2013, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/3764 > ACK > pushed to master and ipa-3-2 From rcritten at redhat.com Tue Jul 9 16:20:38 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jul 2013 12:20:38 -0400 Subject: [Freeipa-devel] [PATCH] Fix client install exception if /etc/ssh is missing In-Reply-To: <1373041218.27700.14.camel@localhost.localdomain> References: <1372882314.27700.3.camel@localhost.localdomain> <51D53E4C.9030509@redhat.com> <1373041218.27700.14.camel@localhost.localdomain> Message-ID: <51DC3856.4090207@redhat.com> Nathaniel McCallum wrote: > On Thu, 2013-07-04 at 11:20 +0200, Jan Cholasta wrote: >> On 3.7.2013 22:11, Nathaniel McCallum wrote: >>> https://fedorahosted.org/freeipa/ticket/3766 >>> >> >> If the directory doesn't exist, update_ssh_keys is no-op, so I would prefer >> >> if not os.path.isdir(ssh_dir): >> return >> >> at the beginning of update_ssh_keys instead. > > Attached. > > I don't care which version of the patch gets merged... ACK, pushed to master and ipa-3-2 rob From rcritten at redhat.com Tue Jul 9 18:24:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Jul 2013 14:24:30 -0400 Subject: [Freeipa-devel] [PATCH] 148 Skip cert issuer validation in service and host commands in CA-less install In-Reply-To: <51DA4A2D.1060406@redhat.com> References: <51DA4A2D.1060406@redhat.com> Message-ID: <51DC555E.1000701@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza ACK, pushed to master and ipa-3-2 rob From jhrozek at redhat.com Tue Jul 9 20:39:23 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 9 Jul 2013 22:39:23 +0200 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130709111233.GB5205@redhat.com> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> Message-ID: <20130709203923.GP6481@hendrix.brq.redhat.com> On Tue, Jul 09, 2013 at 02:12:33PM +0300, Alexander Bokovoy wrote: > On Tue, 09 Jul 2013, Jakub Hrozek wrote: > >On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: > >>On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: > >>> On Mon, 01 Jul 2013, Sumit Bose wrote: > >>> >Hi, > >>> > > >>> >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only > >>> >to allow SSSD running on a FreeIPA server to access the AD LDAP server. > >>> >In the ticket a more generic solution is described but since there is no > >>> >other use case so far I think this patch is sufficient for the time > >>> >being. > >>> > > >>> >bye, > >>> >Sumit > >>> > >>> >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 > >>> >From: Sumit Bose > >>> >Date: Mon, 1 Jul 2013 13:47:22 +0200 > >>> >Subject: [PATCH] Add PAC to master host TGTs > >>> > > >>> >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is > >>> >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server > >>> >of a trusted domain with the credentials of a FreeIPA server host a > >>> >PAC must be added to the TGT for the host. > >>> s/SALS/SASL/ > >> > >>Thank you for the review, I've fixed the typo and added the numerical > >>values for the well-known RIDs to the commit message. > >> > >>> > >>> > >>> >To determine if a host is a FreeIPA server or not it is checked if there > >>> >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately > >>> >this requires an additional LDAP lookup. But since TGS-REQs for hosts > >>> >should be rare I think it is acceptable for the time being. > >>> I think it is better to change this lookup to > >>> "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would > >>> explicitly limit us to the IPA masters running AD trusts. > >> > >>I'm not sure if this restriction is needed. With SSSD's ipa_server_mode > >>any IPA master (which networkwise can access an AD server of the trusted > >>domain) can read AD user and group data, no running smbd or winbind is > >>required. So it would be possible to run the extdom plugin or the compat > >>plugin for the legacy clients on any IPA server which would allow a much > >>better load balancing. > >> > >>If there are other concerns I'm happy to add the restriction. > >> > >>bye, > >>Sumit > > > >I don't think I know the code good enough to provide a full review, but > >the patch enables the lookups from an IPA master without any additional > >hacks. So ack on functionality at least. > Ok. > > I've extended this functionality to generate MS-PAC also for services > running on IPA masters. Patch attached. > > This is needed to finally get rid of access to trust auth material for > IPA python code. HTTP/fqdn at REALM will now be able to authenticate > against AD LDAP server and look up needed information directly, without > elevating privileges to trust admins. > > This should also help for AD range discovery Tomas is working on. > Hi, The patch looks good to me so I'm giving my +1. I would appreciate other review too before a full ack, though. From lslebodn at redhat.com Wed Jul 10 08:29:35 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 10 Jul 2013 10:29:35 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <51D57744.5080807@redhat.com> References: <51D57744.5080807@redhat.com> Message-ID: <20130710082934.GA7205@mail.corp.redhat.com> On (04/07/13 15:23), Petr Spacek wrote: >Hello, > >several warnings from autotools popped up after upgrade to Fedora 19. >Attached patches should make autotools configuration more modern. > >-- >Petr^2 Spacek >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Thu, 4 Jul 2013 14:04:57 +0200 >Subject: [PATCH] Add missing ar check to configure.ac. > >Signed-off-by: Petr Spacek >--- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/configure.ac b/configure.ac >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) > AC_DISABLE_STATIC > > # Checks for programs. >+AM_PROG_AR > AC_PROG_CC > AC_PROG_LIBTOOL > >-- >1.8.3.1 > This solution is not very portable. Automake <= 1.11 does not contain this macro. configure.ac:14: warning: macro `AM_PROG_AR' not found in library configure.ac:14: error: possibly undefined macro: AM_PROG_AR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 Better solution will be: m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) You can find more information about this in mail thread http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html >From 282f9763d0b0cc63a56161b402091c9f1fe7f279 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Thu, 4 Jul 2013 14:05:57 +0200 >Subject: [PATCH] Put m4 macros from autotools to separate sub-directory. > >Signed-off-by: Petr Spacek >--- > Makefile.am | 2 ++ > configure.ac | 1 + > 2 files changed, 3 insertions(+) > >diff --git a/Makefile.am b/Makefile.am >index 8d713c44a889b6a8f1d80ba9780de1287d641227..f5ff369861e3a8fd686f3eb36934df01c38fe597 100644 >--- a/Makefile.am >+++ b/Makefile.am >@@ -1,3 +1,5 @@ >+ACLOCAL_AMFLAGS = -I m4 >+ > SUBDIRS = doc src > > doc_DATA = README NEWS >diff --git a/configure.ac b/configure.ac >index b6d66de1b862a6860226a5f9ae4a3f33842e6100..dfe0ac39adcd779e9df8ba6feab723d32af20c48 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -5,6 +5,7 @@ AM_INIT_AUTOMAKE([-Wall foreign dist-bzip2]) > > AC_CONFIG_SRCDIR([src/zone_manager.h]) > AC_CONFIG_HEADERS([config.h]) >+AC_CONFIG_MACRO_DIR([m4]) > > # Disable static libraries > AC_DISABLE_STATIC >-- >1.8.3.1 > ACK to the 2nd patch LS From jhrozek at redhat.com Wed Jul 10 08:48:27 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Jul 2013 10:48:27 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710082934.GA7205@mail.corp.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> Message-ID: <20130710084827.GU6481@hendrix.brq.redhat.com> On Wed, Jul 10, 2013 at 10:29:35AM +0200, Lukas Slebodnik wrote: > On (04/07/13 15:23), Petr Spacek wrote: > >Hello, > > > >several warnings from autotools popped up after upgrade to Fedora 19. > >Attached patches should make autotools configuration more modern. > > > >-- > >Petr^2 Spacek > > >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 > >From: Petr Spacek > >Date: Thu, 4 Jul 2013 14:04:57 +0200 > >Subject: [PATCH] Add missing ar check to configure.ac. > > > >Signed-off-by: Petr Spacek > >--- > > configure.ac | 1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/configure.ac b/configure.ac > >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 > >--- a/configure.ac > >+++ b/configure.ac > >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) > > AC_DISABLE_STATIC > > > > # Checks for programs. > >+AM_PROG_AR > > AC_PROG_CC > > AC_PROG_LIBTOOL > > > >-- > >1.8.3.1 > > > > This solution is not very portable. Automake <= 1.11 does not contain this > macro. > > configure.ac:14: warning: macro `AM_PROG_AR' not found in library > configure.ac:14: error: possibly undefined macro: AM_PROG_AR > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > Better solution will be: > m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > > You can find more information about this in mail thread > http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html Even better is: m4_pattern_allow([AM_PROG_AR]) AM_PROG_AR From lslebodn at redhat.com Wed Jul 10 08:59:10 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 10 Jul 2013 10:59:10 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710084827.GU6481@hendrix.brq.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <20130710084827.GU6481@hendrix.brq.redhat.com> Message-ID: <20130710085909.GC7205@mail.corp.redhat.com> On (10/07/13 10:48), Jakub Hrozek wrote: >On Wed, Jul 10, 2013 at 10:29:35AM +0200, Lukas Slebodnik wrote: >> On (04/07/13 15:23), Petr Spacek wrote: >> >Hello, >> > >> >several warnings from autotools popped up after upgrade to Fedora 19. >> >Attached patches should make autotools configuration more modern. >> > >> >-- >> >Petr^2 Spacek >> >> >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >> >From: Petr Spacek >> >Date: Thu, 4 Jul 2013 14:04:57 +0200 >> >Subject: [PATCH] Add missing ar check to configure.ac. >> > >> >Signed-off-by: Petr Spacek >> >--- >> > configure.ac | 1 + >> > 1 file changed, 1 insertion(+) >> > >> >diff --git a/configure.ac b/configure.ac >> >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 >> >--- a/configure.ac >> >+++ b/configure.ac >> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >> > AC_DISABLE_STATIC >> > >> > # Checks for programs. >> >+AM_PROG_AR >> > AC_PROG_CC >> > AC_PROG_LIBTOOL >> > >> >-- >> >1.8.3.1 >> > >> >> This solution is not very portable. Automake <= 1.11 does not contain this >> macro. >> >> configure.ac:14: warning: macro `AM_PROG_AR' not found in library >> configure.ac:14: error: possibly undefined macro: AM_PROG_AR >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> autoreconf: /usr/bin/autoconf failed with exit status: 1 >> >> Better solution will be: >> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> >> You can find more information about this in mail thread >> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html You probably did not read this page ^^^^^ >>Even better is: >m4_pattern_allow([AM_PROG_AR]) >AM_PROG_AR m4_pattern_allow should be used for another things. http://www.gnu.org/software/autoconf/manual/autoconf.html#Forbidden-Patterns LS From jhrozek at redhat.com Wed Jul 10 09:14:10 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Jul 2013 11:14:10 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710085909.GC7205@mail.corp.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <20130710084827.GU6481@hendrix.brq.redhat.com> <20130710085909.GC7205@mail.corp.redhat.com> Message-ID: <20130710091410.GX6481@hendrix.brq.redhat.com> On Wed, Jul 10, 2013 at 10:59:10AM +0200, Lukas Slebodnik wrote: > On (10/07/13 10:48), Jakub Hrozek wrote: > >On Wed, Jul 10, 2013 at 10:29:35AM +0200, Lukas Slebodnik wrote: > >> On (04/07/13 15:23), Petr Spacek wrote: > >> >Hello, > >> > > >> >several warnings from autotools popped up after upgrade to Fedora 19. > >> >Attached patches should make autotools configuration more modern. > >> > > >> >-- > >> >Petr^2 Spacek > >> > >> >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 > >> >From: Petr Spacek > >> >Date: Thu, 4 Jul 2013 14:04:57 +0200 > >> >Subject: [PATCH] Add missing ar check to configure.ac. > >> > > >> >Signed-off-by: Petr Spacek > >> >--- > >> > configure.ac | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> >diff --git a/configure.ac b/configure.ac > >> >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 > >> >--- a/configure.ac > >> >+++ b/configure.ac > >> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) > >> > AC_DISABLE_STATIC > >> > > >> > # Checks for programs. > >> >+AM_PROG_AR > >> > AC_PROG_CC > >> > AC_PROG_LIBTOOL > >> > > >> >-- > >> >1.8.3.1 > >> > > >> > >> This solution is not very portable. Automake <= 1.11 does not contain this > >> macro. > >> > >> configure.ac:14: warning: macro `AM_PROG_AR' not found in library > >> configure.ac:14: error: possibly undefined macro: AM_PROG_AR > >> If this token and others are legitimate, please use m4_pattern_allow. > >> See the Autoconf documentation. > >> autoreconf: /usr/bin/autoconf failed with exit status: 1 > >> > >> Better solution will be: > >> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > >> > >> You can find more information about this in mail thread > >> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html > You probably did not read this page ^^^^^ No I didn't :) But what the guy says there isn't true, m4_pattern_allow works just fine even with the old autoconf version in RHEL5. > > >>Even better is: > >m4_pattern_allow([AM_PROG_AR]) > >AM_PROG_AR > > m4_pattern_allow should be used for another things. > http://www.gnu.org/software/autoconf/manual/autoconf.html#Forbidden-Patterns Dunno, I think it'quite pretty established pattern. Is there something wrong with it? From lslebodn at redhat.com Wed Jul 10 09:59:32 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 10 Jul 2013 11:59:32 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710091410.GX6481@hendrix.brq.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <20130710084827.GU6481@hendrix.brq.redhat.com> <20130710085909.GC7205@mail.corp.redhat.com> <20130710091410.GX6481@hendrix.brq.redhat.com> Message-ID: <20130710095931.GD7205@mail.corp.redhat.com> On (10/07/13 11:14), Jakub Hrozek wrote: >On Wed, Jul 10, 2013 at 10:59:10AM +0200, Lukas Slebodnik wrote: >> On (10/07/13 10:48), Jakub Hrozek wrote: >> >On Wed, Jul 10, 2013 at 10:29:35AM +0200, Lukas Slebodnik wrote: >> >> On (04/07/13 15:23), Petr Spacek wrote: >> >> >Hello, >> >> > >> >> >several warnings from autotools popped up after upgrade to Fedora 19. >> >> >Attached patches should make autotools configuration more modern. >> >> > >> >> >-- >> >> >Petr^2 Spacek >> >> >> >> >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >> >> >From: Petr Spacek >> >> >Date: Thu, 4 Jul 2013 14:04:57 +0200 >> >> >Subject: [PATCH] Add missing ar check to configure.ac. >> >> > >> >> >Signed-off-by: Petr Spacek >> >> >--- >> >> > configure.ac | 1 + >> >> > 1 file changed, 1 insertion(+) >> >> > >> >> >diff --git a/configure.ac b/configure.ac >> >> >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 >> >> >--- a/configure.ac >> >> >+++ b/configure.ac >> >> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >> >> > AC_DISABLE_STATIC >> >> > >> >> > # Checks for programs. >> >> >+AM_PROG_AR >> >> > AC_PROG_CC >> >> > AC_PROG_LIBTOOL >> >> > >> >> >-- >> >> >1.8.3.1 >> >> > >> >> >> >> This solution is not very portable. Automake <= 1.11 does not contain this >> >> macro. >> >> >> >> configure.ac:14: warning: macro `AM_PROG_AR' not found in library >> >> configure.ac:14: error: possibly undefined macro: AM_PROG_AR >> >> If this token and others are legitimate, please use m4_pattern_allow. >> >> See the Autoconf documentation. >> >> autoreconf: /usr/bin/autoconf failed with exit status: 1 >> >> >> >> Better solution will be: >> >> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> >> >> >> You can find more information about this in mail thread >> >> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html >> You probably did not read this page ^^^^^ > >No I didn't :) > >But what the guy says there isn't true, m4_pattern_allow works just fine >even with the old autoconf version in RHEL5. > >> >> >>Even better is: >> >m4_pattern_allow([AM_PROG_AR]) >> >AM_PROG_AR >> >> m4_pattern_allow should be used for another things. >> http://www.gnu.org/software/autoconf/manual/autoconf.html#Forbidden-Patterns > >Dunno, I think it'quite pretty established pattern. Is there something wrong >with it? Macro "m4_pattern_allow" only suppresses autotool error "possibly undefined macro", but there still will be a warning "macro `AM_PROG_AR' not found in library" Autreconf will not fail with older versions of automake (<=1.11), but macro AM_PROG_AR will not be expanded and you can find this "unexpanded text" in configure script. It is harmless. Everything will work well, but we don't like warnings. LS From pspacek at redhat.com Wed Jul 10 10:27:08 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Jul 2013 12:27:08 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710082934.GA7205@mail.corp.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> Message-ID: <51DD36FC.3070201@redhat.com> On 10.7.2013 10:29, Lukas Slebodnik wrote: > On (04/07/13 15:23), Petr Spacek wrote: >> >Hello, >> > >> >several warnings from autotools popped up after upgrade to Fedora 19. >> >Attached patches should make autotools configuration more modern. >> > >> >-- >> >Petr^2 Spacek >>From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >> >From: Petr Spacek >> >Date: Thu, 4 Jul 2013 14:04:57 +0200 >> >Subject: [PATCH] Add missing ar check to configure.ac. >> > >> >Signed-off-by: Petr Spacek >> >--- >> >configure.ac | 1 + >> >1 file changed, 1 insertion(+) >> > >> >diff --git a/configure.ac b/configure.ac >> >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 >> >--- a/configure.ac >> >+++ b/configure.ac >> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >> >AC_DISABLE_STATIC >> > >> ># Checks for programs. >> >+AM_PROG_AR >> >AC_PROG_CC >> >AC_PROG_LIBTOOL >> > >> >-- >> >1.8.3.1 >> > > This solution is not very portable. Automake <= 1.11 does not contain this > macro. > > configure.ac:14: warning: macro `AM_PROG_AR' not found in library > configure.ac:14: error: possibly undefined macro: AM_PROG_AR > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > Better solution will be: > m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > > You can find more information about this in mail thread > http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html Thank you for catching this. Fixed patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0169-2-Add-missing-ar-check-to-configure.ac.patch Type: text/x-patch Size: 658 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 10 11:33:17 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Jul 2013 13:33:17 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51DAD38A.1030209@redhat.com> References: <519357F3.3080408@redhat.com> <51C9B709.9030707@redhat.com> <51DAD38A.1030209@redhat.com> Message-ID: <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> On Monday 08 of July 2013 16:58:18 Ana Krivokapic wrote: > On 06/25/2013 05:28 PM, Ana Krivokapic wrote: > > On 06/24/2013 02:27 PM, Tomas Babej wrote: > >> On 06/11/2013 04:42 PM, Ade Lee wrote: > >> [snip] > >>> Just FYI, we plan to do a new release of pki-core today (pki- core-10.0.3-2) > >>> to address this issue. > >>>> -- > >>>> Regards, > >>>> > >>>> Ana Krivokapic > >>>> Associate Software Engineer > >>>> FreeIPA team > >>>> Red Hat Inc. > >> Ok, so I tested the patch, since pki-core has the PkiExport command fixed now. > >> > >> I'm getting a little bit further now. > >> > >> [tbabej at vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129 > >> vm-129.idm.lab.eng.brq.redhat.com > >> Directory Manager (existing master) password: > >> > >> Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from > >> vm-127.idm.lab.eng.brq.redhat.com > >> Constraint violation: Failed to update password > >> > >> With debug output, I get (snipped out irrelevant parts): > >> > >> Directory Manager (existing master) password: > >> > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > >> context.ldap2_57668944 > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > >> conn= > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection > >> context.ldap2_57668944 > >> ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com > >> ipa: DEBUG: Search failed: [Errno -2] Name or service not known > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > >> conn= > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not logging > >> to a file > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: > >> ipa-replica-prepare was invoked with arguments > >> ['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None, > >> 'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin': None, > >> 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None, 'ca_file': > >> '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12': None, 'password': > >> None, 'ip_address': CheckedIPAddress('10.34.47.129'), 'dirsrv_pin': None, > >> 'pkinit_pin': None} > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO: Preparing > >> replica for vm-129.idm.lab.eng.brq.redhat.com from > >> vm-127.idm.lab.eng.brq.redhat.com > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from SchemaCache > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > >> conn= > >> ipa: DEBUG: Starting external process > >> ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p > >> /tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12 > >> ipa: DEBUG: Process finished, return code=0 > >> ipa: DEBUG: stdout= > >> ipa: DEBUG: stderr= > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > >> context.ldap2_139884970376144 > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute > >> return_value = self.run() > >> File > >> "/usr/lib/python2.7/site- packages/ipaserver/install/ipa_replica_prepare.py", > >> line 245, in run > >> self.copy_ds_certificate() > >> File > >> "/usr/lib/python2.7/site- packages/ipaserver/install/ipa_replica_prepare.py", > >> line 281, in copy_ds_certificate > >> self.update_pki_admin_password() > >> File > >> "/usr/lib/python2.7/site- packages/ipaserver/install/ipa_replica_prepare.py", > >> line 520, in update_pki_admin_password > >> ldap.modify_password(dn, self.dirman_password) > >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line > >> 332, in modify_password > >> self.conn.passwd_s(dn, old_pass, new_pass) > >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > >> self.gen.throw(type, value, traceback) > >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 919, in > >> error_handler > >> raise errors.DatabaseError(desc=desc, info=info) > >> > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The > >> ipa-replica-prepare command failed, exception: DatabaseError: Constraint > >> violation: Failed to update password > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint > >> violation: Failed to update password > >> > >> Tomas > > It seems that this time the culprit is 389-ds-base packages. The password change > > is rejected when using the latest version of 389-ds-base > > (389-ds-base-1.3.1.2-1.fc19.x86_64). I tried testing it with a previous version > > (389-ds-base-1.3.0.5-1.fc19.x86_64) and it works. > > > > I open an upstream ticket for the 389 DS project: > > https://fedorahosted.org/389/ticket/47406. > > > > The password change rejection problem has been fixed in the new version of > 389-ds-base: 389-ds-base-1.3.1.3-1.fc19. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > The patch now fixes the issue. However, we need to bump the dependency in the specfile since now we require version 1.3.1.1. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Jul 10 11:49:41 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Jul 2013 13:49:41 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <20130710095931.GD7205@mail.corp.redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <20130710084827.GU6481@hendrix.brq.redhat.com> <20130710085909.GC7205@mail.corp.redhat.com> <20130710091410.GX6481@hendrix.brq.redhat.com> <20130710095931.GD7205@mail.corp.redhat.com> Message-ID: <20130710114941.GY6481@hendrix.brq.redhat.com> On Wed, Jul 10, 2013 at 11:59:32AM +0200, Lukas Slebodnik wrote: > On (10/07/13 11:14), Jakub Hrozek wrote: > >On Wed, Jul 10, 2013 at 10:59:10AM +0200, Lukas Slebodnik wrote: > >> On (10/07/13 10:48), Jakub Hrozek wrote: > >> >On Wed, Jul 10, 2013 at 10:29:35AM +0200, Lukas Slebodnik wrote: > >> >> On (04/07/13 15:23), Petr Spacek wrote: > >> >> >Hello, > >> >> > > >> >> >several warnings from autotools popped up after upgrade to Fedora 19. > >> >> >Attached patches should make autotools configuration more modern. > >> >> > > >> >> >-- > >> >> >Petr^2 Spacek > >> >> > >> >> >From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 > >> >> >From: Petr Spacek > >> >> >Date: Thu, 4 Jul 2013 14:04:57 +0200 > >> >> >Subject: [PATCH] Add missing ar check to configure.ac. > >> >> > > >> >> >Signed-off-by: Petr Spacek > >> >> >--- > >> >> > configure.ac | 1 + > >> >> > 1 file changed, 1 insertion(+) > >> >> > > >> >> >diff --git a/configure.ac b/configure.ac > >> >> >index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 > >> >> >--- a/configure.ac > >> >> >+++ b/configure.ac > >> >> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) > >> >> > AC_DISABLE_STATIC > >> >> > > >> >> > # Checks for programs. > >> >> >+AM_PROG_AR > >> >> > AC_PROG_CC > >> >> > AC_PROG_LIBTOOL > >> >> > > >> >> >-- > >> >> >1.8.3.1 > >> >> > > >> >> > >> >> This solution is not very portable. Automake <= 1.11 does not contain this > >> >> macro. > >> >> > >> >> configure.ac:14: warning: macro `AM_PROG_AR' not found in library > >> >> configure.ac:14: error: possibly undefined macro: AM_PROG_AR > >> >> If this token and others are legitimate, please use m4_pattern_allow. > >> >> See the Autoconf documentation. > >> >> autoreconf: /usr/bin/autoconf failed with exit status: 1 > >> >> > >> >> Better solution will be: > >> >> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > >> >> > >> >> You can find more information about this in mail thread > >> >> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html > >> You probably did not read this page ^^^^^ > > > >No I didn't :) > > > >But what the guy says there isn't true, m4_pattern_allow works just fine > >even with the old autoconf version in RHEL5. > > > >> > >> >>Even better is: > >> >m4_pattern_allow([AM_PROG_AR]) > >> >AM_PROG_AR > >> > >> m4_pattern_allow should be used for another things. > >> http://www.gnu.org/software/autoconf/manual/autoconf.html#Forbidden-Patterns > > > >Dunno, I think it'quite pretty established pattern. Is there something wrong > >with it? > > Macro "m4_pattern_allow" only suppresses autotool error "possibly undefined macro", > but there still will be a warning "macro `AM_PROG_AR' not found in library" > Autreconf will not fail with older versions of automake (<=1.11), but macro > AM_PROG_AR will not be expanded and you can find this "unexpanded text" in > configure script. It is harmless. > Everything will work well, but we don't like warnings. Sounds like we should patch the same in SSSD then. Thanks for the investigation! From jcholast at redhat.com Wed Jul 10 12:03:57 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Jul 2013 14:03:57 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0240 Integration testing framework In-Reply-To: <51C9883C.8030204@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> <51C9883C.8030204@redhat.com> Message-ID: <51DD4DAD.7050408@redhat.com> On 25.6.2013 14:08, Petr Viktorin wrote: > Adding two additional patches for better Beaker integration: > Patch 0241 allows e.g. adding ticket numbers for automatic test case > management > Patch 0242 should bring the BeakerLib logging closer to what traditional > Beaker tests output > make test seems to run fine with patches 230-242 applied, however ipa-run-tests produces the following output: ====================================================================== ERROR: Test that `ipa help` only writes to stdout ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 63, in test_ipa_help return_value = api.Backend.cli.run(['help']) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1067, in run result = self.execute(name, **kw) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 146, in execute raise error #pylint: disable=E0702 InternalError: an internal error has occurred -------------------- >> begin captured logging << -------------------- IPA: DEBUG: [ipa.ipalib.cli.help] raw: help(None, version=u'2.60') IPA: DEBUG: [ipa.ipalib.cli.help] help(None, version=u'2.60') IPA: ERROR: [ipa.ipalib.cli.cli] non-public: AttributeError: 'API' object has no attribute 'parser' Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 435, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 765, in run self.api.parser.print_help(outfile) AttributeError: 'API' object has no attribute 'parser' IPA: DEBUG: [ipa.ipalib.rpc.xmlclient] Destroyed connection context.xmlclient --------------------- >> end captured logging << --------------------- ====================================================================== ERROR: Failure: IOError ([Errno 2] No such file or directory: 'ipatests/test_xmlrpc/service.crt') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_host_plugin.py", line 59, in fd = open('ipatests/test_xmlrpc/service.crt', 'r') IOError: [Errno 2] No such file or directory: 'ipatests/test_xmlrpc/service.crt' ====================================================================== ERROR: Failure: IOError ([Errno 2] No such file or directory: 'ipatests/test_xmlrpc/service.crt') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 413, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_service_plugin.py", line 42, in fd = open('ipatests/test_xmlrpc/service.crt', 'r') IOError: [Errno 2] No such file or directory: 'ipatests/test_xmlrpc/service.crt' ====================================================================== FAIL: Test that `ipa` errors out, and prints the help to stderr ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 71, in test_ipa_without_arguments api.Backend.cli.run([]) File "/usr/lib/python2.7/site-packages/ipatests/test_cmdline/test_help.py", line 55, in __exit__ assert isinstance(exc_value, self.exception), exc_value AssertionError: 'API' object has no attribute 'parser' -------------------- >> begin captured logging << -------------------- IPA: DEBUG: [ipa.ipalib.cli.help] raw: help(None, outfile=) IPA: DEBUG: [ipa.ipalib.cli.help] help(None, outfile=) --------------------- >> end captured logging << --------------------- I guess the location of the test certificate should be made configurable in order to fix the host and service plugin test failures. Also, there is a lot of debugging messages in ipa-run-tests output which wasn't there before IIRC, is that intentional? ipa-test-config should do more command line options validation: $ ipa-test-config --master Traceback (most recent call last): File "/usr/bin/ipa-test-config", line 104, in print main(sys.argv[1:]), File "/usr/bin/ipa-test-config", line 58, in main return config.env_to_script(get_object(conf, args).to_env(**kwargs)) File "/usr/bin/ipa-test-config", line 84, in get_object domain = conf.domain[0] AttributeError: 'Config' object has no attribute 'domain' If $MASTER (and possible other host names) is not resolvable, ipa-test-config --global crashes: $ ipa-test-config --global Traceback (most recent call last): File "/usr/bin/ipa-test-config", line 104, in print main(sys.argv[1:]), File "/usr/bin/ipa-test-config", line 58, in main return config.env_to_script(get_object(conf, args).to_env(**kwargs)) File "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", line 168, in to_env env['MASTER'] = default_domain.master.hostname File "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", line 282, in master return self.masters[0] IndexError: list index out of range Both the tests in test_simple_replication.py fail for me. I suspect it is because the data isn't replicated fast enough, a little delay between user-show and user-add might fix this. Honza -- Jan Cholasta From akrivoka at redhat.com Wed Jul 10 12:06:59 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 10 Jul 2013 14:06:59 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> References: <519357F3.3080408@redhat.com> <51C9B709.9030707@redhat.com> <51DAD38A.1030209@redhat.com> <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> Message-ID: <51DD4E63.5010800@redhat.com> On 07/10/2013 01:33 PM, Tomas Babej wrote: > > On Monday 08 of July 2013 16:58:18 Ana Krivokapic wrote: > > > On 06/25/2013 05:28 PM, Ana Krivokapic wrote: > > > > On 06/24/2013 02:27 PM, Tomas Babej wrote: > > > >> On 06/11/2013 04:42 PM, Ade Lee wrote: > > > >> [snip] > > > >>> Just FYI, we plan to do a new release of pki-core today (pki-core-10.0.3-2) > > > >>> to address this issue. > > > >>>> -- > > > >>>> Regards, > > > >>>> > > > >>>> Ana Krivokapic > > > >>>> Associate Software Engineer > > > >>>> FreeIPA team > > > >>>> Red Hat Inc. > > > >> Ok, so I tested the patch, since pki-core has the PkiExport command fixed > now. > > > >> > > > >> I'm getting a little bit further now. > > > >> > > > >> [tbabej at vm-127 ~]$ sudo ipa-replica-prepare --ip-address 10.34.47.129 > > > >> vm-129.idm.lab.eng.brq.redhat.com > > > >> Directory Manager (existing master) password: > > > >> > > > >> Preparing replica for vm-129.idm.lab.eng.brq.redhat.com from > > > >> vm-127.idm.lab.eng.brq.redhat.com > > > >> Constraint violation: Failed to update password > > > >> > > > >> With debug output, I get (snipped out irrelevant parts): > > > >> > > > >> Directory Manager (existing master) password: > > > >> > > > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > > > >> context.ldap2_57668944 > > > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > > > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > > > >> conn= > > > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Destroyed connection > > > >> context.ldap2_57668944 > > > >> ipa: DEBUG: Search DNS for vm-129.idm.lab.eng.brq.redhat.com > > > >> ipa: DEBUG: Search failed: [Errno -2] Name or service not known > > > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > > > >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from > SchemaCache > > > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > > > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > > > >> conn= > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: Not logging > > > >> to a file > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: > > > >> ipa-replica-prepare was invoked with arguments > > > >> ['vm-129.idm.lab.eng.brq.redhat.com'] and options: {'log_file': None, > > > >> 'verbose': True, 'reverse_zone': None, 'setup_pkinit': True, 'http_pin': > None, > > > >> 'quiet': False, 'http_pkcs12': None, 'pkinit_pkcs12': None, 'ca_file': > > > >> '/root/cacert.p12', 'no_reverse': False, 'dirsrv_pkcs12': None, 'password': > > > >> None, 'ip_address': CheckedIPAddress('10.34.47.129'), 'dirsrv_pin': None, > > > >> 'pkinit_pin': None} > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: INFO: Preparing > > > >> replica for vm-129.idm.lab.eng.brq.redhat.com from > > > >> vm-127.idm.lab.eng.brq.redhat.com > > > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > > > >> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket from > SchemaCache > > > >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for SchemaCache > > > >> url=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-ENG-BRQ-REDHAT-COM.socket > > > >> conn= > > > >> ipa: DEBUG: Starting external process > > > >> ipa: DEBUG: args=/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p > > > >> /tmp/tmprgUrso -w /tmp/tmp6SBBXF -o /root/cacert.p12 > > > >> ipa: DEBUG: Process finished, return code=0 > > > >> ipa: DEBUG: stdout= > > > >> ipa: DEBUG: stderr= > > > >> ipa.ipaserver.plugins.ldap2.ldap2: DEBUG: Created connection > > > >> context.ldap2_139884970376144 > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > > > >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > > > >> return_value = self.run() > > > >> File > > > >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > > > >> line 245, in run > > > >> self.copy_ds_certificate() > > > >> File > > > >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > > > >> line 281, in copy_ds_certificate > > > >> self.update_pki_admin_password() > > > >> File > > > >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > > > >> line 520, in update_pki_admin_password > > > >> ldap.modify_password(dn, self.dirman_password) > > > >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line > > > >> 332, in modify_password > > > >> self.conn.passwd_s(dn, old_pass, new_pass) > > > >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > > > >> self.gen.throw(type, value, traceback) > > > >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 919, in > > > >> error_handler > > > >> raise errors.DatabaseError(desc=desc, info=info) > > > >> > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The > > > >> ipa-replica-prepare command failed, exception: DatabaseError: Constraint > > > >> violation: Failed to update password > > > >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: Constraint > > > >> violation: Failed to update password > > > >> > > > >> Tomas > > > > It seems that this time the culprit is 389-ds-base packages. The password > change > > > > is rejected when using the latest version of 389-ds-base > > > > (389-ds-base-1.3.1.2-1.fc19.x86_64). I tried testing it with a previous > version > > > > (389-ds-base-1.3.0.5-1.fc19.x86_64) and it works. > > > > > > > > I open an upstream ticket for the 389 DS project: > > > > https://fedorahosted.org/389/ticket/47406. > > > > > > > > > > The password change rejection problem has been fixed in the new version of > > > 389-ds-base: 389-ds-base-1.3.1.3-1.fc19. > > > > > > -- > > > Regards, > > > > > > Ana Krivokapic > > > Associate Software Engineer > > > FreeIPA team > > > Red Hat Inc. > > > > > > > The patch now fixes the issue. > > > > However, we need to bump the dependency in the specfile since now we require > > version 1.3.1.1. > > > > Tomas > Thanks, updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0029-03-Make-sure-replication-works-after-DM-password-is-cha.patch Type: text/x-patch Size: 4855 bytes Desc: not available URL: From lslebodn at redhat.com Wed Jul 10 12:07:39 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 10 Jul 2013 14:07:39 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <51DD36FC.3070201@redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <51DD36FC.3070201@redhat.com> Message-ID: <20130710120739.GE7205@mail.corp.redhat.com> On (10/07/13 12:27), Petr Spacek wrote: >On 10.7.2013 10:29, Lukas Slebodnik wrote: >>On (04/07/13 15:23), Petr Spacek wrote: >>>>Hello, >>>> >>>>several warnings from autotools popped up after upgrade to Fedora 19. >>>>Attached patches should make autotools configuration more modern. >>>> >>>>-- >>>>Petr^2 Spacek >>>From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >>>>From: Petr Spacek >>>>Date: Thu, 4 Jul 2013 14:04:57 +0200 >>>>Subject: [PATCH] Add missing ar check to configure.ac. >>>> >>>>Signed-off-by: Petr Spacek >>>>--- >>>>configure.ac | 1 + >>>>1 file changed, 1 insertion(+) >>>> >>>>diff --git a/configure.ac b/configure.ac >>>>index 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 100644 >>>>--- a/configure.ac >>>>+++ b/configure.ac >>>>@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >>>>AC_DISABLE_STATIC >>>> >>>># Checks for programs. >>>>+AM_PROG_AR >>>>AC_PROG_CC >>>>AC_PROG_LIBTOOL >>>> >>>>-- >>>>1.8.3.1 >>>> >>This solution is not very portable. Automake <= 1.11 does not contain this >>macro. >> >>configure.ac:14: warning: macro `AM_PROG_AR' not found in library >>configure.ac:14: error: possibly undefined macro: AM_PROG_AR >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >>autoreconf: /usr/bin/autoconf failed with exit status: 1 >> >>Better solution will be: >>m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> >>You can find more information about this in mail thread >>http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html > >Thank you for catching this. Fixed patch is attached. > >-- >Petr^2 Spacek ACK LS From simo at redhat.com Wed Jul 10 13:17:26 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Jul 2013 09:17:26 -0400 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130709203923.GP6481@hendrix.brq.redhat.com> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> <20130709203923.GP6481@hendrix.brq.redhat.com> Message-ID: <1373462246.30537.231.camel@willson.li.ssimo.org> On Tue, 2013-07-09 at 22:39 +0200, Jakub Hrozek wrote: > On Tue, Jul 09, 2013 at 02:12:33PM +0300, Alexander Bokovoy wrote: > > On Tue, 09 Jul 2013, Jakub Hrozek wrote: > > >On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: > > >>On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: > > >>> On Mon, 01 Jul 2013, Sumit Bose wrote: > > >>> >Hi, > > >>> > > > >>> >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only > > >>> >to allow SSSD running on a FreeIPA server to access the AD LDAP server. > > >>> >In the ticket a more generic solution is described but since there is no > > >>> >other use case so far I think this patch is sufficient for the time > > >>> >being. > > >>> > > > >>> >bye, > > >>> >Sumit > > >>> > > >>> >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 > > >>> >From: Sumit Bose > > >>> >Date: Mon, 1 Jul 2013 13:47:22 +0200 > > >>> >Subject: [PATCH] Add PAC to master host TGTs > > >>> > > > >>> >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is > > >>> >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server > > >>> >of a trusted domain with the credentials of a FreeIPA server host a > > >>> >PAC must be added to the TGT for the host. > > >>> s/SALS/SASL/ > > >> > > >>Thank you for the review, I've fixed the typo and added the numerical > > >>values for the well-known RIDs to the commit message. > > >> > > >>> > > >>> > > >>> >To determine if a host is a FreeIPA server or not it is checked if there > > >>> >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately > > >>> >this requires an additional LDAP lookup. But since TGS-REQs for hosts > > >>> >should be rare I think it is acceptable for the time being. > > >>> I think it is better to change this lookup to > > >>> "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would > > >>> explicitly limit us to the IPA masters running AD trusts. > > >> > > >>I'm not sure if this restriction is needed. With SSSD's ipa_server_mode > > >>any IPA master (which networkwise can access an AD server of the trusted > > >>domain) can read AD user and group data, no running smbd or winbind is > > >>required. So it would be possible to run the extdom plugin or the compat > > >>plugin for the legacy clients on any IPA server which would allow a much > > >>better load balancing. > > >> > > >>If there are other concerns I'm happy to add the restriction. > > >> > > >>bye, > > >>Sumit > > > > > >I don't think I know the code good enough to provide a full review, but > > >the patch enables the lookups from an IPA master without any additional > > >hacks. So ack on functionality at least. > > Ok. > > > > I've extended this functionality to generate MS-PAC also for services > > running on IPA masters. Patch attached. > > > > This is needed to finally get rid of access to trust auth material for > > IPA python code. HTTP/fqdn at REALM will now be able to authenticate > > against AD LDAP server and look up needed information directly, without > > elevating privileges to trust admins. > > > > This should also help for AD range discovery Tomas is working on. > > > > Hi, > > The patch looks good to me so I'm giving my +1. I would appreciate other > review too before a full ack, though. I've nacked the approach, although the results are as expected. Alexander will send a simplified patch that avoids the extra search and use of managedby which is not ok. Simo. -- Simo Sorce * Red Hat, Inc * New York From thozza at redhat.com Wed Jul 10 13:33:08 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 10 Jul 2013 15:33:08 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <51DD36FC.3070201@redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <51DD36FC.3070201@redhat.com> Message-ID: <51DD6294.9050000@redhat.com> On 07/10/2013 12:27 PM, Petr Spacek wrote: > On 10.7.2013 10:29, Lukas Slebodnik wrote: >> On (04/07/13 15:23), Petr Spacek wrote: >>> >Hello, >>> > >>> >several warnings from autotools popped up after upgrade to Fedora 19. >>> >Attached patches should make autotools configuration more modern. >>> > >>> >-- >>> >Petr^2 Spacek >>> From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >>> >From: Petr Spacek >>> >Date: Thu, 4 Jul 2013 14:04:57 +0200 >>> >Subject: [PATCH] Add missing ar check to configure.ac. >>> > >>> >Signed-off-by: Petr Spacek >>> >--- >>> >configure.ac | 1 + >>> >1 file changed, 1 insertion(+) >>> > >>> >diff --git a/configure.ac b/configure.ac >>> >index >>> 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 >>> 100644 >>> >--- a/configure.ac >>> >+++ b/configure.ac >>> >@@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >>> >AC_DISABLE_STATIC >>> > >>> ># Checks for programs. >>> >+AM_PROG_AR >>> >AC_PROG_CC >>> >AC_PROG_LIBTOOL >>> > >>> >-- >>> >1.8.3.1 >>> > >> This solution is not very portable. Automake <= 1.11 does not contain >> this >> macro. >> >> configure.ac:14: warning: macro `AM_PROG_AR' not found in library >> configure.ac:14: error: possibly undefined macro: AM_PROG_AR >> If this token and others are legitimate, please use >> m4_pattern_allow. >> See the Autoconf documentation. >> autoreconf: /usr/bin/autoconf failed with exit status: 1 >> >> Better solution will be: >> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> >> You can find more information about this in mail thread >> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html > > Thank you for catching this. Fixed patch is attached. > ACK Regards, Tomas Hozza From thozza at redhat.com Wed Jul 10 14:45:44 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 10 Jul 2013 16:45:44 +0200 Subject: [Freeipa-devel] [PATCH 0171-0172] Fix potential problems found by Clang static analyzer In-Reply-To: <51DA7D9D.3060201@redhat.com> References: <51DA7D9D.3060201@redhat.com> Message-ID: <51DD7398.9090807@redhat.com> On 07/08/2013 10:51 AM, Petr Spacek wrote: > Hello, > > several warnings from Clang static analyzer popped up after upgrade to > Fedora 19. Attached patches should fix all problems found by > clang-analyzer-3.3-0.6.rc3.fc19.x86_64. > ACK Regards, Tomas Hozza From tbabej at redhat.com Wed Jul 10 15:24:53 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Jul 2013 17:24:53 +0200 Subject: [Freeipa-devel] [PATCH 0067] Add --use-posix option that forces trusted range type In-Reply-To: <51C85609.3000103@redhat.com> References: <51B05207.4010100@redhat.com> <51C2DFF5.8040608@redhat.com> <51C85609.3000103@redhat.com> Message-ID: <1421463.VoxyeaR2vY@thinkpad7.brq.redhat.com> On Monday 24 of June 2013 16:22:01 Petr Viktorin wrote: > On 06/20/2013 12:56 PM, Tomas Babej wrote: > > On 06/17/2013 02:34 PM, Ana Krivokapic wrote: > >> On 06/06/2013 11:10 AM, Tomas Babej wrote: > >>> Hi, > >>> > >>> Adds --use-posix option to ipa trust-add command. It takes two > >>> allowed values: > >>> 'yes' : the 'ipa-ad-trust-posix' range type is enforced > >>> 'no' : the 'ipa-ad-trust' range type is enforced > >>> > >>> When --use-posix option is not specified, the range type should be > >>> determined by ID range discovery. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3650 > >>> > >>> Tomas > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > >> The patch works nicely, but I have a few comments: > >> > >> 1) You added a new option to the API, but you forgot to bump the > >> IPA_API_VERSION_MINOR in the VERSION file. > >> > >> 2) Typo in commit message: "shold" instead of "should". > >> > >> 3) This construct: > >> > >> + if range_type is not None: > >> + if range_type != old_range_type: > >> > >> can be replaced with a more readable variant which also avoids nested ifs: > >> > >> + if range_type and range_type != old_range_type: > >> > > > > All fixed. > > > >> 4) Some unit tests to cover the behavior of the newly added option > >> would be nice. > > > > This is not doable at the moment, we have no unit test framework to test > > the trust-add command. > > > >> -- > >> Regards, > >> > >> Ana Krivokapic > >> Associate Software Engineer > >> FreeIPA team > >> Red Hat Inc. > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Tomas > > I don't know much about AD trusts, but a command-line/API option that > takes a 'yes' or 'no' string raised a tiny warning flag for me. > > It looks like it's possible that there can be other range types in the > future than posix and algorithmic? If that's the case, there should be a > --range-type option instead. (If not, I'd still go for --range-type but > that would just be bikeshedding.) > > In any case I think an explicit 'auto' option would be nice. > > But that's just an outsider's view, maybe --use-posix makes more sense. I replaced --use-posix with more versatile --range-type. It supports only trust-related values for now, and can be extended. Rebased patch attached. > > > AFAIK, for CLI changes there should be a a design page; is this covered > anywhere? > Design page for the umbrella ticket is here: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD > > -- > Petr? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0067-3-Add-range-type-option-that-forces-range-type-of-the-.patch Type: text/x-patch Size: 7023 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jul 10 15:29:25 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Jul 2013 18:29:25 +0300 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <1373462246.30537.231.camel@willson.li.ssimo.org> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> <20130709203923.GP6481@hendrix.brq.redhat.com> <1373462246.30537.231.camel@willson.li.ssimo.org> Message-ID: <20130710152925.GB18587@redhat.com> On Wed, 10 Jul 2013, Simo Sorce wrote: >On Tue, 2013-07-09 at 22:39 +0200, Jakub Hrozek wrote: >> On Tue, Jul 09, 2013 at 02:12:33PM +0300, Alexander Bokovoy wrote: >> > On Tue, 09 Jul 2013, Jakub Hrozek wrote: >> > >On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: >> > >>On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: >> > >>> On Mon, 01 Jul 2013, Sumit Bose wrote: >> > >>> >Hi, >> > >>> > >> > >>> >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only >> > >>> >to allow SSSD running on a FreeIPA server to access the AD LDAP server. >> > >>> >In the ticket a more generic solution is described but since there is no >> > >>> >other use case so far I think this patch is sufficient for the time >> > >>> >being. >> > >>> > >> > >>> >bye, >> > >>> >Sumit >> > >>> >> > >>> >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 >> > >>> >From: Sumit Bose >> > >>> >Date: Mon, 1 Jul 2013 13:47:22 +0200 >> > >>> >Subject: [PATCH] Add PAC to master host TGTs >> > >>> > >> > >>> >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is >> > >>> >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server >> > >>> >of a trusted domain with the credentials of a FreeIPA server host a >> > >>> >PAC must be added to the TGT for the host. >> > >>> s/SALS/SASL/ >> > >> >> > >>Thank you for the review, I've fixed the typo and added the numerical >> > >>values for the well-known RIDs to the commit message. >> > >> >> > >>> >> > >>> >> > >>> >To determine if a host is a FreeIPA server or not it is checked if there >> > >>> >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately >> > >>> >this requires an additional LDAP lookup. But since TGS-REQs for hosts >> > >>> >should be rare I think it is acceptable for the time being. >> > >>> I think it is better to change this lookup to >> > >>> "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would >> > >>> explicitly limit us to the IPA masters running AD trusts. >> > >> >> > >>I'm not sure if this restriction is needed. With SSSD's ipa_server_mode >> > >>any IPA master (which networkwise can access an AD server of the trusted >> > >>domain) can read AD user and group data, no running smbd or winbind is >> > >>required. So it would be possible to run the extdom plugin or the compat >> > >>plugin for the legacy clients on any IPA server which would allow a much >> > >>better load balancing. >> > >> >> > >>If there are other concerns I'm happy to add the restriction. >> > >> >> > >>bye, >> > >>Sumit >> > > >> > >I don't think I know the code good enough to provide a full review, but >> > >the patch enables the lookups from an IPA master without any additional >> > >hacks. So ack on functionality at least. >> > Ok. >> > >> > I've extended this functionality to generate MS-PAC also for services >> > running on IPA masters. Patch attached. >> > >> > This is needed to finally get rid of access to trust auth material for >> > IPA python code. HTTP/fqdn at REALM will now be able to authenticate >> > against AD LDAP server and look up needed information directly, without >> > elevating privileges to trust admins. >> > >> > This should also help for AD range discovery Tomas is working on. >> > >> >> Hi, >> >> The patch looks good to me so I'm giving my +1. I would appreciate other >> review too before a full ack, though. > >I've nacked the approach, although the results are as expected. >Alexander will send a simplified patch that avoids the extra search and >use of managedby which is not ok. New patch attached. -- / Alexander Bokovoy -------------- next part -------------- >From e150e2abd67538db1b53d5b5dd096bd15e2ffe58 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 14:05:02 +0300 Subject: [PATCH 15/15] Generate syntethic MS-PAC for all services running on IPA master MS-PAC is required to be present in TGT if one wants to connect to AD services using this TGT. Users get MS-PAC by default, SSSD in ipa_server_mode uses host/fqdn at REALM principal to talk to AD LDAP. This patch enables other services running on IPA master to connect to AD services. This is required for IPA python code doing discovery of remote AD domain settings shortly after IPA-AD trust has been established. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 56 +++++++++++++++++++++++++++++++++++------ 1 file changed, 49 insertions(+), 7 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 92dc8dd..4944bb8 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -392,13 +392,14 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, struct dom_sid sid; gid_t prigid = -1; time_t timeres; - char *strres; + char *strres, *strhost, *strat; int intres; int ret; char **objectclasses = NULL; size_t c; bool is_host = false; bool is_user = false; + bool is_service = false; ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "objectClass", &objectclasses); @@ -407,6 +408,9 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, if (strcasecmp(objectclasses[c], "ipaHost") == 0) { is_host = true; } + if (strcasecmp(objectclasses[c], "ipaService") == 0) { + is_service = true; + } if (strcasecmp(objectclasses[c], "ipaNTUserAttrs") == 0) { is_user = true; } @@ -415,8 +419,8 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } free(objectclasses); - if (!is_host && !is_user) { - /* We only handle users and hosts */ + if (!is_host && !is_user && !is_service) { + /* We only handle users and hosts, and services */ return ENOENT; } @@ -433,6 +437,44 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, free(strres); return ENOENT; } + } else if (is_service) { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "krbPrincipalName", &strres); + if (ret) { + /* krbPrincipalName is mandatory for services */ + return ret; + } + + /* krbPrincipalName is foo/fqdn at REALM, we need fqdn only */ + strhost = strchr(strres, '/'); + if (strhost == NULL) { + free(strres); + return ENOENT; + } + + strhost++; + strat = strchr(strhost, '@'); + if (strat != NULL) { + strat[0] = '\0'; + } + + /* Only add PAC to TGT to services on IPA masters to allow querying + * AD LDAP server */ + if (!is_master_host(ipactx, strhost)) { + free(strres); + return ENOENT; + } + + if (strat != NULL) { + strat[0] = '@'; + } + + strhost = strdup(strhost); + free(strres); + + if (strhost == NULL) { + return ENOENT; + } + strres = strhost; } else { ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); if (ret) { @@ -444,7 +486,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.account_name.string = talloc_strdup(memctx, strres); free(strres); - if (is_host) { + if (is_host || is_service) { prigid = 515; /* Well known RID for domain computers group */ } else { ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); @@ -567,7 +609,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.logon_count = 0; /* we do not have this info yet */ info3->base.bad_password_count = 0; /* we do not have this info yet */ - if (is_host) { + if (is_host || is_service) { /* Well know RID of domain controllers group */ info3->base.rid = 516; } else { @@ -658,7 +700,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } if (info3->base.primary_gid == 0) { - if (is_host) { + if (is_host || is_service) { info3->base.primary_gid = 515; /* Well known RID for domain computers group */ } else { if (ipactx->mspac->fallback_rid) { @@ -698,7 +740,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, return ENOENT; } - if (is_host) { + if (is_host || is_service) { info3->base.domain_sid = talloc_memdup(memctx, &ipactx->mspac->domsid, sizeof(ipactx->mspac->domsid)); } else { -- 1.8.3.1 From rcritten at redhat.com Wed Jul 10 15:46:23 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Jul 2013 11:46:23 -0400 Subject: [Freeipa-devel] [PATCH] 140 Check trust chain length in CA-less install In-Reply-To: <51C04E37.7060206@redhat.com> References: <51C04E37.7060206@redhat.com> Message-ID: <51DD81CF.1020004@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza This patch seems to work ok but I've been unable to test it with an external CA installation because that seems to be broken (unrelated to this patch). I filed https://fedorahosted.org/freeipa/ticket/3773 rob From pviktori at redhat.com Wed Jul 10 15:50:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Jul 2013 17:50:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0244 Integration testing framework In-Reply-To: <51DD4DAD.7050408@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> <51C9883C.8030204@redhat.com> <51DD4DAD.7050408@redhat.com> Message-ID: <51DD82CE.3080001@redhat.com> On 07/10/2013 02:03 PM, Jan Cholasta wrote: > On 25.6.2013 14:08, Petr Viktorin wrote: >> Adding two additional patches for better Beaker integration: >> Patch 0241 allows e.g. adding ticket numbers for automatic test case >> management >> Patch 0242 should bring the BeakerLib logging closer to what traditional >> Beaker tests output >> > > make test seems to run fine with patches 230-242 applied, however > ipa-run-tests produces the following output: > [...Skipping nose output...] > > > I guess the location of the test certificate should be made configurable > in order to fix the host and service plugin test failures. Making the existing test suite pass out of tree it's not a goal for this patchset. There is a pending patch for the service cert. > Also, there is a lot of debugging messages in ipa-run-tests output which > wasn't there before IIRC, is that intentional? Yes, I believe that for the integration tests it's better to see what is going on. Both for manual runs, and also this way the information is more easily picked up by CI tools. > ipa-test-config should do more command line options validation: > > $ ipa-test-config --master > Traceback (most recent call last): > File "/usr/bin/ipa-test-config", line 104, in > print main(sys.argv[1:]), > File "/usr/bin/ipa-test-config", line 58, in main > return config.env_to_script(get_object(conf, args).to_env(**kwargs)) > File "/usr/bin/ipa-test-config", line 84, in get_object > domain = conf.domain[0] > AttributeError: 'Config' object has no attribute 'domain' Fixed, thanks > If $MASTER (and possible other host names) is not resolvable, > ipa-test-config --global crashes: > > $ ipa-test-config --global > Traceback (most recent call last): > File "/usr/bin/ipa-test-config", line 104, in > print main(sys.argv[1:]), > File "/usr/bin/ipa-test-config", line 58, in main > return config.env_to_script(get_object(conf, args).to_env(**kwargs)) > File > "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", > line 168, in to_env > env['MASTER'] = default_domain.master.hostname > File > "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", > line 282, in master > return self.masters[0] > IndexError: list index out of range Fixed. Now, if the name is not resolvable, reading the config will fail. Alternatively, the IP address can be given in variables such as $BEAKERREPLICA1_IP_env1 (no, I didn't invent the name). > Both the tests in test_simple_replication.py fail for me. I suspect it > is because the data isn't replicated fast enough, a little delay between > user-show and user-add might fix this. Hm, they worked for me. I've added a delay. It seems fragile, I wonder what the proper way to do this would be. I've made some other changes, mainly BeakerLib plugin output. Patch 240: Avoid infinite recursion that happened with some cases of bad SSH credentials Patch 241-243: Rework the BeakerLib plugin output to better match traditional Beaker tests Patch 244: Make it possible to explicitly specify IP addresses of hosts > > Honza > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0230.4-Add-a-plugin-for-test-ordering.patch Type: text/x-patch Size: 4190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0231.4-Add-a-framework-for-integration-test-configuration.patch Type: text/x-patch Size: 21372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0232.4-Add-a-framework-for-integration-testing.patch Type: text/x-patch Size: 22930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0233.4-Introduce-a-class-for-remote-commands.patch Type: text/x-patch Size: 10632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0234.4-Collect-logs-from-tests.patch Type: text/x-patch Size: 7021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0237.4-Show-logs-in-failed-tests.patch Type: text/x-patch Size: 3124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0238.4-tests-Allow-public-keys-for-authentication-to-the-re.patch Type: text/x-patch Size: 4538 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0239.4-tests-Configure-unconfigure-remote-hosts.patch Type: text/x-patch Size: 9826 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0240.4-Host-class-improvements.patch Type: text/x-patch Size: 6803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0241.4-Use-dosctrings-in-BeakerLib-phase-descriptions.patch Type: text/x-patch Size: 3463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0242.4-Make-BeakerLib-logging-less-verbose.patch Type: text/x-patch Size: 7793 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0243.4-BeakerLib-plugin-Log-http-links-in-test-docstrings.patch Type: text/x-patch Size: 2244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0244.4-Integration-test-config-Make-it-possible-to-specify-.patch Type: text/x-patch Size: 5238 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jul 10 16:15:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Jul 2013 19:15:44 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130709100133.GJ6481@hendrix.brq.redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> <20130709094200.GH6481@hendrix.brq.redhat.com> <20130709100133.GJ6481@hendrix.brq.redhat.com> Message-ID: <20130710161544.GC18587@redhat.com> On Tue, 09 Jul 2013, Jakub Hrozek wrote: >On Tue, Jul 09, 2013 at 11:42:00AM +0200, Jakub Hrozek wrote: >> On Tue, Jul 09, 2013 at 10:33:19AM +0300, Alexander Bokovoy wrote: >> > On Mon, 08 Jul 2013, Jakub Hrozek wrote: >> > >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: >> > >>On Mon, 08 Jul 2013, Jakub Hrozek wrote: >> > >>>On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: >> > >>>>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >> > >>>>>On Wed, 03 Jul 2013, Sumit Bose wrote: >> > >>>>>>Hi, >> > >>>>>> >> > >>>>>>with this patch the extdom plugin, the LDAP extended operation that >> > >>>>>>allows IPA clients with recent SSSD to lookup AD users and groups, will >> > >>>>>>not use winbind for the lookup anymore but will use SSSD running in >> > >>>>>>ipa_server_mode. >> > >>>>>> >> > >>>>>>Since now no plugin uses the winbind client libraries anymore, the >> > >>>>>>second patch removes the related configures checks. >> > >>>>>> >> > >>>>>>I think for the time being we cannot remove winbind completely because >> > >>>>>>it might be needed for msbd to work properly in a trusted environment. >> > >>>>>s/msbd/smbd/ >> > >>>>> >> > >>>>>ACK. I need to add 'ipa_server_mode = True' support to >> > >>>>>the installer code and then these patches can go in. >> > >>>>Actually, the code still doesn't work due to some bug in sssd which >> > >>>>fails to respond properly to getsidbyname() request in libsss_nss_idmap. >> > >>>> >> > >>>>Additionally I've found one missing treatment of domain_name for >> > >>>>INP_NAME requests. >> > >>>> >> > >>>>We are working with Jakub on tracking down what's wrong on SSSD side. >> > >>> >> > >>>Indeed, there was a casing issue in sysdb. You can continue testing with >> > >>>lowercase user names in the meantime. A patch is already on the SSSD >> > >>>list. >> > >>In addition, we need to disqualify user name when returning back a >> > >>packet from extdom operation as this is what SSSD expects. >> > >> >> > >>Attached patch does it for all types of requests. >> > >> >> > >>-- >> > >>/ Alexander Bokovoy >> > > >> > >>>From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 >> > >>From: Alexander Bokovoy >> > >>Date: Mon, 8 Jul 2013 19:19:56 +0300 >> > >>Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as >> > >> sssd expects >> > >> >> > >>extdom plugin handles external operation over which SSSD asks IPA server about >> > >>trusted domain users not found through normal paths but detected to belong >> > >>to the trusted domains associated with IPA realm. >> > >> >> > >>SSSD expects that user or group name in the response will be unqualified >> > >>because domain name for the user or group is also included in the response. >> > >>Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully >> > >>qualified name which includes the domain name we are asked to handle. >> > >> >> > >>The code already expects that fully-qualified names are following user at domain >> > >>convention so we are simply tracking whether '@' symbol is present and is followed >> > >>by the domain name. >> > >>--- >> > >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ >> > >> 1 file changed, 26 insertions(+) >> > >> >> > >>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 8aa22e1..290da4e 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 >> > >>@@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, >> > >> &grp_result); >> > >> } >> > >> } >> > >>+ domain_name = strdup(req->data.name.domain_name); >> > > >> > >I would prefer if this was a separate patch. But this is a correct >> > >change. >> > Separated. >> > >> >> Ack to this patch. >> >> > > >> > >> break; >> > >> default: >> > >> ret = LDAP_PROTOCOL_ERROR; >> > >>@@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> > >> const char *domain_name, struct extdom_res **_res) >> > >> { >> > >> int ret = EFAULT; >> > >>+ char *locat = NULL; >> > >> struct extdom_res *res; >> > >> >> > >> res = calloc(1, sizeof(struct extdom_res)); >> > >>@@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> > >> switch(id_type) { >> > >> case SSS_ID_TYPE_UID: >> > >> case SSS_ID_TYPE_BOTH: >> > >>+ if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >> > >>+ if (strstr(locat, domain_name) != NULL ) { >> > > >> > >strstr doesn't work correctly in my case. In SSSD, the domain names are >> > >case-insensitive, so you can use strcasestr here. In my case, the >> > >condition is never hit as the domain case differs: >> > > >> > >407 res->data.user.domain_name = strdup(domain_name); >> > >(gdb) >> > >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >> > >(gdb) n >> > >409 if (strstr(locat, domain_name) != NULL) { >> > >(gdb) >> > >414 strdup(pg_data->data.pwd.pw_name); >> > >(gdb) p domain_name >> > >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" >> > >(gdb) p locat >> > >$2 = 0x7f2e8006500d "@ad.example.com" >> > Replaced by strcasestr. >> > >> > >> > > >> > >Also, this is good enough for the beta or when the default values are used, but >> > >in theory, the admin could configure the fully qualified name format to not >> > >include the @-sign (see full_name_format in sssd.conf) at all. >> > > >> > >It's not very likely, but I think we should account for that case >> > >eventually. I'm not exactly sure how yet as the full_name_format is pretty >> > >free-form, maybe we could simply disallow setting it if server_mode was >> > >set to True. >> > I'd prefer the latter indeed. Given that you can have full_name_format >> > varying between servers and clients, this is simply asking for disaster. >> > >> > I'd preper concentrating our effort on making default configuration >> > working so well that you never need to modify these parameters. After >> > all, we are talking about SSSD use as FreeIPA client with trusts >> > enabled. SSSD configuration is dictated by ipa-client-install in this >> > case for all clients. >> >> And Ack to the second patch as well. >> >> I opened https://fedorahosted.org/sssd/ticket/2009 on the SSSD side to >> make the behaviour more predictable and robust. > >btw of course I tested with Sumit's patches applied before these two. >They are quite large and I don't think I can review them, but from >purely functional point of view, ack. Simo asked to replace strcasestr() with strcasecmp() and I also replaced '@' with SSSD_DOMAIN_SEPARATOR to make it clear what we are dealing with. We'll need to be able to read separator value out of /etc/sssd.conf. I wonder if this could actually be done by libsss_nss_idmap so that we don't need to reimplement the code to read config and link directly with libini_config. -- / Alexander Bokovoy -------------- next part -------------- >From 10eef7991c879fc0f7860d8b6ef6abc45f0465dd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 10:26:22 +0300 Subject: [PATCH 14/15] Fix extdom plugin to provide unqualified name in response as sssd expects extdom plugin handles external operation over which SSSD asks IPA server about trusted domain users not found through normal paths but detected to belong to the trusted domains associated with IPA realm. SSSD expects that user or group name in the response will be unqualified because domain name for the user or group is also included in the response. Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully qualified name which includes the domain name we are asked to handle. The code already expects that fully-qualified names are following user at domain convention so we are simply tracking whether '@' symbol is present and is followed by the domain name. --- .../ipa-extdom-extop/ipa_extdom_common.c | 33 ++++++++++++++++++++-- 1 file changed, 30 insertions(+), 3 deletions(-) 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 823745e..26262e4 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 @@ -48,6 +48,7 @@ #include "util.h" #define MAX(a,b) (((a)>(b))?(a):(b)) +#define SSSD_DOMAIN_SEPARATOR '@' int parse_request_data(struct berval *req_val, struct extdom_req **_req) { @@ -242,7 +243,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, goto done; } - sep = strrchr(fq_name, '@'); + sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); if (sep == NULL) { ret = LDAP_OPERATIONS_ERROR; goto done; @@ -274,8 +275,9 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, domain_name = strdup(req->data.name.domain_name); break; case INP_NAME: - ret = asprintf(&fq_name, "%s@%s", req->data.name.object_name, - req->data.name.domain_name); + ret = asprintf(&fq_name, "%s%c%s", req->data.name.object_name, + SSSD_DOMAIN_SEPARATOR, + req->data.name.domain_name); if (ret == -1) { ret = LDAP_OPERATIONS_ERROR; fq_name = NULL; /* content is undefined according to @@ -339,6 +341,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, const char *domain_name, struct extdom_res **_res) { int ret = EFAULT; + char *locat = NULL; struct extdom_res *res; res = calloc(1, sizeof(struct extdom_res)); @@ -355,10 +358,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, switch(id_type) { case SSS_ID_TYPE_UID: case SSS_ID_TYPE_BOTH: + if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0 ) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.pwd.pw_name); break; case SSS_ID_TYPE_GID: + if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0) { + locat[0] = 0; + } + } res->data.name.object_name = strdup(pg_data->data.grp.gr_name); break; @@ -394,6 +407,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_BOTH: res->response_type = RESP_USER; res->data.user.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0) { + locat[0] = 0; + } + } res->data.user.user_name = strdup(pg_data->data.pwd.pw_name); @@ -409,6 +427,11 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, case SSS_ID_TYPE_GID: res->response_type = RESP_GROUP; res->data.group.domain_name = strdup(domain_name); + if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if (strcasecmp(locat+1, domain_name) == 0) { + locat[0] = 0; + } + } res->data.group.group_name = strdup(pg_data->data.grp.gr_name); @@ -439,6 +462,10 @@ done: free_resp_data(res); } + if (locat != NULL) { + locat[0] = SSSD_DOMAIN_SEPARATOR; + } + return ret; } -- 1.8.3.1 From jhrozek at redhat.com Wed Jul 10 16:24:12 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Jul 2013 18:24:12 +0200 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130710161544.GC18587@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> <20130709094200.GH6481@hendrix.brq.redhat.com> <20130709100133.GJ6481@hendrix.brq.redhat.com> <20130710161544.GC18587@redhat.com> Message-ID: <20130710162412.GK6481@hendrix.brq.redhat.com> On Wed, Jul 10, 2013 at 07:15:44PM +0300, Alexander Bokovoy wrote: > We'll need to be able to read separator value out of /etc/sssd.conf. I > wonder if this could actually be done by libsss_nss_idmap so that we > don't need to reimplement the code to read config and link directly with > libini_config. Unfortunately it's even more complex, because not only you can set the separator, but the FQDN format can be specified with a printf(3)-like expression, the default is: full_name_format = %1$s@%2$s (user at domain) But nothing prevents the admin from setting i.e. NetBIOS-styled FQDNs: full_name_format = %3$s\\%1$s (netbios\user) I think we should just warn if the full_name_format directive is specified to anything else than the default. From akrivoka at redhat.com Wed Jul 10 16:36:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 10 Jul 2013 18:36:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130708063256.GE3956@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> Message-ID: <51DD8D93.2040100@redhat.com> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: > On Thu, 20 Jun 2013, Ana Krivokapic wrote: >> Hello, >> >> Attached patches fix systemd and ipactl related bugs: >> >> https://fedorahosted.org/freeipa/ticket/3730 >> https://fedorahosted.org/freeipa/ticket/3729 > NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on > upgrade properly and everything else has failed afterwards. > This was caused due to 'systemctl is-active' returning exit status 3 ('activating'), and our code treating the non-zero exit status as a failure. I handled this case in the updated patch. As for the ipa.service and dependency ordering, I have done some further testing and found out the adding the '--ignore-dependencies' switch alone solves the shutdown issue. So I think that no modification of ipa.service file is necessary. Updated patches are attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0039-02-Use-correct-DS-instance-in-ipactl-status.patch Type: text/x-patch Size: 4335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0040-02-Avoid-systemd-service-deadlock-during-shutdown.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: From simo at redhat.com Wed Jul 10 16:33:42 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Jul 2013 12:33:42 -0400 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <20130710161544.GC18587@redhat.com> References: <20130703151713.GQ27655@localhost.localdomain> <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> <20130709094200.GH6481@hendrix.brq.redhat.com> <20130709100133.GJ6481@hendrix.brq.redhat.com> <20130710161544.GC18587@redhat.com> Message-ID: <1373474022.30537.241.camel@willson.li.ssimo.org> On Wed, 2013-07-10 at 19:15 +0300, Alexander Bokovoy wrote: > On Tue, 09 Jul 2013, Jakub Hrozek wrote: > >On Tue, Jul 09, 2013 at 11:42:00AM +0200, Jakub Hrozek wrote: > >> On Tue, Jul 09, 2013 at 10:33:19AM +0300, Alexander Bokovoy wrote: > >> > On Mon, 08 Jul 2013, Jakub Hrozek wrote: > >> > >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: > >> > >>On Mon, 08 Jul 2013, Jakub Hrozek wrote: > >> > >>>On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: > >> > >>>>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: > >> > >>>>>On Wed, 03 Jul 2013, Sumit Bose wrote: > >> > >>>>>>Hi, > >> > >>>>>> > >> > >>>>>>with this patch the extdom plugin, the LDAP extended operation that > >> > >>>>>>allows IPA clients with recent SSSD to lookup AD users and groups, will > >> > >>>>>>not use winbind for the lookup anymore but will use SSSD running in > >> > >>>>>>ipa_server_mode. > >> > >>>>>> > >> > >>>>>>Since now no plugin uses the winbind client libraries anymore, the > >> > >>>>>>second patch removes the related configures checks. > >> > >>>>>> > >> > >>>>>>I think for the time being we cannot remove winbind completely because > >> > >>>>>>it might be needed for msbd to work properly in a trusted environment. > >> > >>>>>s/msbd/smbd/ > >> > >>>>> > >> > >>>>>ACK. I need to add 'ipa_server_mode = True' support to > >> > >>>>>the installer code and then these patches can go in. > >> > >>>>Actually, the code still doesn't work due to some bug in sssd which > >> > >>>>fails to respond properly to getsidbyname() request in libsss_nss_idmap. > >> > >>>> > >> > >>>>Additionally I've found one missing treatment of domain_name for > >> > >>>>INP_NAME requests. > >> > >>>> > >> > >>>>We are working with Jakub on tracking down what's wrong on SSSD side. > >> > >>> > >> > >>>Indeed, there was a casing issue in sysdb. You can continue testing with > >> > >>>lowercase user names in the meantime. A patch is already on the SSSD > >> > >>>list. > >> > >>In addition, we need to disqualify user name when returning back a > >> > >>packet from extdom operation as this is what SSSD expects. > >> > >> > >> > >>Attached patch does it for all types of requests. > >> > >> > >> > >>-- > >> > >>/ Alexander Bokovoy > >> > > > >> > >>>From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 > >> > >>From: Alexander Bokovoy > >> > >>Date: Mon, 8 Jul 2013 19:19:56 +0300 > >> > >>Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as > >> > >> sssd expects > >> > >> > >> > >>extdom plugin handles external operation over which SSSD asks IPA server about > >> > >>trusted domain users not found through normal paths but detected to belong > >> > >>to the trusted domains associated with IPA realm. > >> > >> > >> > >>SSSD expects that user or group name in the response will be unqualified > >> > >>because domain name for the user or group is also included in the response. > >> > >>Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully > >> > >>qualified name which includes the domain name we are asked to handle. > >> > >> > >> > >>The code already expects that fully-qualified names are following user at domain > >> > >>convention so we are simply tracking whether '@' symbol is present and is followed > >> > >>by the domain name. > >> > >>--- > >> > >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ > >> > >> 1 file changed, 26 insertions(+) > >> > >> > >> > >>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 8aa22e1..290da4e 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 > >> > >>@@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, > >> > >> &grp_result); > >> > >> } > >> > >> } > >> > >>+ domain_name = strdup(req->data.name.domain_name); > >> > > > >> > >I would prefer if this was a separate patch. But this is a correct > >> > >change. > >> > Separated. > >> > > >> > >> Ack to this patch. > >> > >> > > > >> > >> break; > >> > >> default: > >> > >> ret = LDAP_PROTOCOL_ERROR; > >> > >>@@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > >> > >> const char *domain_name, struct extdom_res **_res) > >> > >> { > >> > >> int ret = EFAULT; > >> > >>+ char *locat = NULL; > >> > >> struct extdom_res *res; > >> > >> > >> > >> res = calloc(1, sizeof(struct extdom_res)); > >> > >>@@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, > >> > >> switch(id_type) { > >> > >> case SSS_ID_TYPE_UID: > >> > >> case SSS_ID_TYPE_BOTH: > >> > >>+ if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > >> > >>+ if (strstr(locat, domain_name) != NULL ) { > >> > > > >> > >strstr doesn't work correctly in my case. In SSSD, the domain names are > >> > >case-insensitive, so you can use strcasestr here. In my case, the > >> > >condition is never hit as the domain case differs: > >> > > > >> > >407 res->data.user.domain_name = strdup(domain_name); > >> > >(gdb) > >> > >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { > >> > >(gdb) n > >> > >409 if (strstr(locat, domain_name) != NULL) { > >> > >(gdb) > >> > >414 strdup(pg_data->data.pwd.pw_name); > >> > >(gdb) p domain_name > >> > >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" > >> > >(gdb) p locat > >> > >$2 = 0x7f2e8006500d "@ad.example.com" > >> > Replaced by strcasestr. > >> > > >> > > >> > > > >> > >Also, this is good enough for the beta or when the default values are used, but > >> > >in theory, the admin could configure the fully qualified name format to not > >> > >include the @-sign (see full_name_format in sssd.conf) at all. > >> > > > >> > >It's not very likely, but I think we should account for that case > >> > >eventually. I'm not exactly sure how yet as the full_name_format is pretty > >> > >free-form, maybe we could simply disallow setting it if server_mode was > >> > >set to True. > >> > I'd prefer the latter indeed. Given that you can have full_name_format > >> > varying between servers and clients, this is simply asking for disaster. > >> > > >> > I'd preper concentrating our effort on making default configuration > >> > working so well that you never need to modify these parameters. After > >> > all, we are talking about SSSD use as FreeIPA client with trusts > >> > enabled. SSSD configuration is dictated by ipa-client-install in this > >> > case for all clients. > >> > >> And Ack to the second patch as well. > >> > >> I opened https://fedorahosted.org/sssd/ticket/2009 on the SSSD side to > >> make the behaviour more predictable and robust. > > > >btw of course I tested with Sumit's patches applied before these two. > >They are quite large and I don't think I can review them, but from > >purely functional point of view, ack. > Simo asked to replace strcasestr() with strcasecmp() and I also replaced > '@' with SSSD_DOMAIN_SEPARATOR to make it clear what we are dealing > with. > > We'll need to be able to read separator value out of /etc/sssd.conf. I > wonder if this could actually be done by libsss_nss_idmap so that we > don't need to reimplement the code to read config and link directly with > libini_config. ack from me Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Jul 10 16:55:19 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Jul 2013 19:55:19 +0300 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130710152925.GB18587@redhat.com> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> <20130709203923.GP6481@hendrix.brq.redhat.com> <1373462246.30537.231.camel@willson.li.ssimo.org> <20130710152925.GB18587@redhat.com> Message-ID: <20130710165519.GD18587@redhat.com> On Wed, 10 Jul 2013, Alexander Bokovoy wrote: > On Wed, 10 Jul 2013, Simo Sorce wrote: >> On Tue, 2013-07-09 at 22:39 +0200, Jakub Hrozek wrote: >>> On Tue, Jul 09, 2013 at 02:12:33PM +0300, Alexander Bokovoy wrote: >>> > On Tue, 09 Jul 2013, Jakub Hrozek wrote: >>> > >On Wed, Jul 03, 2013 at 02:53:55PM +0200, Sumit Bose wrote: >>> > >>On Wed, Jul 03, 2013 at 01:00:43PM +0300, Alexander Bokovoy wrote: >>> > >>> On Mon, 01 Jul 2013, Sumit Bose wrote: >>> > >>> >Hi, >>> > >>> > >>> > >>> >this patch fixes https://fedorahosted.org/freeipa/ticket/3651 but only >>> > >>> >to allow SSSD running on a FreeIPA server to access the AD LDAP server. >>> > >>> >In the ticket a more generic solution is described but since there is no >>> > >>> >other use case so far I think this patch is sufficient for the time >>> > >>> >being. >>> > >>> > >>> > >>> >bye, >>> > >>> >Sumit >>> > >>> >>> > >>> >From a707d8f9d771dfe4fb8487e051519dba0ef72449 Mon Sep 17 00:00:00 2001 >>> > >>> >From: Sumit Bose >>> > >>> >Date: Mon, 1 Jul 2013 13:47:22 +0200 >>> > >>> >Subject: [PATCH] Add PAC to master host TGTs >>> > >>> > >>> > >>> >For a proper SALS bind with GSSAPI against an AD LDAP server a PAC is >>> > >>> >needed. To allow SSSD in ipa_server_mode to access the LDAP or GC server >>> > >>> >of a trusted domain with the credentials of a FreeIPA server host a >>> > >>> >PAC must be added to the TGT for the host. >>> > >>> s/SALS/SASL/ >>> > >> >>> > >>Thank you for the review, I've fixed the typo and added the numerical >>> > >>values for the well-known RIDs to the commit message. >>> > >> >>> > >>> >>> > >>> >>> > >>> >To determine if a host is a FreeIPA server or not it is checked if there >>> > >>> >is an entry for the host in cn=master,cn=ipa,cn=etc,$base. Unfortunately >>> > >>> >this requires an additional LDAP lookup. But since TGS-REQs for hosts >>> > >>> >should be rare I think it is acceptable for the time being. >>> > >>> I think it is better to change this lookup to >>> > >>> "cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX", it would >>> > >>> explicitly limit us to the IPA masters running AD trusts. >>> > >> >>> > >>I'm not sure if this restriction is needed. With SSSD's ipa_server_mode >>> > >>any IPA master (which networkwise can access an AD server of the trusted >>> > >>domain) can read AD user and group data, no running smbd or winbind is >>> > >>required. So it would be possible to run the extdom plugin or the compat >>> > >>plugin for the legacy clients on any IPA server which would allow a much >>> > >>better load balancing. >>> > >> >>> > >>If there are other concerns I'm happy to add the restriction. >>> > >> >>> > >>bye, >>> > >>Sumit >>> > > >>> > >I don't think I know the code good enough to provide a full review, but >>> > >the patch enables the lookups from an IPA master without any additional >>> > >hacks. So ack on functionality at least. >>> > Ok. >>> > >>> > I've extended this functionality to generate MS-PAC also for services >>> > running on IPA masters. Patch attached. >>> > >>> > This is needed to finally get rid of access to trust auth material for >>> > IPA python code. HTTP/fqdn at REALM will now be able to authenticate >>> > against AD LDAP server and look up needed information directly, without >>> > elevating privileges to trust admins. >>> > >>> > This should also help for AD range discovery Tomas is working on. >>> > >>> >>> Hi, >>> >>> The patch looks good to me so I'm giving my +1. I would appreciate other >>> review too before a full ack, though. >> >> I've nacked the approach, although the results are as expected. >> Alexander will send a simplified patch that avoids the extra search and >> use of managedby which is not ok. > New patch attached. After discussion with Simo on IRC, I decided to use krb5_parse_name() to properly parse krbPrincipalName attribute for the service and veto it against pre-defined set of services we support generating MS-PAC for on the IPA master. The list currently includes only cifs/ipa.master at REALM and HTTP/ipa.master at REALM as host/ipa.master at REALM is handled by the is_host case. I verified it by initializing ccache with /etc/httpd/conf/ipa.keytab and accessing AD over LDAP, it worked well (same result for host/): --------------------------------------------------------------------- # kinit -kt /etc/httpd/conf/ipa.keytab HTTP/ipa.example.com at EXAMPLE.COM # ldapsearch -Y GSSAPI -h altai.ad.lan -b dc=ad,dc=lan '(cn=IPAX$)' SASL/GSSAPI authentication started SASL username: HTTP/ipa.example.com at EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (cn=IPAX$) # requesting: ALL # # IPAX$, Users, ad.lan dn: CN=IPAX$,CN=Users,DC=ad,DC=lan objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: IPAX$ distinguishedName: CN=IPAX$,CN=Users,DC=ad,DC=lan instanceType: 4 whenCreated: 20130708091622.0Z whenChanged: 20130710123914.0Z uSNCreated: 98603 uSNChanged: 102524 name: IPAX$ objectGUID:: FxL42tGLnEOfKkuMw6sVVw== userAccountControl: 2080 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 130179335549552172 pwdLastSet: 130177485824178582 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAzl3L0KYmgQdG8ZPbeQQAAA== accountExpires: 9223372036854775807 logonCount: 1 sAMAccountName: IPAX$ sAMAccountType: 805306370 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=lan isCriticalSystemObject: TRUE dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 130179335549552172 # search reference ref: ldap://ForestDnsZones.ad.lan/DC=ForestDnsZones,DC=ad,DC=lan # search reference ref: ldap://DomainDnsZones.ad.lan/DC=DomainDnsZones,DC=ad,DC=lan # search reference ref: ldap://ad.lan/CN=Configuration,DC=ad,DC=lan # search result search: 4 result: 0 Success # numResponses: 5 # numEntries: 1 # numReferences: 3 --------------------------------------------------------------------- When I tried to initialize ccache with /etc/dirsrv/ds.keytab, I've got: --------------------------------------------------------------------- # kinit -kt /etc/dirsrv/ds.keytab ldap/ipa.example.com at EXAMPLE.COM # ldapsearch -Y GSSAPI -h altai.ad.lan -b dc=ad,dc=lan '(cn=IPAX$)' SASL/GSSAPI authentication started SASL username: ldap/ipa.example.com at EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (cn=IPAX$) # requesting: ALL # # search result search: 4 result: 1 Operations error text: 000004DC: LdapErr: DSID-0C090724, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v23f0 # numResponses: 1 --------------------------------------------------------------------- -- / Alexander Bokovoy -------------- next part -------------- >From 124e6ed79c69d486b9d9bf69d9bfef354b40840b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 9 Jul 2013 14:05:02 +0300 Subject: [PATCH 15/15] Generate syntethic MS-PAC for all services running on IPA master MS-PAC is required to be present in TGT if one wants to connect to AD services using this TGT. Users get MS-PAC by default, SSSD in ipa_server_mode uses host/fqdn at REALM principal to talk to AD LDAP. This patch enables other services running on IPA master to connect to AD services. This is required for IPA python code doing discovery of remote AD domain settings shortly after IPA-AD trust has been established. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 79 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 92dc8dd..96eac6f 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -93,9 +93,21 @@ static char *memberof_pac_attrs[] = { NULL }; + +static struct { + char *service; + int length; +} supported_services[] = { + {"cifs", sizeof("cifs")}, + {"HTTP", sizeof("HTTP")}, + {NULL, 0} +}; + + #define SID_ID_AUTHS 6 #define SID_SUB_AUTHS 15 #define MAX(a,b) (((a)>(b))?(a):(b)) +#define MIN(a,b) (((a)<(b))?(a):(b)) #define AUTHZ_DATA_TYPE_PAC "MS-PAC" #define AUTHZ_DATA_TYPE_PAD "PAD" @@ -395,10 +407,14 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, char *strres; int intres; int ret; + int i; char **objectclasses = NULL; size_t c; bool is_host = false; bool is_user = false; + bool is_service = false; + krb5_principal princ; + krb5_data *data; ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "objectClass", &objectclasses); @@ -407,6 +423,9 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, if (strcasecmp(objectclasses[c], "ipaHost") == 0) { is_host = true; } + if (strcasecmp(objectclasses[c], "ipaService") == 0) { + is_service = true; + } if (strcasecmp(objectclasses[c], "ipaNTUserAttrs") == 0) { is_user = true; } @@ -415,8 +434,8 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } free(objectclasses); - if (!is_host && !is_user) { - /* We only handle users and hosts */ + if (!is_host && !is_user && !is_service) { + /* We only handle users and hosts, and services */ return ENOENT; } @@ -433,6 +452,54 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, free(strres); return ENOENT; } + } else if (is_service) { + ret = ipadb_ldap_attr_to_str(lcontext, lentry, "krbPrincipalName", &strres); + if (ret) { + /* krbPrincipalName is mandatory for services */ + return ret; + } + + ret = krb5_parse_name(ipactx->kcontext, strres, &princ); + + free(strres); + if (ret) { + return ENOENT; + } + + if (krb5_princ_size(ipactx->kcontext, princ) != 2) { + krb5_free_principal(ipactx->kcontext, princ); + return ENOENT; + } + + data = krb5_princ_component(ipactx->context, princ, 0); + for (i = 0; supported_services[i].service; i++) { + if (0 == memcmp(data->data, supported_services[i].service, + MIN(supported_services[i].length, data->length))) { + break; + } + } + + if (supported_services[i].service == NULL) { + krb5_free_principal(ipactx->kcontext, princ); + return ENOENT; + } + + data = krb5_princ_component(ipactx->context, princ, 1); + strres = malloc(data->length); + if (strres == NULL) { + krb5_free_principal(ipactx->kcontext, princ); + return ENOENT; + } + + memcpy(strres, data->data, data->length); + krb5_free_principal(ipactx->kcontext, princ); + + /* Only add PAC to TGT to services on IPA masters to allow querying + * AD LDAP server */ + if (!is_master_host(ipactx, strres)) { + free(strres); + return ENOENT; + } } else { ret = ipadb_ldap_attr_to_str(lcontext, lentry, "uid", &strres); if (ret) { @@ -444,7 +511,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.account_name.string = talloc_strdup(memctx, strres); free(strres); - if (is_host) { + if (is_host || is_service) { prigid = 515; /* Well known RID for domain computers group */ } else { ret = ipadb_ldap_attr_to_int(lcontext, lentry, "gidNumber", &intres); @@ -567,7 +634,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, info3->base.logon_count = 0; /* we do not have this info yet */ info3->base.bad_password_count = 0; /* we do not have this info yet */ - if (is_host) { + if (is_host || is_service) { /* Well know RID of domain controllers group */ info3->base.rid = 516; } else { @@ -658,7 +725,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, } if (info3->base.primary_gid == 0) { - if (is_host) { + if (is_host || is_service) { info3->base.primary_gid = 515; /* Well known RID for domain computers group */ } else { if (ipactx->mspac->fallback_rid) { @@ -698,7 +765,7 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, return ENOENT; } - if (is_host) { + if (is_host || is_service) { info3->base.domain_sid = talloc_memdup(memctx, &ipactx->mspac->domsid, sizeof(ipactx->mspac->domsid)); } else { -- 1.8.3.1 From simo at redhat.com Wed Jul 10 17:04:49 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Jul 2013 13:04:49 -0400 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <20130710165519.GD18587@redhat.com> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> <20130709203923.GP6481@hendrix.brq.redhat.com> <1373462246.30537.231.camel@willson.li.ssimo.org> <20130710152925.GB18587@redhat.com> <20130710165519.GD18587@redhat.com> Message-ID: <1373475889.30537.247.camel@willson.li.ssimo.org> On Wed, 2013-07-10 at 19:55 +0300, Alexander Bokovoy wrote: > >>> The patch looks good to me so I'm giving my +1. I would appreciate > other > >>> review too before a full ack, though. > >> > >> I've nacked the approach, although the results are as expected. > >> Alexander will send a simplified patch that avoids the extra search > and > >> use of managedby which is not ok. > > New patch attached. > After discussion with Simo on IRC, I decided to use krb5_parse_name() > to > properly parse krbPrincipalName attribute for the service and veto it > against pre-defined set of services we support generating MS-PAC for > on > the IPA master. > > The list currently includes only cifs/ipa.master at REALM and > HTTP/ipa.master at REALM as host/ipa.master at REALM is handled by the > is_host > case. > LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Jul 10 19:11:37 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 10 Jul 2013 15:11:37 -0400 Subject: [Freeipa-devel] [PATCH] Fix for small syntax error in OTP schema Message-ID: <1373483497.16354.14.camel@localhost.localdomain> https://fedorahosted.org/freeipa/ticket/3765 Due to the potentially bad ramifications of a schema syntax error, I tested this in both single server and replica configurations. The worst case in both is a truncated attribute description. The above patch fixes the problem in both cases with a simple ipa-ldap-updater. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0011-Fix-for-small-syntax-error-in-OTP-schema.patch Type: text/x-patch Size: 4387 bytes Desc: not available URL: From jhrozek at redhat.com Wed Jul 10 20:27:16 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Jul 2013 22:27:16 +0200 Subject: [Freeipa-devel] [PATCH] Remove unused variable Message-ID: <20130710202716.GM6481@hendrix.brq.redhat.com> Hi, I was doing quite a few builds of freeipa for testing and patch reviews lately and found a couple of unused variables. The attached patch removed the variables. -------------- next part -------------- >From f3408502fe3e4392dff4085b58670241cd1956ae Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Tue, 9 Jul 2013 21:55:04 +0200 Subject: [PATCH] Remove unused variable --- daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c | 4 ---- daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c | 1 - 2 files changed, 5 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c index fcd4d30a3d813204cc36c499fd9c0fa64156974f..0b3b84108476b0c6fc153b49cd0f65f9279035f2 100644 --- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c +++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c @@ -232,7 +232,6 @@ int ipalockout_getpolicy(Slapi_Entry *target_entry, Slapi_Entry **policy_entry, char **errstr) { int ldrc = 0; - int flags = 0; int type_name_disposition = 0; Slapi_DN *pdn = NULL; @@ -415,7 +414,6 @@ static int ipalockout_postop(Slapi_PBlock *pb) char *lastfail = NULL; int tries = 0; int failure = 1; - int type_name_disposition = 0; char *actual_type_name = NULL; int attr_free_flags = 0; Slapi_ValueSet *values = NULL; @@ -665,7 +663,6 @@ static int ipalockout_preop(Slapi_PBlock *pb) Slapi_Entry *target_entry = NULL; Slapi_Entry *policy_entry = NULL; Slapi_DN *sdn = NULL; - Slapi_DN *pdn = NULL; Slapi_Value *objectclass = NULL; char *errstr = NULL; int ldrc = 0; @@ -678,7 +675,6 @@ static int ipalockout_preop(Slapi_PBlock *pb) time_t last_failed = 0; char *lastfail = NULL; char *unlock_time = NULL; - int type_name_disposition = 0; char *actual_type_name = NULL; int attr_free_flags = 0; Slapi_ValueSet *values = NULL; diff --git a/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c b/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c index ae7adecb6e04b5a736fa04b458d51a6fa3860d05..65ceaea685a276db91aab356dab617e260095873 100644 --- a/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c +++ b/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c @@ -853,7 +853,6 @@ ipa_winsync_config_refresh_domain( int loopdone = 0; int search_scope = LDAP_SCOPE_SUBTREE; int ret = LDAP_SUCCESS; - Slapi_Value *sv = NULL; int acct_disable; char *inactivated_filter = NULL; char *activated_filter = NULL; -- 1.8.3.1 From tbabej at redhat.com Thu Jul 11 06:59:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 08:59:24 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51CAA280.9090900@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C841AC.1050604@redhat.com> <51CAA280.9090900@redhat.com> Message-ID: <24977773.5fSg6SGopZ@thinkpad7.brq.redhat.com> On Wednesday 26 of June 2013 10:12:48 Petr Spacek wrote: [snip] > > Appropriate error handling = Return 'Permission denied' if particular > operation requires higher privileges. > > IMHO 'cryptic' error message is bad in any case, so the right way how to fix > 'cryptic' error messages is to fix the places where errors are thrown. > > I don't think that additional checks in 'advisor' to hide 'cryptic' errors are > the right approach. > > -- > Petr^2 Spacek To wrap-up, after an offline discussion Petr: We came to an conclusion that since 'require_root' attribute is optional (Petr was not aware of that, and that fact was what caused his concern), with default value False, the attribute should not pose any additional burden for the plugin developer. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Jul 11 08:53:37 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 10:53:37 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51DD4E63.5010800@redhat.com> References: <519357F3.3080408@redhat.com> <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> <51DD4E63.5010800@redhat.com> Message-ID: <1795359.XAoWLNcAuc@thinkpad7.brq.redhat.com> [snip] > > The patch now fixes the issue. > > > > > > > > However, we need to bump the dependency in the specfile since now we require > > > > version 1.3.1.1. > > > > > > > > Tomas > > > > Thanks, updated patch is attached. > I tested the patch both with clean install and upgrade. ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Jul 11 09:19:44 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 11:19:44 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51C43E88.7000807@redhat.com> References: <51B86955.6040905@redhat.com> <51C43E88.7000807@redhat.com> Message-ID: <1592475.0Os3DrEZJ8@thinkpad7.brq.redhat.com> On Friday 21 of June 2013 13:52:40 Ana Krivokapic wrote: > On 06/12/2013 02:28 PM, Tomas Babej wrote: > > Hi, > > > > Drops the code from ipa-server-install, ipa-dns-install and the > > BindInstance itself. Also changed ipa-upgradeconfig script so > > that it does not set zone_refresh to 0 on upgrades, as the option > > is deprecated, but rather removes it altogether. > > > > https://fedorahosted.org/freeipa/ticket/3632 > > > > Tomas > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > 1) ipa-server-install (with no DNS), followed by ipa-dns-install now fails, > because you missed one reference to options.persistent_search in ipa-dns-install: > > if options.serial_autoincrement and not options.persistent_search: > parser.error('persistent search feature is required for ' > 'DNS SOA serial autoincrement') > > 2) I wonder if we can also remove the '--zone-notif' option from > ipa-server-install and ipa-dns-install. It is already deprecated so maybe this > is a good time to drop it altogether? > > 3) You can remove the 'persistant_search' attribute of the BindInstance class, > and just hardcode the value to "yes" in the '__setup_sub_dict()' method. > Updated patch adresses all 3 issues. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Jul 11 09:20:54 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 11:20:54 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <1592475.0Os3DrEZJ8@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <51C43E88.7000807@redhat.com> <1592475.0Os3DrEZJ8@thinkpad7.brq.redhat.com> Message-ID: <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> On Thursday 11 of July 2013 11:19:44 Tomas Babej wrote: > On Friday 21 of June 2013 13:52:40 Ana Krivokapic wrote: > > On 06/12/2013 02:28 PM, Tomas Babej wrote: > > > Hi, > > > > > > Drops the code from ipa-server-install, ipa-dns-install and the > > > BindInstance itself. Also changed ipa-upgradeconfig script so > > > that it does not set zone_refresh to 0 on upgrades, as the option > > > is deprecated, but rather removes it altogether. > > > > > > https://fedorahosted.org/freeipa/ticket/3632 > > > > > > Tomas > > > > > > > > > _______________________________________________ > > > Freeipa-devel mailing list > > > Freeipa-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > 1) ipa-server-install (with no DNS), followed by ipa-dns-install now fails, > > because you missed one reference to options.persistent_search in ipa-dns-install: > > > > if options.serial_autoincrement and not options.persistent_search: > > parser.error('persistent search feature is required for ' > > 'DNS SOA serial autoincrement') > > > > 2) I wonder if we can also remove the '--zone-notif' option from > > ipa-server-install and ipa-dns-install. It is already deprecated so maybe this > > is a good time to drop it altogether? > > > > 3) You can remove the 'persistant_search' attribute of the BindInstance class, > > and just hardcode the value to "yes" in the '__setup_sub_dict()' method. > > > > Updated patch adresses all 3 issues. > > Tomas And it comes here. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-2-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 12088 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 11 09:36:03 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 12:36:03 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <51DD8D93.2040100@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> Message-ID: <20130711093603.GE18587@redhat.com> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>> Hello, >>> >>> Attached patches fix systemd and ipactl related bugs: >>> >>> https://fedorahosted.org/freeipa/ticket/3730 >>> https://fedorahosted.org/freeipa/ticket/3729 >> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >> upgrade properly and everything else has failed afterwards. >> > >This was caused due to 'systemctl is-active' returning exit status 3 >('activating'), and our code treating the non-zero exit status as a failure. I >handled this case in the updated patch. > >As for the ipa.service and dependency ordering, I have done some further testing >and found out the adding the '--ignore-dependencies' switch alone solves the >shutdown issue. So I think that no modification of ipa.service file is necessary. > >Updated patches are attached. This is much better. However, 'ipactl stop' doesn't stop ns-slapd and dogtag: 1155 ? Sl 0:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid -w /var/run/dirsrv/slapd-EXAMPLE-COM.startpid 1485 ? Sl 0:11 /usr/lib/jvm/jre/bin/java -DRESTEASY_LIB=/usr/share/java/resteasy -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.security.manager -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start # systemctl status dirsrv.target dirsrv.target - 389 Directory Server Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; disabled) Active: inactive (dead) since ?? 2013-07-11 12:32:19 EEST; 1min 52s ago ??? 11 12:31:31 ipa.example.com systemd[1]: Stopping 389 Directory Server. ??? 11 12:31:31 ipa.example.com systemd[1]: Starting 389 Directory Server. ??? 11 12:31:31 ipa.example.com systemd[1]: Reached target 389 Directory Server. ??? 11 12:32:19 ipa.example.com systemd[1]: Stopping 389 Directory Server. ??? 11 12:32:19 ipa.example.com systemd[1]: Stopped target 389 Directory Server. # systemctl status dirsrv at EXAMPLE-COM dirsrv at EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/lib/systemd/system/dirsrv at .service; enabled) Active: active (running) since ?? 2013-07-11 12:31:32 EEST; 2min 59s ago Process: 1121 ExecStopPost=/bin/rm -f /var/run/dirsrv/slapd-%i.pid (code=exited, status=0/SUCCESS) Process: 1123 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS) Main PID: 1155 (ns-slapd) CGroup: name=systemd:/system/dirsrv at .service/dirsrv at EXAMPLE-COM.service ??1155 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid -w /var/run/dirsrv/slapd-EXAMPLE-COM.startpi... ??? 11 12:31:34 ipa.example.com ns-slapd[1155]: GSSAPI server step 2 ??? 11 12:31:34 ipa.example.com ns-slapd[1155]: GSSAPI server step 3 ??? 11 12:31:34 ipa.example.com ns-slapd[1155]: GSSAPI server step 2 ??? 11 12:31:34 ipa.example.com ns-slapd[1155]: GSSAPI server step 3 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 1 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 2 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 3 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 1 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 2 ??? 11 12:31:56 ipa.example.com ns-slapd[1155]: GSSAPI server step 3 When I issue 'ipactl restart' all processes are restarted properly. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 09:38:50 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 12:38:50 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130711093603.GE18587@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> Message-ID: <20130711093850.GF18587@redhat.com> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>Hello, >>>> >>>>Attached patches fix systemd and ipactl related bugs: >>>> >>>>https://fedorahosted.org/freeipa/ticket/3730 >>>>https://fedorahosted.org/freeipa/ticket/3729 >>>NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>upgrade properly and everything else has failed afterwards. >>> >> >>This was caused due to 'systemctl is-active' returning exit status 3 >>('activating'), and our code treating the non-zero exit status as a failure. I >>handled this case in the updated patch. >> >>As for the ipa.service and dependency ordering, I have done some further testing >>and found out the adding the '--ignore-dependencies' switch alone solves the >>shutdown issue. So I think that no modification of ipa.service file is necessary. >> >>Updated patches are attached. >This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >dogtag: What's important is the fact that now I can issue reboot and VM restarts, not hangs, and then IPA starts properly on boot -- this is because when ns-slapd gets a signal from systemd, it automatically shuts itself down properly and the same happens to dogtag. This is good enough so that I push current patches to master but please proceed on fixing 'ipactl stop' issue. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 09:49:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 12:49:34 +0300 Subject: [Freeipa-devel] [PATCH] 140 Check trust chain length in CA-less install In-Reply-To: <51DD81CF.1020004@redhat.com> References: <51C04E37.7060206@redhat.com> <51DD81CF.1020004@redhat.com> Message-ID: <20130711094934.GG18587@redhat.com> On Wed, 10 Jul 2013, Rob Crittenden wrote: >Jan Cholasta wrote: >>Hi, >> >>the attached patch fixes . >> >>Honza > >This patch seems to work ok but I've been unable to test it with an >external CA installation because that seems to be broken (unrelated >to this patch). > >I filed https://fedorahosted.org/freeipa/ticket/3773 Commited to master, ipa-3-2: master: ab96ca7831ad8ab2ee2389093ea8b9327d94d6f0 ipa-3-2: e1f481c891b67c79b7d7cc1e9a3ac636826c90cb -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 09:58:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 12:58:27 +0300 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <20130708072254.GG3956@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> Message-ID: <20130711095827.GH18587@redhat.com> On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >On Thu, 27 Jun 2013, Jan Cholasta wrote: >>On 27.6.2013 17:34, Rich Megginson wrote: >>>On 06/27/2013 09:31 AM, Jan Cholasta wrote: >>>>The search is hard-coded in the referint plugin, see >>>>. >>>> >>> >>>Not sure if it makes sense to do a wildcard/substr search here - please >>>file a ticket with 389 to investigate. >> >>https://fedorahosted.org/389/ticket/47411 >So, should we merge this patchset or wait until 389-ds analyzes 47411? >To me it looks like we can use this one as an interim solution, once Web >UI performance is checked through. I've commited the patchset to master. Web UI works just fine for me and with a VM limited to 1GB RAM I seem to get snappier response even when running whole IPA stack and Firefox in the same VM. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jul 11 10:03:18 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Jul 2013 12:03:18 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <20130711095827.GH18587@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> Message-ID: <51DE82E6.4020307@redhat.com> On 11.7.2013 11:58, Alexander Bokovoy wrote: > On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >> On Thu, 27 Jun 2013, Jan Cholasta wrote: >>> On 27.6.2013 17:34, Rich Megginson wrote: >>>> On 06/27/2013 09:31 AM, Jan Cholasta wrote: >>>>> The search is hard-coded in the referint plugin, see >>>>> . >>>>> >>>>> >>>> >>>> Not sure if it makes sense to do a wildcard/substr search here - please >>>> file a ticket with 389 to investigate. >>> >>> https://fedorahosted.org/389/ticket/47411 >> So, should we merge this patchset or wait until 389-ds analyzes 47411? >> To me it looks like we can use this one as an interim solution, once Web >> UI performance is checked through. > I've commited the patchset to master. Web UI works just fine for me and > with a VM limited to 1GB RAM I seem to get snappier response even when > running whole IPA stack and Firefox in the same VM. > We can add WebUI improvements later. I have some WIP, but I need to discuss it with Petr first (he's away this week). Honza -- Jan Cholasta From abokovoy at redhat.com Thu Jul 11 10:15:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:15:52 +0300 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51DE82E6.4020307@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> Message-ID: <20130711101552.GI18587@redhat.com> On Thu, 11 Jul 2013, Jan Cholasta wrote: >On 11.7.2013 11:58, Alexander Bokovoy wrote: >>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >>>On Thu, 27 Jun 2013, Jan Cholasta wrote: >>>>On 27.6.2013 17:34, Rich Megginson wrote: >>>>>On 06/27/2013 09:31 AM, Jan Cholasta wrote: >>>>>>The search is hard-coded in the referint plugin, see >>>>>>. >>>>>> >>>>>> >>>>> >>>>>Not sure if it makes sense to do a wildcard/substr search here - please >>>>>file a ticket with 389 to investigate. >>>> >>>>https://fedorahosted.org/389/ticket/47411 >>>So, should we merge this patchset or wait until 389-ds analyzes 47411? >>>To me it looks like we can use this one as an interim solution, once Web >>>UI performance is checked through. >>I've commited the patchset to master. Web UI works just fine for me and >>with a VM limited to 1GB RAM I seem to get snappier response even when >>running whole IPA stack and Firefox in the same VM. >> > >We can add WebUI improvements later. I have some WIP, but I need to >discuss it with Petr first (he's away this week). Ok. The patchset is in ipa-3-2 as well now. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 10:24:32 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:24:32 +0300 Subject: [Freeipa-devel] [PATCH] Permit reads to ipatokenRadiusProxyUser objects In-Reply-To: <1372691139.2261.1.camel@localhost.localdomain> References: <1371580050.23980.20.camel@localhost.localdomain> <51C2D7A7.5070006@redhat.com> <1372691139.2261.1.camel@localhost.localdomain> Message-ID: <20130711102432.GJ18587@redhat.com> On Mon, 01 Jul 2013, Nathaniel McCallum wrote: >On Thu, 2013-06-20 at 12:21 +0200, Martin Kosek wrote: >> On 06/18/2013 08:27 PM, Nathaniel McCallum wrote: >> > Patch attached. >> > >> >> Hello Nathaniel, >> >> Thanks for the patch! I have just few general procedural comments with >> submitting patch: >> >> 1. As you are doing a work on an upstream ticket, please assign the upstream >> Trac ticket to yourself and accept it. When the patch is sent to the list, you >> should also mark the ticket as "patch sent". >> >> 2. Please follow our patch format: >> - https://fedorahosted.org/freeipa/wiki/PatchFormat >> >> This is just a short excerpt of our Development process: >> http://www.freeipa.org/page/Contribute#Development_Process > >Patch is attached with proper formatting. The ticket is properly >assigned and flagged. No code has changed since the last patch. Thanks. Works for me. Commited to master and ipa-3-2, ticket updated and closed. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jul 11 10:24:59 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Jul 2013 12:24:59 +0200 Subject: [Freeipa-devel] [PATCH 0173] Improve logging for cases where SOA serial autoincrementation failed Message-ID: <51DE87FB.50308@redhat.com> Hello, Improve logging for cases where SOA serial autoincrementation failed. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0173-Improve-logging-for-cases-where-SOA-serial-autoincre.patch Type: text/x-patch Size: 1239 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 11 10:31:35 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:31:35 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130711093850.GF18587@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> Message-ID: <20130711103135.GK18587@redhat.com> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >>On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>>On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>>On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>>Hello, >>>>> >>>>>Attached patches fix systemd and ipactl related bugs: >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/3730 >>>>>https://fedorahosted.org/freeipa/ticket/3729 >>>>NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>>upgrade properly and everything else has failed afterwards. >>>> >>> >>>This was caused due to 'systemctl is-active' returning exit status 3 >>>('activating'), and our code treating the non-zero exit status as a failure. I >>>handled this case in the updated patch. >>> >>>As for the ipa.service and dependency ordering, I have done some further testing >>>and found out the adding the '--ignore-dependencies' switch alone solves the >>>shutdown issue. So I think that no modification of ipa.service file is necessary. >>> >>>Updated patches are attached. >>This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >>dogtag: >What's important is the fact that now I can issue reboot and VM >restarts, not hangs, and then IPA starts properly on boot -- this is >because when ns-slapd gets a signal from systemd, it automatically shuts >itself down properly and the same happens to dogtag. This is good >enough so that I push current patches to master but please proceed on >fixing 'ipactl stop' issue. Also pushed to ipa-3-2 and updated the tickets 3729 and 3730. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 10:34:58 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:34:58 +0300 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <1795359.XAoWLNcAuc@thinkpad7.brq.redhat.com> References: <519357F3.3080408@redhat.com> <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> <51DD4E63.5010800@redhat.com> <1795359.XAoWLNcAuc@thinkpad7.brq.redhat.com> Message-ID: <20130711103458.GL18587@redhat.com> On Thu, 11 Jul 2013, Tomas Babej wrote: >[snip] > >> > The patch now fixes the issue. >> > >> > >> > >> > However, we need to bump the dependency in the specfile since now we require >> > >> > version 1.3.1.1. >> > >> > >> > >> > Tomas >> > >> >> Thanks, updated patch is attached. >> > >I tested the patch both with clean install and upgrade. > >ACK The patch does not apply to ipa-3-2, it needs rebasing. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 10:37:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:37:27 +0300 Subject: [Freeipa-devel] [PATCH] Fix for small syntax error in OTP schema In-Reply-To: <1373483497.16354.14.camel@localhost.localdomain> References: <1373483497.16354.14.camel@localhost.localdomain> Message-ID: <20130711103727.GM18587@redhat.com> On Wed, 10 Jul 2013, Nathaniel McCallum wrote: >https://fedorahosted.org/freeipa/ticket/3765 > >Due to the potentially bad ramifications of a schema syntax error, I >tested this in both single server and replica configurations. The worst >case in both is a truncated attribute description. The above patch fixes >the problem in both cases with a simple ipa-ldap-updater. ACK. Committed to master and ipa-3-2. -- / Alexander Bokovoy From akrivoka at redhat.com Thu Jul 11 10:54:16 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Jul 2013 12:54:16 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <20130711103458.GL18587@redhat.com> References: <519357F3.3080408@redhat.com> <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> <51DD4E63.5010800@redhat.com> <1795359.XAoWLNcAuc@thinkpad7.brq.redhat.com> <20130711103458.GL18587@redhat.com> Message-ID: <51DE8ED8.4090900@redhat.com> On 07/11/2013 12:34 PM, Alexander Bokovoy wrote: > On Thu, 11 Jul 2013, Tomas Babej wrote: >> [snip] >> >>> > The patch now fixes the issue. >>> > >>> > >>> > >>> > However, we need to bump the dependency in the specfile since now we require >>> > >>> > version 1.3.1.1. >>> > >>> > >>> > >>> > Tomas >>> > >>> >>> Thanks, updated patch is attached. >>> >> >> I tested the patch both with clean install and upgrade. >> >> ACK > The patch does not apply to ipa-3-2, it needs rebasing. > Rebased patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0029-04-Make-sure-replication-works-after-DM-password-is-cha.patch Type: text/x-patch Size: 4947 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 11 10:55:46 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 13:55:46 +0300 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51DE8ED8.4090900@redhat.com> References: <519357F3.3080408@redhat.com> <2463772.rGMmeTpr0y@thinkpad7.brq.redhat.com> <51DD4E63.5010800@redhat.com> <1795359.XAoWLNcAuc@thinkpad7.brq.redhat.com> <20130711103458.GL18587@redhat.com> <51DE8ED8.4090900@redhat.com> Message-ID: <20130711105546.GN18587@redhat.com> On Thu, 11 Jul 2013, Ana Krivokapic wrote: >On 07/11/2013 12:34 PM, Alexander Bokovoy wrote: >> On Thu, 11 Jul 2013, Tomas Babej wrote: >>> [snip] >>> >>>> > The patch now fixes the issue. >>>> > >>>> > >>>> > >>>> > However, we need to bump the dependency in the specfile since now we require >>>> > >>>> > version 1.3.1.1. >>>> > >>>> > >>>> > >>>> > Tomas >>>> > >>>> >>>> Thanks, updated patch is attached. >>>> >>> >>> I tested the patch both with clean install and upgrade. >>> >>> ACK >> The patch does not apply to ipa-3-2, it needs rebasing. >> > >Rebased patch attached. Thanks, committed to ipa-3-2. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 11:02:54 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 14:02:54 +0300 Subject: [Freeipa-devel] [PATCH] 117 extdom: replace winbind calls with POSIX/SSSD calls In-Reply-To: <1373474022.30537.241.camel@willson.li.ssimo.org> References: <20130708073053.GJ3956@redhat.com> <20130708131539.GK3956@redhat.com> <20130708141736.GI17598@hendrix.redhat.com> <20130708163241.GM3956@redhat.com> <20130708205738.GL17598@hendrix.redhat.com> <20130709073319.GA5205@redhat.com> <20130709094200.GH6481@hendrix.brq.redhat.com> <20130709100133.GJ6481@hendrix.brq.redhat.com> <20130710161544.GC18587@redhat.com> <1373474022.30537.241.camel@willson.li.ssimo.org> Message-ID: <20130711110254.GO18587@redhat.com> On Wed, 10 Jul 2013, Simo Sorce wrote: >On Wed, 2013-07-10 at 19:15 +0300, Alexander Bokovoy wrote: >> On Tue, 09 Jul 2013, Jakub Hrozek wrote: >> >On Tue, Jul 09, 2013 at 11:42:00AM +0200, Jakub Hrozek wrote: >> >> On Tue, Jul 09, 2013 at 10:33:19AM +0300, Alexander Bokovoy wrote: >> >> > On Mon, 08 Jul 2013, Jakub Hrozek wrote: >> >> > >On Mon, Jul 08, 2013 at 07:32:41PM +0300, Alexander Bokovoy wrote: >> >> > >>On Mon, 08 Jul 2013, Jakub Hrozek wrote: >> >> > >>>On Mon, Jul 08, 2013 at 04:15:39PM +0300, Alexander Bokovoy wrote: >> >> > >>>>On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >> >> > >>>>>On Wed, 03 Jul 2013, Sumit Bose wrote: >> >> > >>>>>>Hi, >> >> > >>>>>> >> >> > >>>>>>with this patch the extdom plugin, the LDAP extended operation that >> >> > >>>>>>allows IPA clients with recent SSSD to lookup AD users and groups, will >> >> > >>>>>>not use winbind for the lookup anymore but will use SSSD running in >> >> > >>>>>>ipa_server_mode. >> >> > >>>>>> >> >> > >>>>>>Since now no plugin uses the winbind client libraries anymore, the >> >> > >>>>>>second patch removes the related configures checks. >> >> > >>>>>> >> >> > >>>>>>I think for the time being we cannot remove winbind completely because >> >> > >>>>>>it might be needed for msbd to work properly in a trusted environment. >> >> > >>>>>s/msbd/smbd/ >> >> > >>>>> >> >> > >>>>>ACK. I need to add 'ipa_server_mode = True' support to >> >> > >>>>>the installer code and then these patches can go in. >> >> > >>>>Actually, the code still doesn't work due to some bug in sssd which >> >> > >>>>fails to respond properly to getsidbyname() request in libsss_nss_idmap. >> >> > >>>> >> >> > >>>>Additionally I've found one missing treatment of domain_name for >> >> > >>>>INP_NAME requests. >> >> > >>>> >> >> > >>>>We are working with Jakub on tracking down what's wrong on SSSD side. >> >> > >>> >> >> > >>>Indeed, there was a casing issue in sysdb. You can continue testing with >> >> > >>>lowercase user names in the meantime. A patch is already on the SSSD >> >> > >>>list. >> >> > >>In addition, we need to disqualify user name when returning back a >> >> > >>packet from extdom operation as this is what SSSD expects. >> >> > >> >> >> > >>Attached patch does it for all types of requests. >> >> > >> >> >> > >>-- >> >> > >>/ Alexander Bokovoy >> >> > > >> >> > >>>From 3659059c646f7b584ee07fb9e780759bcc0bb08e Mon Sep 17 00:00:00 2001 >> >> > >>From: Alexander Bokovoy >> >> > >>Date: Mon, 8 Jul 2013 19:19:56 +0300 >> >> > >>Subject: [PATCH] Fix extdom plugin to provide unqualified name in response as >> >> > >> sssd expects >> >> > >> >> >> > >>extdom plugin handles external operation over which SSSD asks IPA server about >> >> > >>trusted domain users not found through normal paths but detected to belong >> >> > >>to the trusted domains associated with IPA realm. >> >> > >> >> >> > >>SSSD expects that user or group name in the response will be unqualified >> >> > >>because domain name for the user or group is also included in the response. >> >> > >>Strip domain name from the name if getgrnam_r/getpwnam_r calls returned fully >> >> > >>qualified name which includes the domain name we are asked to handle. >> >> > >> >> >> > >>The code already expects that fully-qualified names are following user at domain >> >> > >>convention so we are simply tracking whether '@' symbol is present and is followed >> >> > >>by the domain name. >> >> > >>--- >> >> > >> .../ipa-extdom-extop/ipa_extdom_common.c | 26 ++++++++++++++++++++++ >> >> > >> 1 file changed, 26 insertions(+) >> >> > >> >> >> > >>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 8aa22e1..290da4e 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 >> >> > >>@@ -295,6 +295,7 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, >> >> > >> &grp_result); >> >> > >> } >> >> > >> } >> >> > >>+ domain_name = strdup(req->data.name.domain_name); >> >> > > >> >> > >I would prefer if this was a separate patch. But this is a correct >> >> > >change. >> >> > Separated. >> >> > >> >> >> >> Ack to this patch. >> >> >> >> > > >> >> > >> break; >> >> > >> default: >> >> > >> ret = LDAP_PROTOCOL_ERROR; >> >> > >>@@ -338,6 +339,7 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> >> > >> const char *domain_name, struct extdom_res **_res) >> >> > >> { >> >> > >> int ret = EFAULT; >> >> > >>+ char *locat = NULL; >> >> > >> struct extdom_res *res; >> >> > >> >> >> > >> res = calloc(1, sizeof(struct extdom_res)); >> >> > >>@@ -354,10 +356,20 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, >> >> > >> switch(id_type) { >> >> > >> case SSS_ID_TYPE_UID: >> >> > >> case SSS_ID_TYPE_BOTH: >> >> > >>+ if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >> >> > >>+ if (strstr(locat, domain_name) != NULL ) { >> >> > > >> >> > >strstr doesn't work correctly in my case. In SSSD, the domain names are >> >> > >case-insensitive, so you can use strcasestr here. In my case, the >> >> > >condition is never hit as the domain case differs: >> >> > > >> >> > >407 res->data.user.domain_name = strdup(domain_name); >> >> > >(gdb) >> >> > >408 if ((locat = strchr(pg_data->data.pwd.pw_name, '@')) != NULL) { >> >> > >(gdb) n >> >> > >409 if (strstr(locat, domain_name) != NULL) { >> >> > >(gdb) >> >> > >414 strdup(pg_data->data.pwd.pw_name); >> >> > >(gdb) p domain_name >> >> > >$1 = 0x7f2e800f0690 "AD.EXAMPLE.COM" >> >> > >(gdb) p locat >> >> > >$2 = 0x7f2e8006500d "@ad.example.com" >> >> > Replaced by strcasestr. >> >> > >> >> > >> >> > > >> >> > >Also, this is good enough for the beta or when the default values are used, but >> >> > >in theory, the admin could configure the fully qualified name format to not >> >> > >include the @-sign (see full_name_format in sssd.conf) at all. >> >> > > >> >> > >It's not very likely, but I think we should account for that case >> >> > >eventually. I'm not exactly sure how yet as the full_name_format is pretty >> >> > >free-form, maybe we could simply disallow setting it if server_mode was >> >> > >set to True. >> >> > I'd prefer the latter indeed. Given that you can have full_name_format >> >> > varying between servers and clients, this is simply asking for disaster. >> >> > >> >> > I'd preper concentrating our effort on making default configuration >> >> > working so well that you never need to modify these parameters. After >> >> > all, we are talking about SSSD use as FreeIPA client with trusts >> >> > enabled. SSSD configuration is dictated by ipa-client-install in this >> >> > case for all clients. >> >> >> >> And Ack to the second patch as well. >> >> >> >> I opened https://fedorahosted.org/sssd/ticket/2009 on the SSSD side to >> >> make the behaviour more predictable and robust. >> > >> >btw of course I tested with Sumit's patches applied before these two. >> >They are quite large and I don't think I can review them, but from >> >purely functional point of view, ack. >> Simo asked to replace strcasestr() with strcasecmp() and I also replaced >> '@' with SSSD_DOMAIN_SEPARATOR to make it clear what we are dealing >> with. >> >> We'll need to be able to read separator value out of /etc/sssd.conf. I >> wonder if this could actually be done by libsss_nss_idmap so that we >> don't need to reimplement the code to read config and link directly with >> libini_config. > >ack from me Committed to master. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 11 11:03:15 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 14:03:15 +0300 Subject: [Freeipa-devel] [PATCH] 116 Add PAC to master host TGTs In-Reply-To: <1373475889.30537.247.camel@willson.li.ssimo.org> References: <20130701143817.GK27655@localhost.localdomain> <20130703100043.GA12345@leiri.espoo.7ia.org> <20130703125355.GO27655@localhost.localdomain> <20130709095650.GI6481@hendrix.brq.redhat.com> <20130709111233.GB5205@redhat.com> <20130709203923.GP6481@hendrix.brq.redhat.com> <1373462246.30537.231.camel@willson.li.ssimo.org> <20130710152925.GB18587@redhat.com> <20130710165519.GD18587@redhat.com> <1373475889.30537.247.camel@willson.li.ssimo.org> Message-ID: <20130711110315.GP18587@redhat.com> On Wed, 10 Jul 2013, Simo Sorce wrote: >On Wed, 2013-07-10 at 19:55 +0300, Alexander Bokovoy wrote: >> >>> The patch looks good to me so I'm giving my +1. I would appreciate >> other >> >>> review too before a full ack, though. >> >> >> >> I've nacked the approach, although the results are as expected. >> >> Alexander will send a simplified patch that avoids the extra search >> and >> >> use of managedby which is not ok. >> > New patch attached. >> After discussion with Simo on IRC, I decided to use krb5_parse_name() >> to >> properly parse krbPrincipalName attribute for the service and veto it >> against pre-defined set of services we support generating MS-PAC for >> on >> the IPA master. >> >> The list currently includes only cifs/ipa.master at REALM and >> HTTP/ipa.master at REALM as host/ipa.master at REALM is handled by the >> is_host >> case. >> >LGTM. Committed to master. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jul 11 11:28:04 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Jul 2013 13:28:04 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0244 Integration testing framework In-Reply-To: <51DD82CE.3080001@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> <51C9883C.8030204@redhat.com> <51DD4DAD.7050408@redhat.com> <51DD82CE.3080001@redhat.com> Message-ID: <51DE96C4.8000401@redhat.com> On 10.7.2013 17:50, Petr Viktorin wrote: > On 07/10/2013 02:03 PM, Jan Cholasta wrote: >> make test seems to run fine with patches 230-242 applied, however >> ipa-run-tests produces the following output: >> > [...Skipping nose output...] >> >> >> I guess the location of the test certificate should be made configurable >> in order to fix the host and service plugin test failures. > > Making the existing test suite pass out of tree it's not a goal for this > patchset. There is a pending patch for the service cert. Better report it now than forget it later. > >> Also, there is a lot of debugging messages in ipa-run-tests output which >> wasn't there before IIRC, is that intentional? > > Yes, I believe that for the integration tests it's better to see what is > going on. Both for manual runs, and also this way the information is > more easily picked up by CI tools. It's harder to see what's going on with so much noise IMHO, I would prefer less verbose output for manual runs by default. > >> If $MASTER (and possible other host names) is not resolvable, >> ipa-test-config --global crashes: >> >> $ ipa-test-config --global >> Traceback (most recent call last): >> File "/usr/bin/ipa-test-config", line 104, in >> print main(sys.argv[1:]), >> File "/usr/bin/ipa-test-config", line 58, in main >> return config.env_to_script(get_object(conf, args).to_env(**kwargs)) >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", >> line 168, in to_env >> env['MASTER'] = default_domain.master.hostname >> File >> "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", >> line 282, in master >> return self.masters[0] >> IndexError: list index out of range > > Fixed. > Now, if the name is not resolvable, reading the config will fail. > Alternatively, the IP address can be given in variables such as > $BEAKERREPLICA1_IP_env1 (no, I didn't invent the name). This fixed ipa-test-config as advertised, but "ipa-run-tests test_integration/test_simple_replication.py" still fails. > >> Both the tests in test_simple_replication.py fail for me. I suspect it >> is because the data isn't replicated fast enough, a little delay between >> user-show and user-add might fix this. > > Hm, they worked for me. > I've added a delay. It seems fragile, I wonder what the proper way to > do this would be. Hmm, the "replica -> master" test still fails for me, even with delay increased to 20 s. Something less fragile than delay would certainly be nice. > > > I've made some other changes, mainly BeakerLib plugin output. > > Patch 240: Avoid infinite recursion that happened with some cases of bad > SSH credentials > Patch 241-243: Rework the BeakerLib plugin output to better match > traditional Beaker tests > Patch 244: Make it possible to explicitly specify IP addresses of hosts To sum things up, there are still some little bugs, but these can be fixed after the beta release, in general everything seems to work, so ACK. Honza -- Jan Cholasta From tbabej at redhat.com Thu Jul 11 11:37:07 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 13:37:07 +0200 Subject: [Freeipa-devel] [PATCH 0077] Add libsss_nss_idmap-devel to BuildRequires Message-ID: <4179475.AEnOnV7KJG@thinkpad7.brq.redhat.com> Hi, attached patch fixes build problems introduced by recently pushed Sumit's patches. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0077-Add-libsss_nss_idmap-devel-to-BuildRequires.patch Type: text/x-patch Size: 733 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 11 11:42:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 14:42:05 +0300 Subject: [Freeipa-devel] [PATCH 0077] Add libsss_nss_idmap-devel to BuildRequires In-Reply-To: <4179475.AEnOnV7KJG@thinkpad7.brq.redhat.com> References: <4179475.AEnOnV7KJG@thinkpad7.brq.redhat.com> Message-ID: <20130711114205.GQ18587@redhat.com> On Thu, 11 Jul 2013, Tomas Babej wrote: >Hi, > >attached patch fixes build problems introduced by recently pushed Sumit's patches. ACK, pushed to master. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jul 11 12:10:02 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Jul 2013 14:10:02 +0200 Subject: [Freeipa-devel] [PATCHES] 152-156 ipa-server-certinstall fixes Message-ID: <51DEA09A.7070909@redhat.com> Hi, this is the first batch of patches for . It contains port of ipa-server-certinstall to the admintool framework and fixes some bugs. Note that there's still some work I have to do to make ipa-server-certinstall work properly for installs with CA, currently it works reliably only on CA-less installs. This patchset also does not make it possible to change the CA certificate (as requested in the ticket). We discussed this with Rob and agreed that it should instead be done as part of . Unless there are any objections, that's what is going to happen. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-152-Make-PKCS-12-handling-in-ipa-server-certinstall-clos.patch Type: text/x-patch Size: 4000 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-153-Port-ipa-server-certinstall-to-the-admintool-framewo.patch Type: text/x-patch Size: 12007 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-154-Remove-unused-NSSDatabase-and-CertDB-method-find_roo.patch Type: text/x-patch Size: 2844 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-155-Use-correct-password-for-httpd-NSS-DB-in-ipa-server-.patch Type: text/x-patch Size: 2609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-156-Ignore-empty-mod-error-when-updating-DS-SSL-config-i.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jul 11 12:41:02 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Jul 2013 14:41:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130711093850.GF18587@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> Message-ID: <51DEA7DE.70205@redhat.com> On 07/11/2013 11:38 AM, Alexander Bokovoy wrote: > On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> Attached patches fix systemd and ipactl related bugs: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3730 >>>>> https://fedorahosted.org/freeipa/ticket/3729 >>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>> upgrade properly and everything else has failed afterwards. >>>> >>> >>> This was caused due to 'systemctl is-active' returning exit status 3 >>> ('activating'), and our code treating the non-zero exit status as a failure. I >>> handled this case in the updated patch. >>> >>> As for the ipa.service and dependency ordering, I have done some further >>> testing >>> and found out the adding the '--ignore-dependencies' switch alone solves the >>> shutdown issue. So I think that no modification of ipa.service file is >>> necessary. >>> >>> Updated patches are attached. >> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >> dogtag: > What's important is the fact that now I can issue reboot and VM > restarts, not hangs, and then IPA starts properly on boot -- this is > because when ns-slapd gets a signal from systemd, it automatically shuts > itself down properly and the same happens to dogtag. This is good > enough so that I push current patches to master but please proceed on > fixing 'ipactl stop' issue. > > Thanks for catching that. I am attaching a patch which should solve this issue. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0042-Use-ignore-dependencies-only-when-necessary.patch Type: text/x-patch Size: 1898 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jul 11 14:10:33 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Jul 2013 16:10:33 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <51C43E88.7000807@redhat.com> <1592475.0Os3DrEZJ8@thinkpad7.brq.redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> Message-ID: <51DEBCD9.6060909@redhat.com> On 07/11/2013 11:20 AM, Tomas Babej wrote: > boolean_var = {} > - for var in ('persistent_search', 'serial_autoincrement'): > + for var in ('serial_autoincrement'): This won't work - a one element tuple needs a comma at the end: ('serial_autoincrement', ) > boolean_var[var] = "yes" if getattr(self, var, False) else "no" > > self.sub_dict = dict(FQDN=self.fqdn, > @@ -607,9 +604,8 @@ class BindInstance(service.Service): > SUFFIX=self.suffix, > OPTIONAL_NTP=optional_ntp, > ZONEMGR=self.zonemgr, > - ZONE_REFRESH=self.zone_refresh, > IPA_CA_RECORD=ipa_ca, > - PERSISTENT_SEARCH=boolean_var['persistent_search'], > + PERSISTENT_SEARCH="yes", > SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) But anyway, I think this piece of code is unnecessarily complicated, I don't see a need for the 'boolean_var' dict here. I would suggest replacing it with something like: serial_autoincrement = "yes" if self.serial_autoincrement else "no" and then pass serial_autoincrement to self.sub_dict = dict(...) -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From abokovoy at redhat.com Thu Jul 11 15:02:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 18:02:49 +0300 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <51CC52B6.30908@redhat.com> References: <51C1683B.60308@redhat.com> <51C16C6D.5080700@redhat.com> <51CAD8AF.3090605@redhat.com> <51CC14B4.7020505@redhat.com> <51CC52B6.30908@redhat.com> Message-ID: <20130711150249.GR18587@redhat.com> On Thu, 27 Jun 2013, Martin Kosek wrote: >On 06/27/2013 12:32 PM, Jan Cholasta wrote: >> On 26.6.2013 14:03, Tomas Babej wrote: >>> On 06/19/2013 10:31 AM, Petr Vobornik wrote: >>>> On 06/19/2013 10:13 AM, Martin Kosek wrote: >>>>> Entitlements code was not tested nor supported upstream since >>>>> version 3.0. Remove the associated code. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3739 >>>>> >>>>> ---- >>>>> >>>>> As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and >>>>> master >>>>> branches. >>>>> >>>>> Martin >>>>> >>>> >>>> >>>> ACK on Web UI part. >>> >>> ACK on the IPA part >>> >>> Tomas >>> >> >> ipa-upgradeconfig fails for me when upgrading from version with entitlement >> plugin to version without entitlement plugin: >> >> 2013-06-26T22:22:43Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with >> options: {'debug': False, 'quiet': True} >> 2013-06-26T22:22:43Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2013-06-26T22:22:43Z DEBUG importing all plugin modules in >> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >> >> 2013-06-26T22:22:43Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py' >> 2013-06-26T22:22:43Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, >> in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-upgradeconfig", line 872, in main >> api.finalize() >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 674, in >> finalize >> self.__do_if_not_done('load_plugins') >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 454, in >> __do_if_not_done >> getattr(self, name)() >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 613, in >> load_plugins >> self.import_plugins('ipalib') >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 655, in >> import_plugins >> __import__(fullname) >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 180, >> in >> class entitle(LDAPObject): >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 184, >> in entitle >> container_dn = api.env.container_entitlements >> >> 2013-06-26T22:22:43Z DEBUG The ipa-upgradeconfig command failed, exception: >> AttributeError: 'Env' object has no attribute 'container_entitlements' >> >> Honza >> > >This happens because we run ipa-upgradeconfig in %post while there was still >entitlements plugin. I think that clean solution for this plugin (and also for >other future occurrences of this issue) is to run upgrade/server restart >process only in %posttrans. > >In the end, I iterated to the attached patch. With this spec change, I was able >to upgrade from FreeIPA 3.2 to current master version without any entitlements >related upgrade error. > >Adding Alexander and Rob to CC to double-check this upgrade-related change, I >want to be sure I didn't do something stupid. The patch needed rebase and it also had formatting errors. I've fixed the patch (attached) and tested it, all works. -- / Alexander Bokovoy -------------- next part -------------- >From b5e4b46a2a7c22de69cbd3841b7ce2625771018e Mon Sep 17 00:00:00 2001 From: Martin Kosek Date: Thu, 11 Jul 2013 17:35:26 +0300 Subject: [PATCH 2/2] Run server upgrade and restart in posttrans Running server upgrade or restart in %post or %postun may cause issues when there are still parts of old FreeIPA software (like entitlements plugin). https://fedorahosted.org/freeipa/ticket/3739 --- freeipa.spec.in | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index f2847e1..05b43bc 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -468,13 +468,22 @@ rm -rf %{buildroot} # END if [ $1 -gt 1 ] ; then /bin/systemctl condrestart certmonger.service 2>&1 || : - /usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : fi %posttrans server # This must be run in posttrans so that updates from previous # execution that may no longer be shipped are not applied. /usr/sbin/ipa-ldap-updater --upgrade --quiet >/dev/null || : +/usr/sbin/ipa-upgradeconfig --quiet >/dev/null || : + +# Restart IPA processes. This must be also run in postrans so that plugins +# and software is in consistent state +python -c "import sys; from ipaserver.install import installutils; sys.exit(0 if installutils.is_ipa_configured() else 1);" > /dev/null 2>&1 +# NOTE: systemd specific section +if [ $? -eq 0 ]; then + /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : +fi +# END %preun server if [ $1 = 0 ]; then @@ -484,14 +493,6 @@ if [ $1 = 0 ]; then # END fi -%postun server -if [ "$1" -ge "1" ]; then -# NOTE: systemd specific section - /bin/systemctl --quiet is-active ipa.service >/dev/null && \ - /bin/systemctl try-restart ipa.service >/dev/null 2>&1 || : -# END -fi - %pre server # Stop ipa_kpasswd if it exists before upgrading so we don't have a # zombie process when we're done. @@ -511,6 +512,8 @@ fi %post server-trust-ad %{_sbindir}/update-alternatives --install %{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so \ winbind_krb5_locator.so /dev/null 90 + +%posttrans server-trust-ad python -c "import sys; from ipaserver.install import installutils; sys.exit(0 if installutils.is_ipa_configured() else 1);" > /dev/null 2>&1 if [ $? -eq 0 ]; then # NOTE: systemd specific section @@ -816,6 +819,10 @@ fi %endif # ! %{ONLY_CLIENT} %changelog +* Thu Jul 11 2013 Martin Kosek - 3.2.99-5 +- Run ipa-upgradeconfig and server restart in posttrans to avoid inconsistency + issues when there are still old parts of software (like entitlements plugin) + * Wed Jul 10 2013 Ana Krivokapic - 3.2.99-4 - Bump minimum version of 389-ds-base to 1.3.1.3 for user password change fix. -- 1.8.3.1 From abokovoy at redhat.com Thu Jul 11 15:03:37 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Jul 2013 18:03:37 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <51DEA7DE.70205@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> <51DEA7DE.70205@redhat.com> Message-ID: <20130711150337.GS18587@redhat.com> On Thu, 11 Jul 2013, Ana Krivokapic wrote: >On 07/11/2013 11:38 AM, Alexander Bokovoy wrote: >> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >>> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> Attached patches fix systemd and ipactl related bugs: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3730 >>>>>> https://fedorahosted.org/freeipa/ticket/3729 >>>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>>> upgrade properly and everything else has failed afterwards. >>>>> >>>> >>>> This was caused due to 'systemctl is-active' returning exit status 3 >>>> ('activating'), and our code treating the non-zero exit status as a failure. I >>>> handled this case in the updated patch. >>>> >>>> As for the ipa.service and dependency ordering, I have done some further >>>> testing >>>> and found out the adding the '--ignore-dependencies' switch alone solves the >>>> shutdown issue. So I think that no modification of ipa.service file is >>>> necessary. >>>> >>>> Updated patches are attached. >>> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >>> dogtag: >> What's important is the fact that now I can issue reboot and VM >> restarts, not hangs, and then IPA starts properly on boot -- this is >> because when ns-slapd gets a signal from systemd, it automatically shuts >> itself down properly and the same happens to dogtag. This is good >> enough so that I push current patches to master but please proceed on >> fixing 'ipactl stop' issue. >> >> > >Thanks for catching that. I am attaching a patch which should solve this issue. Works now, I tried stop/start/restart, all processes were properly addressed. Thanks! -- / Alexander Bokovoy From tbabej at redhat.com Thu Jul 11 15:10:58 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Jul 2013 17:10:58 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51DEBCD9.6060909@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> Message-ID: <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: > On 07/11/2013 11:20 AM, Tomas Babej wrote: > > boolean_var = {} > > - for var in ('persistent_search', 'serial_autoincrement'): > > + for var in ('serial_autoincrement'): > This won't work - a one element tuple needs a comma at the end: > ('serial_autoincrement', ) > > boolean_var[var] = "yes" if getattr(self, var, False) else "no" > > > > self.sub_dict = dict(FQDN=self.fqdn, > > @@ -607,9 +604,8 @@ class BindInstance(service.Service): > > SUFFIX=self.suffix, > > OPTIONAL_NTP=optional_ntp, > > ZONEMGR=self.zonemgr, > > - ZONE_REFRESH=self.zone_refresh, > > IPA_CA_RECORD=ipa_ca, > > - PERSISTENT_SEARCH=boolean_var['persistent_search'], > > + PERSISTENT_SEARCH="yes", > > SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) > > But anyway, I think this piece of code is unnecessarily complicated, I don't see > a need for the 'boolean_var' dict here. I would suggest replacing it with > something like: > > serial_autoincrement = "yes" if self.serial_autoincrement else "no" > > and then pass serial_autoincrement to self.sub_dict = dict(...) > > Attached patch refactored the relevant part of the code. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-3-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 12947 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jul 11 16:18:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Jul 2013 18:18:53 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> Message-ID: <51DEDAED.8020707@redhat.com> On 07/11/2013 05:10 PM, Tomas Babej wrote: > > On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: > > > On 07/11/2013 11:20 AM, Tomas Babej wrote: > > > > boolean_var = {} > > > > - for var in ('persistent_search', 'serial_autoincrement'): > > > > + for var in ('serial_autoincrement'): > > > This won't work - a one element tuple needs a comma at the end: > > > ('serial_autoincrement', ) > > > > boolean_var[var] = "yes" if getattr(self, var, False) else "no" > > > > > > > > self.sub_dict = dict(FQDN=self.fqdn, > > > > @@ -607,9 +604,8 @@ class BindInstance(service.Service): > > > > SUFFIX=self.suffix, > > > > OPTIONAL_NTP=optional_ntp, > > > > ZONEMGR=self.zonemgr, > > > > - ZONE_REFRESH=self.zone_refresh, > > > > IPA_CA_RECORD=ipa_ca, > > > > - PERSISTENT_SEARCH=boolean_var['persistent_search'], > > > > + PERSISTENT_SEARCH="yes", > > > > SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) > > > > > > But anyway, I think this piece of code is unnecessarily complicated, I don't see > > > a need for the 'boolean_var' dict here. I would suggest replacing it with > > > something like: > > > > > > serial_autoincrement = "yes" if self.serial_autoincrement else "no" > > > > > > and then pass serial_autoincrement to self.sub_dict = dict(...) > > > > > > > > > > Attached patch refactored the relevant part of the code. > > > > Tomas > ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.hogarth at gmail.com Thu Jul 11 16:21:55 2013 From: james.hogarth at gmail.com (James Hogarth) Date: Thu, 11 Jul 2013 17:21:55 +0100 Subject: [Freeipa-devel] [PATCH] 3031 Allow TTL to be configured during ipa-client-install Message-ID: Hi, SSSD 1.10 added the ability to configure the TTL used in dynamic DNS updates. This patch is the mirror of that rebased from the original patch submitted a year ago onto current head. This patch allows the user during ipa-client-install to pick the TTL to be used on the creation of the client DNS records and configures the value in sssd.conf so that ongoing changes to IP use the TTL as desired. Cheers, James -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Allow-TTL-to-be-configured-during-ipa-client-install.patch Type: application/octet-stream Size: 5078 bytes Desc: not available URL: From rcritten at redhat.com Thu Jul 11 18:51:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jul 2013 14:51:50 -0400 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively In-Reply-To: <51DC02C3.8040507@redhat.com> References: <51DC02C3.8040507@redhat.com> Message-ID: <51DEFEC6.3040006@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Also added a small patch to fix a formatting issue with > installutils.read_password. > > Honza Functionally ok but I found it very jarring the way the passwords were prompted for. I think they should be moved after the realm question and the text should be more than just the path to the filename. rob From rcritten at redhat.com Thu Jul 11 20:50:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Jul 2013 16:50:36 -0400 Subject: [Freeipa-devel] [PATCH] 1102 set correct content-type Message-ID: <51DF1A9C.8000604@redhat.com> Set the correct content-type on negotiated XML-RPC requests. It was being set as text/plain when it should be text/xml. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1102-contenttype.patch Type: text/x-patch Size: 1815 bytes Desc: not available URL: From jcholast at redhat.com Fri Jul 12 06:04:56 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Jul 2013 08:04:56 +0200 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively In-Reply-To: <51DEFEC6.3040006@redhat.com> References: <51DC02C3.8040507@redhat.com> <51DEFEC6.3040006@redhat.com> Message-ID: <51DF9C88.8050401@redhat.com> On 11.7.2013 20:51, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Also added a small patch to fix a formatting issue with >> installutils.read_password. >> >> Honza > > Functionally ok but I found it very jarring the way the passwords were > prompted for. I think they should be moved after the realm question and > the text should be more than just the path to the filename. > > rob > Moved the prompt and changed the text to "Enter unlock password". Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-149.1-Ask-for-PKCS-12-password-interactively-in-ipa-server.patch Type: text/x-patch Size: 5343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-150.1-Ask-for-PKCS-12-password-interactively-in-ipa-replic.patch Type: text/x-patch Size: 3901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-151.1-Print-newline-after-receiving-EOF-in-installutils.re.patch Type: text/x-patch Size: 8163 bytes Desc: not available URL: From thozza at redhat.com Fri Jul 12 08:18:19 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 12 Jul 2013 10:18:19 +0200 Subject: [Freeipa-devel] [PATCH 0173] Improve logging for cases where SOA serial autoincrementation failed In-Reply-To: <51DE87FB.50308@redhat.com> References: <51DE87FB.50308@redhat.com> Message-ID: <51DFBBCB.7050808@redhat.com> On 07/11/2013 12:24 PM, Petr Spacek wrote: > Hello, > > Improve logging for cases where SOA serial autoincrementation failed. > ACK Regards, Tomas Hozza From tbabej at redhat.com Fri Jul 12 08:19:09 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 12 Jul 2013 10:19:09 +0200 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively In-Reply-To: <51DF9C88.8050401@redhat.com> References: <51DC02C3.8040507@redhat.com> <51DEFEC6.3040006@redhat.com> <51DF9C88.8050401@redhat.com> Message-ID: <38174590.7AT5dsIgTR@thinkpad7.brq.redhat.com> > > > > Functionally ok but I found it very jarring the way the passwords were > > prompted for. I think they should be moved after the realm question and > > the text should be more than just the path to the filename. > > > > rob > > > > Moved the prompt and changed the text to "Enter unlock password". > > Updated patches attached. > > Honza Just a nitpick: + # If any of the PKCS#12 options are selected, all are required. + pkcs12_req = (options.dirsrv_pkcs12, options.http_pkcs12) + pkcs12_opt = (options.pkinit_pkcs12,) + if any(pkcs12_req + pkcs12_opt) and not all(pkcs12_req): parser.error("All PKCS#12 options are required if any are used.") This error message is somewhat misleading, since --pkinit-pkcs12 options is not required. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Jul 12 14:44:07 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jul 2013 10:44:07 -0400 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers Message-ID: <51E01637.9040102@redhat.com> Add the Camellia ciphers to the supported list in the KDC. Also exclude some attributes from being displayed in LDAP updater logs. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1103-camellia.patch Type: text/x-patch Size: 11672 bytes Desc: not available URL: From akrivoka at redhat.com Fri Jul 12 15:18:05 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Jul 2013 17:18:05 +0200 Subject: [Freeipa-devel] [PATCH] 0043 Fix internal error in idrange-add Message-ID: <51E01E2D.3050507@redhat.com> Hello, This patch fixes https://fedorahosted.org/freeipa/ticket/3781 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0043-Fix-internal-error-in-idrange-add.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jul 12 15:31:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Jul 2013 18:31:27 +0300 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers In-Reply-To: <51E01637.9040102@redhat.com> References: <51E01637.9040102@redhat.com> Message-ID: <20130712153127.GW18587@redhat.com> On Fri, 12 Jul 2013, Rob Crittenden wrote: > Add the Camellia ciphers to the supported list in the KDC. > > Also exclude some attributes from being displayed in LDAP updater logs. ACK if you split the patches into separate for logging and adding Camelia cyphers, for maintenance purposes (easier to cherry-pick). Thanks! -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jul 12 15:32:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Jul 2013 18:32:38 +0300 Subject: [Freeipa-devel] [PATCH] 0043 Fix internal error in idrange-add In-Reply-To: <51E01E2D.3050507@redhat.com> References: <51E01E2D.3050507@redhat.com> Message-ID: <20130712153238.GX18587@redhat.com> On Fri, 12 Jul 2013, Ana Krivokapic wrote: >Hello, > >This patch fixes https://fedorahosted.org/freeipa/ticket/3781 ACK. -- / Alexander Bokovoy From rcritten at redhat.com Fri Jul 12 15:32:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Jul 2013 11:32:47 -0400 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers In-Reply-To: <51E01637.9040102@redhat.com> References: <51E01637.9040102@redhat.com> Message-ID: <51E0219F.8030604@redhat.com> Rob Crittenden wrote: > Add the Camellia ciphers to the supported list in the KDC. > > Also exclude some attributes from being displayed in LDAP updater logs. > > rob I've split the Camellia patch out from the updater patch to clarify things. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1103-2-camellia.patch Type: text/x-patch Size: 2275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1104-updater.patch Type: text/x-patch Size: 9687 bytes Desc: not available URL: From jcholast at redhat.com Mon Jul 15 08:16:47 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Jul 2013 10:16:47 +0200 Subject: [Freeipa-devel] [PATCHES] 152-158 ipa-server-certinstall fixes In-Reply-To: <51DEA09A.7070909@redhat.com> References: <51DEA09A.7070909@redhat.com> Message-ID: <51E3AFEF.5000508@redhat.com> On 11.7.2013 14:10, Jan Cholasta wrote: > Hi, > > this is the first batch of patches for > . It contains port of > ipa-server-certinstall to the admintool framework and fixes some bugs. > > Note that there's still some work I have to do to make > ipa-server-certinstall work properly for installs with CA, currently it > works reliably only on CA-less installs. > > This patchset also does not make it possible to change the CA > certificate (as requested in the ticket). We discussed this with Rob and > agreed that it should instead be done as part of > . Unless there are any > objections, that's what is going to happen. Added patches (157 and 158) to support installs with CA. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-157-Replace-only-the-cert-instead-of-the-whole-NSS-DB-in.patch Type: text/x-patch Size: 4151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-158-Untrack-old-and-track-new-cert-with-certmonger-in-ip.patch Type: text/x-patch Size: 2719 bytes Desc: not available URL: From james.hogarth at gmail.com Mon Jul 15 08:21:23 2013 From: james.hogarth at gmail.com (James Hogarth) Date: Mon, 15 Jul 2013 09:21:23 +0100 Subject: [Freeipa-devel] [PATCH] 3031 Allow TTL to be configured during ipa-client-install In-Reply-To: References: Message-ID: > > > > This patch allows the user during ipa-client-install to pick the TTL to be > used on the creation of the client DNS records and configures the value in > sssd.conf so that ongoing changes to IP use the TTL as desired. > Apologies but I just realised I missed the link to the ticket this refers to... so just to be clear it's for this one: https://fedorahosted.org/freeipa/ticket/3031 Cheers, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Jul 15 08:44:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Jul 2013 10:44:58 +0200 Subject: [Freeipa-devel] [PATCH] 1102 set correct content-type In-Reply-To: <51DF1A9C.8000604@redhat.com> References: <51DF1A9C.8000604@redhat.com> Message-ID: <51E3B68A.8010908@redhat.com> On 11.7.2013 22:50, Rob Crittenden wrote: > Set the correct content-type on negotiated XML-RPC requests. It was > being set as text/plain when it should be text/xml. > > rob > ACK. Honza -- Jan Cholasta From jcholast at redhat.com Mon Jul 15 08:57:37 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Jul 2013 10:57:37 +0200 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively In-Reply-To: <38174590.7AT5dsIgTR@thinkpad7.brq.redhat.com> References: <51DC02C3.8040507@redhat.com> <51DEFEC6.3040006@redhat.com> <51DF9C88.8050401@redhat.com> <38174590.7AT5dsIgTR@thinkpad7.brq.redhat.com> Message-ID: <51E3B981.3010207@redhat.com> On 12.7.2013 10:19, Tomas Babej wrote: > Just a nitpick: > > + # If any of the PKCS#12 options are selected, all are required. > > + pkcs12_req = (options.dirsrv_pkcs12, options.http_pkcs12) > > + pkcs12_opt = (options.pkinit_pkcs12,) > > + if any(pkcs12_req + pkcs12_opt) and not all(pkcs12_req): > > parser.error("All PKCS#12 options are required if any are used.") > > This error message is somewhat misleading, since --pkinit-pkcs12 options > is not required. Fixed. Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-149.2-Ask-for-PKCS-12-password-interactively-in-ipa-server.patch Type: text/x-patch Size: 5402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-150.2-Ask-for-PKCS-12-password-interactively-in-ipa-replic.patch Type: text/x-patch Size: 4093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-151.2-Print-newline-after-receiving-EOF-in-installutils.re.patch Type: text/x-patch Size: 8163 bytes Desc: not available URL: From tbabej at redhat.com Mon Jul 15 10:27:34 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Jul 2013 12:27:34 +0200 Subject: [Freeipa-devel] [PATCH] Remove unused variable In-Reply-To: <20130710202716.GM6481@hendrix.brq.redhat.com> References: <20130710202716.GM6481@hendrix.brq.redhat.com> Message-ID: <2417093.uJyCuro3ui@thinkpad7.brq.redhat.com> On Wednesday 10 of July 2013 22:27:16 Jakub Hrozek wrote: > Hi, > > I was doing quite a few builds of freeipa for testing and patch reviews > lately and found a couple of unused variables. The attached patch > removed the variables. ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Jul 15 12:58:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 14:58:47 +0200 Subject: [Freeipa-devel] [PATCH] Use pkg-config to detect cmocka In-Reply-To: <20130704114935.GD26182@mail.corp.redhat.com> References: <20130704094906.GB26182@mail.corp.redhat.com> <20130704101054.GA3956@redhat.com> <20130704114935.GD26182@mail.corp.redhat.com> Message-ID: <51E3F207.309@redhat.com> On 07/04/2013 01:49 PM, Lukas Slebodnik wrote: > On (04/07/13 13:10), Alexander Bokovoy wrote: >> On Thu, 04 Jul 2013, Lukas Slebodnik wrote: >>> ehlo, >>> >>> libcmocka-0.3 was released and package is available in fedore >= 18. >>> libcmocka-devel contains pkg-config file, >>> therefore it is better to use pkg-config to detect this library. >>> >>> Patch is attached. >> Few comments. >> >> 0. Please follow https://fedorahosted.org/freeipa/wiki/PatchFormat > changed > >> 1. It would be nice to have a ticket in the FreeIPA trac. > Could ticket#3434 be used? I know that ticket is fixed. > https://fedorahosted.org/freeipa/ticket/3434 > Funcionality of patch is the same as Sumit's version. > >> 2. I think at this point we need to decide whether we want to have >> BuildRequires: libcmocka-devel >> in freeipa.spec.in. Given the change, older version would become >> unsupported but we don't really have any packaging dependency yet. > At the moment, there isnot any cmocka test in freeipa source repo. > > LS > Any update with this patch? If the build works OK, I would push it. I think we do not need to add libcmocka BuildRequires ATM and leave the cmocka tests optional (especially if there is no cmocka test). Martin From akrivoka at redhat.com Mon Jul 15 13:07:07 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Jul 2013 15:07:07 +0200 Subject: [Freeipa-devel] [PATCH] 0044 Add 'ipa_server_mode' option to SSSD configuration Message-ID: <51E3F3FB.5060600@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0044-Add-ipa_server_mode-option-to-SSSD-configuration.patch Type: text/x-patch Size: 3807 bytes Desc: not available URL: From mkosek at redhat.com Mon Jul 15 13:08:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:08:56 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <24977773.5fSg6SGopZ@thinkpad7.brq.redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C841AC.1050604@redhat.com> <51CAA280.9090900@redhat.com> <24977773.5fSg6SGopZ@thinkpad7.brq.redhat.com> Message-ID: <51E3F468.5050709@redhat.com> On 07/11/2013 08:59 AM, Tomas Babej wrote: > On Wednesday 26 of June 2013 10:12:48 Petr Spacek wrote: > > > > [snip] > > > >> > >> Appropriate error handling = Return 'Permission denied' if particular > >> operation requires higher privileges. > >> > >> IMHO 'cryptic' error message is bad in any case, so the right way how to fix > >> 'cryptic' error messages is to fix the places where errors are thrown. > >> > >> I don't think that additional checks in 'advisor' to hide 'cryptic' errors are > >> the right approach. > >> > >> -- > >> Petr^2 Spacek > > > > To wrap-up, after an offline discussion Petr: > > > > We came to an conclusion that since 'require_root' attribute is optional (Petr > was not aware of that, and that fact was what caused his concern), with default > value False, the attribute should not pose any additional burden for > > the plugin developer. > > > > Tomas > Agreed, I think that current approach is fine. Alexander, are you OK with the ipa-advise tool as is? We can add more bells and whistles or options/API for plugins when we have actually more ipa-advise plugins and see the real needs of such plugins. Martin From pspacek at redhat.com Mon Jul 15 13:13:29 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Jul 2013 15:13:29 +0200 Subject: [Freeipa-devel] [PATCH 0174] Fix crash during zone_refresh triggered by connection failure Message-ID: <51E3F579.2010908@redhat.com> Hello, Fix crash during zone_refresh triggered by connection failure. Variable 'iter' was initialized too late. Code in cleanup section of refresh_zones_from_ldap() dereferenced the uninitialized variable. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0174-Fix-crash-during-zone_refresh-triggered-by-connectio.patch Type: text/x-patch Size: 1405 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 15 13:13:53 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Jul 2013 16:13:53 +0300 Subject: [Freeipa-devel] [PATCH] Use pkg-config to detect cmocka In-Reply-To: <51E3F207.309@redhat.com> References: <20130704094906.GB26182@mail.corp.redhat.com> <20130704101054.GA3956@redhat.com> <20130704114935.GD26182@mail.corp.redhat.com> <51E3F207.309@redhat.com> Message-ID: <20130715131353.GA18587@redhat.com> On Mon, 15 Jul 2013, Martin Kosek wrote: >On 07/04/2013 01:49 PM, Lukas Slebodnik wrote: >> On (04/07/13 13:10), Alexander Bokovoy wrote: >>> On Thu, 04 Jul 2013, Lukas Slebodnik wrote: >>>> ehlo, >>>> >>>> libcmocka-0.3 was released and package is available in fedore >= 18. >>>> libcmocka-devel contains pkg-config file, >>>> therefore it is better to use pkg-config to detect this library. >>>> >>>> Patch is attached. >>> Few comments. >>> >>> 0. Please follow https://fedorahosted.org/freeipa/wiki/PatchFormat >> changed >> >>> 1. It would be nice to have a ticket in the FreeIPA trac. >> Could ticket#3434 be used? I know that ticket is fixed. >> https://fedorahosted.org/freeipa/ticket/3434 >> Funcionality of patch is the same as Sumit's version. >> >>> 2. I think at this point we need to decide whether we want to have >>> BuildRequires: libcmocka-devel >>> in freeipa.spec.in. Given the change, older version would become >>> unsupported but we don't really have any packaging dependency yet. >> At the moment, there isnot any cmocka test in freeipa source repo. >> >> LS >> > >Any update with this patch? If the build works OK, I would push it. > >I think we do not need to add libcmocka BuildRequires ATM and leave the cmocka >tests optional (especially if there is no cmocka test). Yes, it works fine. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 15 13:15:19 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Jul 2013 16:15:19 +0300 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51E3F468.5050709@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C841AC.1050604@redhat.com> <51CAA280.9090900@redhat.com> <24977773.5fSg6SGopZ@thinkpad7.brq.redhat.com> <51E3F468.5050709@redhat.com> Message-ID: <20130715131519.GB18587@redhat.com> On Mon, 15 Jul 2013, Martin Kosek wrote: >On 07/11/2013 08:59 AM, Tomas Babej wrote: >> On Wednesday 26 of June 2013 10:12:48 Petr Spacek wrote: >> >> >> >> [snip] >> >> >> >>> >> >>> Appropriate error handling = Return 'Permission denied' if particular >> >>> operation requires higher privileges. >> >>> >> >>> IMHO 'cryptic' error message is bad in any case, so the right way how to fix >> >>> 'cryptic' error messages is to fix the places where errors are thrown. >> >>> >> >>> I don't think that additional checks in 'advisor' to hide 'cryptic' errors are >> >>> the right approach. >> >>> >> >>> -- >> >>> Petr^2 Spacek >> >> >> >> To wrap-up, after an offline discussion Petr: >> >> >> >> We came to an conclusion that since 'require_root' attribute is optional (Petr >> was not aware of that, and that fact was what caused his concern), with default >> value False, the attribute should not pose any additional burden for >> >> the plugin developer. >> >> >> >> Tomas >> > >Agreed, I think that current approach is fine. > >Alexander, are you OK with the ipa-advise tool as is? We can add more bells and >whistles or options/API for plugins when we have actually more ipa-advise >plugins and see the real needs of such plugins. Yes, I'm OK. -- / Alexander Bokovoy From mkosek at redhat.com Mon Jul 15 13:16:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:16:51 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <20130711101552.GI18587@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> Message-ID: <51E3F643.1080909@redhat.com> On 07/11/2013 12:15 PM, Alexander Bokovoy wrote: > On Thu, 11 Jul 2013, Jan Cholasta wrote: >> On 11.7.2013 11:58, Alexander Bokovoy wrote: >>> On Mon, 08 Jul 2013, Alexander Bokovoy wrote: >>>> On Thu, 27 Jun 2013, Jan Cholasta wrote: >>>>> On 27.6.2013 17:34, Rich Megginson wrote: >>>>>> On 06/27/2013 09:31 AM, Jan Cholasta wrote: >>>>>>> The search is hard-coded in the referint plugin, see >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Not sure if it makes sense to do a wildcard/substr search here - please >>>>>> file a ticket with 389 to investigate. >>>>> >>>>> https://fedorahosted.org/389/ticket/47411 >>>> So, should we merge this patchset or wait until 389-ds analyzes 47411? >>>> To me it looks like we can use this one as an interim solution, once Web >>>> UI performance is checked through. >>> I've commited the patchset to master. Web UI works just fine for me and >>> with a VM limited to 1GB RAM I seem to get snappier response even when >>> running whole IPA stack and Firefox in the same VM. >>> >> >> We can add WebUI improvements later. I have some WIP, but I need to discuss >> it with Petr first (he's away this week). > Ok. > > The patchset is in ipa-3-2 as well now. Just checking: 1) Jan, did you check size of these new indexes on IPA master with such a high number of users? How big are they? I want to make sure that this won't create an issue on upgrades to new 3.2.x. 2) Does the patch set also fix the problem for Web UI? Currently, I think it will still grab and process all member attributes even though it does not need it. If the Web UI performance is still not sharp, I would rather leave this ticket opened and let Jan&Petr cooperate on the Web UI part. Martin From mkosek at redhat.com Mon Jul 15 13:24:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:24:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130711150337.GS18587@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> <51DEA7DE.70205@redhat.com> <20130711150337.GS18587@redhat.com> Message-ID: <51E3F81D.2090407@redhat.com> On 07/11/2013 05:03 PM, Alexander Bokovoy wrote: > On Thu, 11 Jul 2013, Ana Krivokapic wrote: >> On 07/11/2013 11:38 AM, Alexander Bokovoy wrote: >>> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >>>> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>>>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Attached patches fix systemd and ipactl related bugs: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3730 >>>>>>> https://fedorahosted.org/freeipa/ticket/3729 >>>>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>>>> upgrade properly and everything else has failed afterwards. >>>>>> >>>>> >>>>> This was caused due to 'systemctl is-active' returning exit status 3 >>>>> ('activating'), and our code treating the non-zero exit status as a >>>>> failure. I >>>>> handled this case in the updated patch. >>>>> >>>>> As for the ipa.service and dependency ordering, I have done some further >>>>> testing >>>>> and found out the adding the '--ignore-dependencies' switch alone solves the >>>>> shutdown issue. So I think that no modification of ipa.service file is >>>>> necessary. >>>>> >>>>> Updated patches are attached. >>>> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >>>> dogtag: >>> What's important is the fact that now I can issue reboot and VM >>> restarts, not hangs, and then IPA starts properly on boot -- this is >>> because when ns-slapd gets a signal from systemd, it automatically shuts >>> itself down properly and the same happens to dogtag. This is good >>> enough so that I push current patches to master but please proceed on >>> fixing 'ipactl stop' issue. >>> >>> >> >> Thanks for catching that. I am attaching a patch which should solve this issue. > Works now, I tried stop/start/restart, all processes were properly addressed. > > Thanks! > Is that an ACK? If yes, please push the patches :-) Martin From abokovoy at redhat.com Mon Jul 15 13:27:51 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Jul 2013 16:27:51 +0300 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <51E3F81D.2090407@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> <51DEA7DE.70205@redhat.com> <20130711150337.GS18587@redhat.com> <51E3F81D.2090407@redhat.com> Message-ID: <20130715132751.GC18587@redhat.com> On Mon, 15 Jul 2013, Martin Kosek wrote: >On 07/11/2013 05:03 PM, Alexander Bokovoy wrote: >> On Thu, 11 Jul 2013, Ana Krivokapic wrote: >>> On 07/11/2013 11:38 AM, Alexander Bokovoy wrote: >>>> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >>>>> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>>>>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>>>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Attached patches fix systemd and ipactl related bugs: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3730 >>>>>>>> https://fedorahosted.org/freeipa/ticket/3729 >>>>>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>>>>> upgrade properly and everything else has failed afterwards. >>>>>>> >>>>>> >>>>>> This was caused due to 'systemctl is-active' returning exit status 3 >>>>>> ('activating'), and our code treating the non-zero exit status as a >>>>>> failure. I >>>>>> handled this case in the updated patch. >>>>>> >>>>>> As for the ipa.service and dependency ordering, I have done some further >>>>>> testing >>>>>> and found out the adding the '--ignore-dependencies' switch alone solves the >>>>>> shutdown issue. So I think that no modification of ipa.service file is >>>>>> necessary. >>>>>> >>>>>> Updated patches are attached. >>>>> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >>>>> dogtag: >>>> What's important is the fact that now I can issue reboot and VM >>>> restarts, not hangs, and then IPA starts properly on boot -- this is >>>> because when ns-slapd gets a signal from systemd, it automatically shuts >>>> itself down properly and the same happens to dogtag. This is good >>>> enough so that I push current patches to master but please proceed on >>>> fixing 'ipactl stop' issue. >>>> >>>> >>> >>> Thanks for catching that. I am attaching a patch which should solve this issue. >> Works now, I tried stop/start/restart, all processes were properly addressed. >> >> Thanks! >> > >Is that an ACK? If yes, please push the patches :-) It is already in master, I only forgot to respond on the list: af7807aacc6cf1beb25e53483b54bd599bd6421d -- / Alexander Bokovoy From mkosek at redhat.com Mon Jul 15 13:31:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:31:29 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> Message-ID: <51E3F9B1.3000401@redhat.com> On 07/11/2013 05:10 PM, Tomas Babej wrote: > On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: > >> On 07/11/2013 11:20 AM, Tomas Babej wrote: > >> > boolean_var = {} > >> > - for var in ('persistent_search', 'serial_autoincrement'): > >> > + for var in ('serial_autoincrement'): > >> This won't work - a one element tuple needs a comma at the end: > >> ('serial_autoincrement', ) > >> > boolean_var[var] = "yes" if getattr(self, var, False) else "no" > >> > > >> > self.sub_dict = dict(FQDN=self.fqdn, > >> > @@ -607,9 +604,8 @@ class BindInstance(service.Service): > >> > SUFFIX=self.suffix, > >> > OPTIONAL_NTP=optional_ntp, > >> > ZONEMGR=self.zonemgr, > >> > - ZONE_REFRESH=self.zone_refresh, > >> > IPA_CA_RECORD=ipa_ca, > >> > - PERSISTENT_SEARCH=boolean_var['persistent_search'], > >> > + PERSISTENT_SEARCH="yes", > >> > SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) > >> > >> But anyway, I think this piece of code is unnecessarily complicated, I don't see > >> a need for the 'boolean_var' dict here. I would suggest replacing it with > >> something like: > >> > >> serial_autoincrement = "yes" if self.serial_autoincrement else "no" > >> > >> and then pass serial_autoincrement to self.sub_dict = dict(...) > >> > >> > > > > Attached patch refactored the relevant part of the code. > > > > Tomas > Thanks for patches! I am just thinking, should we also hide the respective option from ipa global DNS configuration? That's idnszonerefresh attribute. We may want to mark the attribute as invisible in CLI + remove it from Web UI. Petr - what is your take on this? Do you plan to remove idnszonerefresh attribute support in the future (Fedora 20) as persistent search will be mandatory in that time? Thanks, Martin From mkosek at redhat.com Mon Jul 15 13:38:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:38:17 +0200 Subject: [Freeipa-devel] [PATCH] 1102 set correct content-type In-Reply-To: <51E3B68A.8010908@redhat.com> References: <51DF1A9C.8000604@redhat.com> <51E3B68A.8010908@redhat.com> Message-ID: <51E3FB49.8060107@redhat.com> On 07/15/2013 10:44 AM, Jan Cholasta wrote: > On 11.7.2013 22:50, Rob Crittenden wrote: >> Set the correct content-type on negotiated XML-RPC requests. It was >> being set as text/plain when it should be text/xml. >> >> rob >> > > ACK. > > Honza > Pushed to master, ipa-3-2. Martin From mkosek at redhat.com Mon Jul 15 13:41:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:41:29 +0200 Subject: [Freeipa-devel] [PATCH] Remove unused variable In-Reply-To: <2417093.uJyCuro3ui@thinkpad7.brq.redhat.com> References: <20130710202716.GM6481@hendrix.brq.redhat.com> <2417093.uJyCuro3ui@thinkpad7.brq.redhat.com> Message-ID: <51E3FC09.7050506@redhat.com> On 07/15/2013 12:27 PM, Tomas Babej wrote: > On Wednesday 10 of July 2013 22:27:16 Jakub Hrozek wrote: > >> Hi, > >> > >> I was doing quite a few builds of freeipa for testing and patch reviews > >> lately and found a couple of unused variables. The attached patch > >> removed the variables. > > > > ACK > > > > Tomas > Pushed to master. Martin From jcholast at redhat.com Mon Jul 15 13:43:32 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Jul 2013 15:43:32 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E3F643.1080909@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> Message-ID: <51E3FC84.7050407@redhat.com> On 15.7.2013 15:16, Martin Kosek wrote: > On 07/11/2013 12:15 PM, Alexander Bokovoy wrote: >> On Thu, 11 Jul 2013, Jan Cholasta wrote: >>> We can add WebUI improvements later. I have some WIP, but I need to discuss >>> it with Petr first (he's away this week). >> Ok. >> >> The patchset is in ipa-3-2 as well now. > > Just checking: > > 1) Jan, did you check size of these new indexes on IPA master with such a high > number of users? How big are they? I want to make sure that this won't create > an issue on upgrades to new 3.2.x. With 10k users, the indices ate roughly 250 MB of disk space. > > 2) Does the patch set also fix the problem for Web UI? Currently, I think it > will still grab and process all member attributes even though it does not need > it. If the Web UI performance is still not sharp, I would rather leave this > ticket opened and let Jan&Petr cooperate on the Web UI part. I agree on keeping the ticket open. Honza -- Jan Cholasta From pspacek at redhat.com Mon Jul 15 13:44:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Jul 2013 15:44:13 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E3F9B1.3000401@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> Message-ID: <51E3FCAD.8050502@redhat.com> On 15.7.2013 15:31, Martin Kosek wrote: > On 07/11/2013 05:10 PM, Tomas Babej wrote: >> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >> >>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >> >>>> boolean_var = {} >> >>>> - for var in ('persistent_search', 'serial_autoincrement'): >> >>>> + for var in ('serial_autoincrement'): >> >>> This won't work - a one element tuple needs a comma at the end: >> >>> ('serial_autoincrement', ) >> >>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >> >>>> >> >>>> self.sub_dict = dict(FQDN=self.fqdn, >> >>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >> >>>> SUFFIX=self.suffix, >> >>>> OPTIONAL_NTP=optional_ntp, >> >>>> ZONEMGR=self.zonemgr, >> >>>> - ZONE_REFRESH=self.zone_refresh, >> >>>> IPA_CA_RECORD=ipa_ca, >> >>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >> >>>> + PERSISTENT_SEARCH="yes", >> >>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >> >>> >> >>> But anyway, I think this piece of code is unnecessarily complicated, I don't see >> >>> a need for the 'boolean_var' dict here. I would suggest replacing it with >> >>> something like: >> >>> >> >>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >> >>> >> >>> and then pass serial_autoincrement to self.sub_dict = dict(...) >> >>> >> >>> >> >> >> >> Attached patch refactored the relevant part of the code. >> >> >> >> Tomas >> > > Thanks for patches! I am just thinking, should we also hide the respective > option from ipa global DNS configuration? That's idnszonerefresh attribute. > > We may want to mark the attribute as invisible in CLI + remove it from Web UI. > Petr - what is your take on this? Do you plan to remove idnszonerefresh > attribute support in the future (Fedora 20) as persistent search will be > mandatory in that time? Yes, you are right. We completely forgot to web UI. And yes - please remove the option from web UI. The latest development shows that persistent search will be replaced by RFC 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. All options related to persistent search and zone_refresh will simply disappear. Syncrepl itself doesn't require explicit configuration. -- Petr^2 Spacek From mkosek at redhat.com Mon Jul 15 13:57:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 15:57:16 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E3FCAD.8050502@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> Message-ID: <51E3FFBC.8000809@redhat.com> On 07/15/2013 03:44 PM, Petr Spacek wrote: > On 15.7.2013 15:31, Martin Kosek wrote: >> On 07/11/2013 05:10 PM, Tomas Babej wrote: >>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >>> >>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >>> >>>>> boolean_var = {} >>> >>>>> - for var in ('persistent_search', 'serial_autoincrement'): >>> >>>>> + for var in ('serial_autoincrement'): >>> >>>> This won't work - a one element tuple needs a comma at the end: >>> >>>> ('serial_autoincrement', ) >>> >>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >>> >>>>> >>> >>>>> self.sub_dict = dict(FQDN=self.fqdn, >>> >>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >>> >>>>> SUFFIX=self.suffix, >>> >>>>> OPTIONAL_NTP=optional_ntp, >>> >>>>> ZONEMGR=self.zonemgr, >>> >>>>> - ZONE_REFRESH=self.zone_refresh, >>> >>>>> IPA_CA_RECORD=ipa_ca, >>> >>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >>> >>>>> + PERSISTENT_SEARCH="yes", >>> >>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >>> >>>> >>> >>>> But anyway, I think this piece of code is unnecessarily complicated, I >>>> don't see >>> >>>> a need for the 'boolean_var' dict here. I would suggest replacing it with >>> >>>> something like: >>> >>>> >>> >>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >>> >>>> >>> >>>> and then pass serial_autoincrement to self.sub_dict = dict(...) >>> >>>> >>> >>>> >>> >>> >>> >>> Attached patch refactored the relevant part of the code. >>> >>> >>> >>> Tomas >>> >> >> Thanks for patches! I am just thinking, should we also hide the respective >> option from ipa global DNS configuration? That's idnszonerefresh attribute. >> >> We may want to mark the attribute as invisible in CLI + remove it from Web UI. >> Petr - what is your take on this? Do you plan to remove idnszonerefresh >> attribute support in the future (Fedora 20) as persistent search will be >> mandatory in that time? > > Yes, you are right. We completely forgot to web UI. And yes - please remove the > option from web UI. Ok, Tomas please do the changes as proposed above. > > The latest development shows that persistent search will be replaced by RFC > 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. > All options related to persistent search and zone_refresh will simply > disappear. Syncrepl itself doesn't require explicit configuration. Ah, so this means that "psearch" option will be also removed from bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that cause issues with Fedora 20? Should we already avoid using the "psearch" option and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? Thanks, Martin From simo at redhat.com Mon Jul 15 14:15:12 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 15 Jul 2013 10:15:12 -0400 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E3FFBC.8000809@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> Message-ID: <1373897712.30537.353.camel@willson.li.ssimo.org> On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: > On 07/15/2013 03:44 PM, Petr Spacek wrote: > > On 15.7.2013 15:31, Martin Kosek wrote: > >> On 07/11/2013 05:10 PM, Tomas Babej wrote: > >>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: > >>> > >>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: > >>> > >>>>> boolean_var = {} > >>> > >>>>> - for var in ('persistent_search', 'serial_autoincrement'): > >>> > >>>>> + for var in ('serial_autoincrement'): > >>> > >>>> This won't work - a one element tuple needs a comma at the end: > >>> > >>>> ('serial_autoincrement', ) > >>> > >>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" > >>> > >>>>> > >>> > >>>>> self.sub_dict = dict(FQDN=self.fqdn, > >>> > >>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): > >>> > >>>>> SUFFIX=self.suffix, > >>> > >>>>> OPTIONAL_NTP=optional_ntp, > >>> > >>>>> ZONEMGR=self.zonemgr, > >>> > >>>>> - ZONE_REFRESH=self.zone_refresh, > >>> > >>>>> IPA_CA_RECORD=ipa_ca, > >>> > >>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], > >>> > >>>>> + PERSISTENT_SEARCH="yes", > >>> > >>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) > >>> > >>>> > >>> > >>>> But anyway, I think this piece of code is unnecessarily complicated, I > >>>> don't see > >>> > >>>> a need for the 'boolean_var' dict here. I would suggest replacing it with > >>> > >>>> something like: > >>> > >>>> > >>> > >>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" > >>> > >>>> > >>> > >>>> and then pass serial_autoincrement to self.sub_dict = dict(...) > >>> > >>>> > >>> > >>>> > >>> > >>> > >>> > >>> Attached patch refactored the relevant part of the code. > >>> > >>> > >>> > >>> Tomas > >>> > >> > >> Thanks for patches! I am just thinking, should we also hide the respective > >> option from ipa global DNS configuration? That's idnszonerefresh attribute. > >> > >> We may want to mark the attribute as invisible in CLI + remove it from Web UI. > >> Petr - what is your take on this? Do you plan to remove idnszonerefresh > >> attribute support in the future (Fedora 20) as persistent search will be > >> mandatory in that time? > > > > Yes, you are right. We completely forgot to web UI. And yes - please remove the > > option from web UI. > > Ok, Tomas please do the changes as proposed above. > > > > > The latest development shows that persistent search will be replaced by RFC > > 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. > > All options related to persistent search and zone_refresh will simply > > disappear. Syncrepl itself doesn't require explicit configuration. > > Ah, so this means that "psearch" option will be also removed from > bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that > cause issues with Fedora 20? Should we already avoid using the "psearch" option > and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? Won't the new bind-dyndb-ldap simply ignore the psearch option when it moves to syncrepl ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Jul 15 14:41:28 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Jul 2013 16:41:28 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <1373897712.30537.353.camel@willson.li.ssimo.org> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> <1373897712.30537.353.camel@willson.li.ssimo.org> Message-ID: <51E40A18.4010907@redhat.com> On 15.7.2013 16:15, Simo Sorce wrote: > On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: >> On 07/15/2013 03:44 PM, Petr Spacek wrote: >>> On 15.7.2013 15:31, Martin Kosek wrote: >>>> On 07/11/2013 05:10 PM, Tomas Babej wrote: >>>>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >>>>> >>>>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >>>>> >>>>>>> boolean_var = {} >>>>> >>>>>>> - for var in ('persistent_search', 'serial_autoincrement'): >>>>> >>>>>>> + for var in ('serial_autoincrement'): >>>>> >>>>>> This won't work - a one element tuple needs a comma at the end: >>>>> >>>>>> ('serial_autoincrement', ) >>>>> >>>>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >>>>> >>>>>>> >>>>> >>>>>>> self.sub_dict = dict(FQDN=self.fqdn, >>>>> >>>>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >>>>> >>>>>>> SUFFIX=self.suffix, >>>>> >>>>>>> OPTIONAL_NTP=optional_ntp, >>>>> >>>>>>> ZONEMGR=self.zonemgr, >>>>> >>>>>>> - ZONE_REFRESH=self.zone_refresh, >>>>> >>>>>>> IPA_CA_RECORD=ipa_ca, >>>>> >>>>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >>>>> >>>>>>> + PERSISTENT_SEARCH="yes", >>>>> >>>>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >>>>> >>>>>> >>>>> >>>>>> But anyway, I think this piece of code is unnecessarily complicated, I >>>>>> don't see >>>>> >>>>>> a need for the 'boolean_var' dict here. I would suggest replacing it with >>>>> >>>>>> something like: >>>>> >>>>>> >>>>> >>>>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >>>>> >>>>>> >>>>> >>>>>> and then pass serial_autoincrement to self.sub_dict = dict(...) >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> Attached patch refactored the relevant part of the code. >>>>> >>>>> >>>>> >>>>> Tomas >>>>> >>>> >>>> Thanks for patches! I am just thinking, should we also hide the respective >>>> option from ipa global DNS configuration? That's idnszonerefresh attribute. >>>> >>>> We may want to mark the attribute as invisible in CLI + remove it from Web UI. >>>> Petr - what is your take on this? Do you plan to remove idnszonerefresh >>>> attribute support in the future (Fedora 20) as persistent search will be >>>> mandatory in that time? >>> >>> Yes, you are right. We completely forgot to web UI. And yes - please remove the >>> option from web UI. >> >> Ok, Tomas please do the changes as proposed above. >> >>> >>> The latest development shows that persistent search will be replaced by RFC >>> 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. >>> All options related to persistent search and zone_refresh will simply >>> disappear. Syncrepl itself doesn't require explicit configuration. >> >> Ah, so this means that "psearch" option will be also removed from >> bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that >> cause issues with Fedora 20? Should we already avoid using the "psearch" option >> and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? > > Won't the new bind-dyndb-ldap simply ignore the psearch option when it > moves to syncrepl ? I can do it, but I think that cleanest way is to remove the 'psearch' option in upgrade script. Another option is to release new bind-dyndb-ldap to Fedora 19 and change default values to 'psearch yes' right now. Do you agree? -- Petr^2 Spacek From pviktori at redhat.com Mon Jul 15 14:43:52 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Jul 2013 16:43:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0244 Integration testing framework In-Reply-To: <51DE96C4.8000401@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> <51C9883C.8030204@redhat.com> <51DD4DAD.7050408@redhat.com> <51DD82CE.3080001@redhat.com> <51DE96C4.8000401@redhat.com> Message-ID: <51E40AA8.4090607@redhat.com> On 07/11/2013 01:28 PM, Jan Cholasta wrote: > On 10.7.2013 17:50, Petr Viktorin wrote: >> On 07/10/2013 02:03 PM, Jan Cholasta wrote: >>> make test seems to run fine with patches 230-242 applied, however >>> ipa-run-tests produces the following output: >>> >> [...Skipping nose output...] >>> >>> >>> I guess the location of the test certificate should be made configurable >>> in order to fix the host and service plugin test failures. >> >> Making the existing test suite pass out of tree it's not a goal for this >> patchset. There is a pending patch for the service cert. > > Better report it now than forget it later. > >> >>> Also, there is a lot of debugging messages in ipa-run-tests output which >>> wasn't there before IIRC, is that intentional? >> >> Yes, I believe that for the integration tests it's better to see what is >> going on. Both for manual runs, and also this way the information is >> more easily picked up by CI tools. > > It's harder to see what's going on with so much noise IMHO, I would > prefer less verbose output for manual runs by default. On the other hand, the integration tests take too long and without output they may seem stuck. I'd rather not make that the default. I'll try to find some balance and make it more easily configurable in future patches. >>> If $MASTER (and possible other host names) is not resolvable, >>> ipa-test-config --global crashes: >>> >>> $ ipa-test-config --global >>> Traceback (most recent call last): >>> File "/usr/bin/ipa-test-config", line 104, in >>> print main(sys.argv[1:]), >>> File "/usr/bin/ipa-test-config", line 58, in main >>> return config.env_to_script(get_object(conf, >>> args).to_env(**kwargs)) >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", >>> line 168, in to_env >>> env['MASTER'] = default_domain.master.hostname >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_integration/config.py", >>> line 282, in master >>> return self.masters[0] >>> IndexError: list index out of range >> >> Fixed. >> Now, if the name is not resolvable, reading the config will fail. >> Alternatively, the IP address can be given in variables such as >> $BEAKERREPLICA1_IP_env1 (no, I didn't invent the name). > > This fixed ipa-test-config as advertised, but "ipa-run-tests > test_integration/test_simple_replication.py" still fails. > >>> Both the tests in test_simple_replication.py fail for me. I suspect it >>> is because the data isn't replicated fast enough, a little delay between >>> user-show and user-add might fix this. >> >> Hm, they worked for me. >> I've added a delay. It seems fragile, I wonder what the proper way to >> do this would be. > > Hmm, the "replica -> master" test still fails for me, even with delay > increased to 20 s. Is there anything in the DS logs? > Something less fragile than delay would certainly be nice. I'll read up on the DS replication docs, and ask for some guidance. >> I've made some other changes, mainly BeakerLib plugin output. >> >> Patch 240: Avoid infinite recursion that happened with some cases of bad >> SSH credentials >> Patch 241-243: Rework the BeakerLib plugin output to better match >> traditional Beaker tests >> Patch 244: Make it possible to explicitly specify IP addresses of hosts > > To sum things up, there are still some little bugs, but these can be > fixed after the beta release, in general everything seems to work, so ACK. Thanks, pushed to master: 23d3fde05960d6e47485e246e11bec701b30cb59 Not closing the ticket yet until the issues are cleared (or moved to separate tickets). -- Petr? From mkosek at redhat.com Mon Jul 15 14:44:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 16:44:32 +0200 Subject: [Freeipa-devel] [PATCH] Use pkg-config to detect cmocka In-Reply-To: <20130715131353.GA18587@redhat.com> References: <20130704094906.GB26182@mail.corp.redhat.com> <20130704101054.GA3956@redhat.com> <20130704114935.GD26182@mail.corp.redhat.com> <51E3F207.309@redhat.com> <20130715131353.GA18587@redhat.com> Message-ID: <51E40AD0.4010900@redhat.com> On 07/15/2013 03:13 PM, Alexander Bokovoy wrote: > On Mon, 15 Jul 2013, Martin Kosek wrote: >> On 07/04/2013 01:49 PM, Lukas Slebodnik wrote: >>> On (04/07/13 13:10), Alexander Bokovoy wrote: >>>> On Thu, 04 Jul 2013, Lukas Slebodnik wrote: >>>>> ehlo, >>>>> >>>>> libcmocka-0.3 was released and package is available in fedore >= 18. >>>>> libcmocka-devel contains pkg-config file, >>>>> therefore it is better to use pkg-config to detect this library. >>>>> >>>>> Patch is attached. >>>> Few comments. >>>> >>>> 0. Please follow https://fedorahosted.org/freeipa/wiki/PatchFormat >>> changed >>> >>>> 1. It would be nice to have a ticket in the FreeIPA trac. >>> Could ticket#3434 be used? I know that ticket is fixed. >>> https://fedorahosted.org/freeipa/ticket/3434 >>> Funcionality of patch is the same as Sumit's version. >>> >>>> 2. I think at this point we need to decide whether we want to have >>>> BuildRequires: libcmocka-devel >>>> in freeipa.spec.in. Given the change, older version would become >>>> unsupported but we don't really have any packaging dependency yet. >>> At the moment, there isnot any cmocka test in freeipa source repo. >>> >>> LS >>> >> >> Any update with this patch? If the build works OK, I would push it. >> >> I think we do not need to add libcmocka BuildRequires ATM and leave the cmocka >> tests optional (especially if there is no cmocka test). > Yes, it works fine. OK. I pushed the patch to master, ipa-3-2. Martin From pspacek at redhat.com Mon Jul 15 14:58:00 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Jul 2013 16:58:00 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1372351401.18685.35.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> Message-ID: <51E40DF8.80105@redhat.com> Hello, first pair of this message quickly concludes discussion about database part of the DNSSEC support and then key material handling is discussed. I'm sorry for the wall of text. On 27.6.2013 18:43, Simo Sorce wrote: >>> > > * How to get sorted list of entries from LDAP? Use LDAP >>> > > server-side sorting? Do we have necessary indices? >>> > > >>> > >We can do client side sorting as well I guess, I do not have a strong >>> > >opinion here. The main reason why you need ordering is to detect delete >>> > >records right ? >> >Exactly. I realized that server-side sorting doesn't make sense because we >> >plan to use syncrepl, so there is nothing to sort - only the flow of >> >incremental updates. > Syncrepl includes notice of deletions too, right ? Yes. Client receives delete notification with entryUUID, so we can unambiguously identify the deleted entry. I wrote example LDAP client and it works (against OpenLDAP :-). >>> > (Filesystem) cache maintenance >>> >>> > Questions: How often should we save the cache from operating >>> memory to disk? >>> >>> Prerequisite to be able to evaluate this question. How expensive is it >>> to save the cache ? >> My test zone contains 65535 AAAA records, 255 A records, 1 SOA + 1 NS record. >> >> Benchmark results: >> zone dump < 0.5 s (to text file) >> zone load < 1 s (from text file) >> zone delete < 9 s (LOL. This is caused by implementation details of RBTDB.) >> >> LDAP search on the whole sub-tree: < 15 s > > Ouch, this looks very slow, missing indexes ?) I don't see any 'notes=U' in access log. Also, my OpenLDAP instance with the same DNS data can do the same search < 2 seconds. > Is this just the search? or is it search + zone load ? Just the search. >> Load time for bind-dyndb-ldap 3.x: < 120 s > > So, a reload from scratch can take many 10s of seconds on big zones, did > this test include DNSSEC signing ? Or would we need to add that on top ? The time is for plain load. Current code is horribly ineffective and generates one extra LDAP search for each update. This madness will be eliminated by syncrepl, so the plain load time should be cut to much smaller value. We will see. The other problem is that current code serializes a lot of work. This also will be mitigated to certain level (not completely, for now). >> Originally, I planed to write a script which would compare data in LDAP with >> zone file on disk. This script could be used for debugging & automated >> testing, so we can assess if the code behaves correctly and decide if we want >> to implement automatic re-synchronization when necessary. > > Wouldn't this script be subject to races depending at what time it is > accessing either LDAP or the file ? Yes, it would. The script was intended for 'lab use': 1. Run DNS server. 2. Do big amount of dynamic updates in short time. 3. Shutdown DNS and LDAP servers. 4. Compare data in DNS database with data in LDAP. This could tell us how often and how many inconsistencies occur. After that we can make up some re-synchronization intervals etc. > The main issue here is that it is hard to know when doing a full re-sync > is necessary. And because it is expensive I am wary of doing it > automatically too often. > > However perhaps a timed event so it is done once a day it is not a bad > idea. I agree. I think that we sorted out necessary changes in storage/database part of the DNSSEC integration. The remaining part is mostly about key management. Following text mentions 'DNSSEC keys' many times, so I tried to summarize how keys are used in DNSSEC. Feel free to skip it. == DNSSEC theory == Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, the first key pair) and Zone Signing Key (ZSK, the second key pair). - *Parent* zone contains a copy of public part of the KSK. - Zone itself contains public part of ZSK (and KSK). - Client uses public part of KSK (obtained from secure parent zone) for ZSK verification. - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG records) and verification on client side. Each key and signature contains key-id, so one zone can be signed by multiple KSKs and ZSKs at the same time. This solves the key roll over problem. Each key contains this set of timestamps: Created, Revoke - self descriptive :-) Publish - public part of the key will be visible in zone after this time Active - new signatures with this key can be generated after this time Inactive - new signatures with this key cannot be generated after this time Delete - public part of the key will deleted from the zone after this time NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change in parent zone) and ZSK should be changed ~ each 1-3 months. The recommendation says [1] that zone should have two ZSKs: One Active (used for signature generation) and second only Published (ready for roll over in case of emergency/when the first key pair expires). This mitigates problems with caches and stale key material during roll-over. BIND 9 can do signature maintenance/ZSK key roll over automatically. It needs only keys stored in files (with proper timestamps) and all signatures will be generated & removed when the right time passes. KSK has to be rolled over manually because it requires changes in parent zone. (It could be automated for sub-zones if their parent zone is also managed by the same IPA server.) == End of DNSSEC theory == 1) How will we handle generation of key pairs? How will externally generated keys be imported? Personally, I would start with 'classical' command line utilities like dnssec-keygen etc. and extend 'ipa' tool to import generated keys. (Import = read keys from text files and create appropriate attributes to LDAP.) Initial key generation is closely related to the question how should we handle (periodic) key regeneration? (e.g. "Generate new ZSK each month.") Is it okay to use normal cron job to handle the key generation? I.e. to call dnssec-keygen with proper parameters each month and store the result in LDAP? Or should we teach certmonger to take care of DNSSEC keys? Certmonger would have to call dnssec-keygen and to do some IPA calls. (I assume that key parsing and import will be handled by IPA framework.) We can postpone the key management for the first version and just provide interface for key removal and import from file. 2) Second question is how and where keys should be stored. AFAIK BIND 9 expects that keys will be stored in file system: One key pair as two files in specified directory. We probably want to store keys in LDAP, as usual. My proposal is to represent each key pair by object with new class idnsDNSSECKey. This 'key pair object' will be stored inside zone container. E.g. DNS zone = idnsname=ipa.test,cn=dns,dc=ipa,dc=test Key pair = cn=005+01908,idnsname=ipa.test,cn=dns,dc=ipa,dc=test Private key is represented by opaque blob (size ~ 1-2 kiB), so octetString could be the right syntax: attributetypes: ( x.x.x.x.x NAME 'idnsSecPrivateKey' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) Public key can be represented with normal DNSKEY record (size ~ 200-500 B), so it would be possible to use normal DNSKEY attribute. I see two problems with this approach: - DNSKEY record (= attribute) is multi-valued by definition, but only one public key can be present in a key pair. - DNSKEY records will be managed automatically by BIND so we don't want to let users to mess with them directly. DNSKEYRecord attribute is not defined at the moment and I'm not willing to define it now. For these reasons I think that we can define new public key attribute in the same way as private key attribute: attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) The resulting object class could be: objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) CN attribute is user readable key name. It could be anything. BIND's syntax follows (text copied from dnssec-keyfromlabel): This is an identification string for the key files: String of the form "Knnnn.+aaa+iiiii": - nnnn is the key name (zone name) - aaa is the numeric representation of the algorithm - iiiii is the key identifier (or footprint) Naturally, we can omit leading "K" and zone name, because we know the name from parent object in the LDAP/DIT. Also, it could be nice to indicate the type of the key - KSK or ZSK. Attribute idnsSecPrivateKey should be readable only by DNS admins (and DNS servers :-). I'm not sure if we should make restrict read access even more. Is there a valid reason for admin to read the blob? I don't know, but admin can read the file on disk anyway ... From user interface point of view, key pairs are bit hard to deal with. Private key format is algorithm-dependent, so the only universal way to get standardized fields like valid-from/active-from/valid-to/revoked timestamps etc. is to call parser from bind-libs. 3) How will the configuration be stored? Parameters are: - DNSSEC enabled/disabled for one zone or globally - proposal: add a new boolean attribute idnsSecInlineSigning to zone and global config object - NSEC3 parameters - proposal: use standard NSEC3PARAM record in the zone The rest of the configuration options are related to the key management problem. We need to know: - how many key pairs (e.g. 2 KSKs, 2 ZSKs) - when (e.g. generate new key pair 30 days before active key expires) - of which key types (KSK or ZSK) - with which algorithms - with which key lengths should be generated. Note that we need to store configuration about X KSKs and Y ZSKs. Again, we can postpone the key management for the first version. 4) For future versions - do we plan to add support for PKCS#11 HSMs? BIND 9 can use OpenSSL for this stuff (somehow), but I didn't look into details. [1] http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf section 9.3 Generation of Public Key-Private Key Pair (DNSSEC-OP1) page 9-5 Congratulations, you reached end of the text :-) Have a nice day! -- Petr^2 Spacek From mkosek at redhat.com Mon Jul 15 15:18:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 17:18:28 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E40A18.4010907@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> <1373897712.30537.353.camel@willson.li.ssimo.org> <51E40A18.4010907@redhat.com> Message-ID: <51E412C4.2020209@redhat.com> On 07/15/2013 04:41 PM, Petr Spacek wrote: > On 15.7.2013 16:15, Simo Sorce wrote: >> On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: >>> On 07/15/2013 03:44 PM, Petr Spacek wrote: >>>> On 15.7.2013 15:31, Martin Kosek wrote: >>>>> On 07/11/2013 05:10 PM, Tomas Babej wrote: >>>>>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >>>>>> >>>>>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >>>>>> >>>>>>>> boolean_var = {} >>>>>> >>>>>>>> - for var in ('persistent_search', 'serial_autoincrement'): >>>>>> >>>>>>>> + for var in ('serial_autoincrement'): >>>>>> >>>>>>> This won't work - a one element tuple needs a comma at the end: >>>>>> >>>>>>> ('serial_autoincrement', ) >>>>>> >>>>>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >>>>>> >>>>>>>> >>>>>> >>>>>>>> self.sub_dict = dict(FQDN=self.fqdn, >>>>>> >>>>>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >>>>>> >>>>>>>> SUFFIX=self.suffix, >>>>>> >>>>>>>> OPTIONAL_NTP=optional_ntp, >>>>>> >>>>>>>> ZONEMGR=self.zonemgr, >>>>>> >>>>>>>> - ZONE_REFRESH=self.zone_refresh, >>>>>> >>>>>>>> IPA_CA_RECORD=ipa_ca, >>>>>> >>>>>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >>>>>> >>>>>>>> + PERSISTENT_SEARCH="yes", >>>>>> >>>>>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >>>>>> >>>>>>> >>>>>> >>>>>>> But anyway, I think this piece of code is unnecessarily complicated, I >>>>>>> don't see >>>>>> >>>>>>> a need for the 'boolean_var' dict here. I would suggest replacing it with >>>>>> >>>>>>> something like: >>>>>> >>>>>>> >>>>>> >>>>>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >>>>>> >>>>>>> >>>>>> >>>>>>> and then pass serial_autoincrement to self.sub_dict = dict(...) >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Attached patch refactored the relevant part of the code. >>>>>> >>>>>> >>>>>> >>>>>> Tomas >>>>>> >>>>> >>>>> Thanks for patches! I am just thinking, should we also hide the respective >>>>> option from ipa global DNS configuration? That's idnszonerefresh attribute. >>>>> >>>>> We may want to mark the attribute as invisible in CLI + remove it from Web >>>>> UI. >>>>> Petr - what is your take on this? Do you plan to remove idnszonerefresh >>>>> attribute support in the future (Fedora 20) as persistent search will be >>>>> mandatory in that time? >>>> >>>> Yes, you are right. We completely forgot to web UI. And yes - please remove >>>> the >>>> option from web UI. >>> >>> Ok, Tomas please do the changes as proposed above. >>> >>>> >>>> The latest development shows that persistent search will be replaced by RFC >>>> 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. >>>> All options related to persistent search and zone_refresh will simply >>>> disappear. Syncrepl itself doesn't require explicit configuration. >>> >>> Ah, so this means that "psearch" option will be also removed from >>> bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that >>> cause issues with Fedora 20? Should we already avoid using the "psearch" option >>> and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by >>> default? >> >> Won't the new bind-dyndb-ldap simply ignore the psearch option when it >> moves to syncrepl ? > > I can do it, but I think that cleanest way is to remove the 'psearch' option in > upgrade script. Hm, right, this should make the upgrade script a lot simpler - it would just remove all psearch or zone_refresh references. > > Another option is to release new bind-dyndb-ldap to Fedora 19 and change > default values to 'psearch yes' right now. Do you agree? Looks OK to me and would let us avoid doing any additional upgrade process for Fedora 20 - are you planning to do a Fedora 19 release any time soon? If yes, we can do the changes we are talking about in next 3.2.x release. Martin From mkosek at redhat.com Mon Jul 15 15:21:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 17:21:46 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E3FC84.7050407@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> Message-ID: <51E4138A.5060508@redhat.com> On 07/15/2013 03:43 PM, Jan Cholasta wrote: > On 15.7.2013 15:16, Martin Kosek wrote: >> On 07/11/2013 12:15 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Jul 2013, Jan Cholasta wrote: >>>> We can add WebUI improvements later. I have some WIP, but I need to discuss >>>> it with Petr first (he's away this week). >>> Ok. >>> >>> The patchset is in ipa-3-2 as well now. >> >> Just checking: >> >> 1) Jan, did you check size of these new indexes on IPA master with such a high >> number of users? How big are they? I want to make sure that this won't create >> an issue on upgrades to new 3.2.x. > > With 10k users, the indices ate roughly 250 MB of disk space. > >> >> 2) Does the patch set also fix the problem for Web UI? Currently, I think it >> will still grab and process all member attributes even though it does not need >> it. If the Web UI performance is still not sharp, I would rather leave this >> ticket opened and let Jan&Petr cooperate on the Web UI part. > > I agree on keeping the ticket open. > > Honza > Ok, I reopened the ticket. Petr and Jan, please cooperate on this one. Martin From simo at redhat.com Mon Jul 15 16:28:43 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 15 Jul 2013 12:28:43 -0400 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E40A18.4010907@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> <1373897712.30537.353.camel@willson.li.ssimo.org> <51E40A18.4010907@redhat.com> Message-ID: <1373905723.30537.371.camel@willson.li.ssimo.org> On Mon, 2013-07-15 at 16:41 +0200, Petr Spacek wrote: > On 15.7.2013 16:15, Simo Sorce wrote: > > On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: > >> On 07/15/2013 03:44 PM, Petr Spacek wrote: > >>> On 15.7.2013 15:31, Martin Kosek wrote: > >>>> On 07/11/2013 05:10 PM, Tomas Babej wrote: > >>>>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: > >>>>> > >>>>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: > >>>>> > >>>>>>> boolean_var = {} > >>>>> > >>>>>>> - for var in ('persistent_search', 'serial_autoincrement'): > >>>>> > >>>>>>> + for var in ('serial_autoincrement'): > >>>>> > >>>>>> This won't work - a one element tuple needs a comma at the end: > >>>>> > >>>>>> ('serial_autoincrement', ) > >>>>> > >>>>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" > >>>>> > >>>>>>> > >>>>> > >>>>>>> self.sub_dict = dict(FQDN=self.fqdn, > >>>>> > >>>>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): > >>>>> > >>>>>>> SUFFIX=self.suffix, > >>>>> > >>>>>>> OPTIONAL_NTP=optional_ntp, > >>>>> > >>>>>>> ZONEMGR=self.zonemgr, > >>>>> > >>>>>>> - ZONE_REFRESH=self.zone_refresh, > >>>>> > >>>>>>> IPA_CA_RECORD=ipa_ca, > >>>>> > >>>>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], > >>>>> > >>>>>>> + PERSISTENT_SEARCH="yes", > >>>>> > >>>>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) > >>>>> > >>>>>> > >>>>> > >>>>>> But anyway, I think this piece of code is unnecessarily complicated, I > >>>>>> don't see > >>>>> > >>>>>> a need for the 'boolean_var' dict here. I would suggest replacing it with > >>>>> > >>>>>> something like: > >>>>> > >>>>>> > >>>>> > >>>>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" > >>>>> > >>>>>> > >>>>> > >>>>>> and then pass serial_autoincrement to self.sub_dict = dict(...) > >>>>> > >>>>>> > >>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> Attached patch refactored the relevant part of the code. > >>>>> > >>>>> > >>>>> > >>>>> Tomas > >>>>> > >>>> > >>>> Thanks for patches! I am just thinking, should we also hide the respective > >>>> option from ipa global DNS configuration? That's idnszonerefresh attribute. > >>>> > >>>> We may want to mark the attribute as invisible in CLI + remove it from Web UI. > >>>> Petr - what is your take on this? Do you plan to remove idnszonerefresh > >>>> attribute support in the future (Fedora 20) as persistent search will be > >>>> mandatory in that time? > >>> > >>> Yes, you are right. We completely forgot to web UI. And yes - please remove the > >>> option from web UI. > >> > >> Ok, Tomas please do the changes as proposed above. > >> > >>> > >>> The latest development shows that persistent search will be replaced by RFC > >>> 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. > >>> All options related to persistent search and zone_refresh will simply > >>> disappear. Syncrepl itself doesn't require explicit configuration. > >> > >> Ah, so this means that "psearch" option will be also removed from > >> bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that > >> cause issues with Fedora 20? Should we already avoid using the "psearch" option > >> and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? > > > > Won't the new bind-dyndb-ldap simply ignore the psearch option when it > > moves to syncrepl ? > > I can do it, but I think that cleanest way is to remove the 'psearch' option > in upgrade script. Sure, but if the upgrade, for whatever reason, fails to remove it bind-dyndb-ldap should just ignore. > Another option is to release new bind-dyndb-ldap to Fedora 19 and change > default values to 'psearch yes' right now. Do you agree? Too much churn, I think it is ok to change it when we are done with syncrepl and upgrade config, with the fallback failsafe that even if upgrade doesn't remove the option bind-dyndb-ldap will simply ignore it. This will be safer even for people using stuff like cfengine/puppet to manage configurations and not realizing we changed the conf on upgrade, their confsystems will push again a conf file with psearch yes but bnid-dyndb-ldap won't break. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jul 15 17:14:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Jul 2013 20:14:52 +0300 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users Message-ID: <20130715171452.GE18587@redhat.com> Hi! Attached patch allows to enable serving trusted domain users and groups through Schema Compatibilty plugin. The patch only does FreeIPA master configuration settings, the real work is done by the changes to slapi-nis plugin (in a separate email). Since ipa-adtrust-install can safely be run multiple times, one can re-run it on the IPA master to enable serving old clients, by specifying ipa-adtrust-install --enable-compat or answering 'yes' to the interactive question. I have expanded man page for ipa-adtrust-install to cover this option. Once enabled, following is possible: --------------------------------------------------------------------------- # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li '(&(cn=domain admins at ad.lan)(objectclass=posixgroup))' SASL/GSSAPI authentication started SASL username: admin at VDA.LI SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(cn=domain admins at ad.lan)(objectclass=posixgroup)) # requesting: ALL # # domain admins at ad.lan, groups, compat, vda.li dn: cn=domain admins at ad.lan,cn=groups,cn=compat,dc=vda,dc=li objectClass: posixGroup objectClass: extensibleObject objectClass: top gidNumber: 1442800512 memberUid: uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li schema-compat-origin: sssd ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-512 cn: domain admins at ad.lan # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 --------------------------------------------------------------------------- and for users: --------------------------------------------------------------------------- # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li # '(uid=administrator at ad.lan)' SASL/GSSAPI authentication started SASL username: admin at VDA.LI SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=administrator at ad.lan) # requesting: ALL # # administrator at ad.lan, users, compat, vda.li dn: uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li objectClass: posixAccount objectClass: extensibleObject objectClass: top gecos: Administrator cn: Administrator uidNumber: 1442800500 gidNumber: 1442800500 homeDirectory: / schema-compat-origin: sssd ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-500 uid: administrator at ad.lan # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 ---------------------------------------------------------------------------- Currently PAM authentication is a bit broken due to yet-to-hunt bug in SSSD or my environment (Jakub was unable to reproduce it) where SSSD thinks that AD DC is offline during authentication step. However, if you don't hit the bug, you can check authentication by doing following bind and entering a password for your AD administrator: # ldapsearch -D uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li \ -W -x -C -a always -b dc=vda,dc=li '(uid=admin)' The bind operation needs to be performed _after_ user lookup. All these commands are only examples, I'm currently working on seeing how to configure pam_ldap/nss_ldap to use compat plugin this way. -- / Alexander Bokovoy -------------- next part -------------- >From bd7addcc2a25555b37cd128dcbea0bc6e9b2929e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Jul 2013 19:13:50 +0300 Subject: [PATCH] ipa-adtrust-install: configure compatibility tree to serve trusted domain users Enables support for trusted domains users for old clients through Schema Compatibility plugin. SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi-nis package needs to be installed and schema-compat-plugin will be configured to provide lookup of users and groups from trusted domains via SSSD on IPA server. These users and groups will be available under cn=users,cn=compat,$SUFFIX and cn=groups,cn=compat,$SUFFIX trees. SSSD will normalize names of users and groups to lower case. In addition to providing these users and groups through the compat tree, this option enables authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN uid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX. This authentication is related to PAM stack using 'system-auth' PAM service. If you have disabled HBAC rule 'allow_all', then make sure there is special service called 'system-auth' created and HBAC rule to allow access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service is not used directly by any other application, therefore it is safe to create one specifically to support trusted domain users via compatibility path. https://fedorahosted.org/freeipa/ticket/3567 --- install/tools/ipa-adtrust-install | 18 +++++++++++++++++- install/tools/man/ipa-adtrust-install.1 | 18 ++++++++++++++++++ ipaserver/install/adtrustinstance.py | 22 +++++++++++++++++++++- 3 files changed, 56 insertions(+), 2 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 5744c6f..838f722 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -62,6 +62,9 @@ def parse_options(): parser.add_option("--add-sids", dest="add_sids", action="store_true", default=False, help="Add SIDs for existing users and" \ " groups as the final step") + parser.add_option("--enable-compat", + dest="enable_compat", default=False, action="store_true", + help="Enable support for trusted domains for old clients") options, args = parser.parse_args() safe_options = parser.get_safe_opts(options) @@ -194,6 +197,15 @@ def ensure_admin_kinit(admin_name, admin_password): return False return True +def enable_compat_tree(): + print "Do you want to enable support for trusted domains in Schema Compatibility plugin?" + print "This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users." + print "" + enable_compat = ipautil.user_input("Enable trusted domains support in slapi-nis?", default = False, allow_empty = False) + print "" + return enable_compat + + def main(): safe_options, options = parse_options() @@ -244,6 +256,9 @@ def main(): sys.exit("Aborting installation.") break + if not options.unattended and not options.enable_compat: + options.enable_compat = enable_compat_tree() + # Check we have a public IP that is associated with the hostname ip = None try: @@ -363,7 +378,8 @@ def main(): smb.setup(api.env.host, ip_address, api.env.realm, api.env.domain, netbios_name, reset_netbios_name, options.rid_base, options.secondary_rid_base, - options.no_msdcs, options.add_sids) + options.no_msdcs, options.add_sids, + enable_compat = options.enable_compat) smb.find_local_id_range() smb.create_instance() diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 38957f3..7931178 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -106,6 +106,24 @@ The password of the user with administrative privileges for this IPA server. Wil .TP The credentials of the admin user will be used to obtain Kerberos ticket before configuring cross-realm trusts support and afterwards, to ensure that the ticket contains MS-PAC information required to actually add a trust with Active Directory domain via 'ipa trust-add --type=ad' command. .TP +\fB\-\-enable\-compat\fR +Enables support for trusted domains users for old clients through Schema Compatibility plugin. +SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that +lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi\-nis package +needs to be installed and schema\-compat\-plugin will be configured to provide lookup of +users and groups from trusted domains via SSSD on IPA server. These users and groups will be +available under \fBcn=users,cn=compat,$SUFFIX\fR and \fBcn=groups,cn=compat,$SUFFIX\fR trees. +SSSD will normalize names of users and groups to lower case. +.IP +In addition to providing these users and groups through the compat tree, this option enables +authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN +\fBuid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX\fR. This authentication is related +to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled HBAC rule 'allow_all', then +make sure there is special service called '\fBsystem\-auth\fR' created and HBAC rule to allow +access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service +is not used directly by any other application, therefore it is safe to create one specifically +to support trusted domain users via compatibility path. +.TP .SH "EXIT STATUS" 0 if the installation was successful diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 4eb20d9..9ecc7e9 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -664,6 +664,20 @@ class ADTRUSTInstance(service.Service): except Exception, e: root_logger.critical("Checking replicas for cifs principals failed with error '%s'" % e) + def __enable_compat_tree(self): + try: + compat_plugin_dn = DN("cn=Schema Compatibility,cn=plugins,cn=config") + lookup_sssd_name = "schema-compat-lookup-sssd" + for config in (("cn=users", "user"), ("cn=groups", "group")): + entry_dn = DN(config[0], compat_plugin_dn) + current = self.admin_conn.get_entry(entry_dn) + lookup_sssd = current.get(lookup_sssd_name, []) + if not(config[1] in lookup_sssd): + current[lookup_sssd_name] = [config[1]] + self.admin_conn.update_entry(entry_dn, current) + except Exception, e: + root_logger.critical("Enabling SSSD support in slapi-nis failed with error '%s'" % e) + def __start(self): try: self.start() @@ -713,7 +727,7 @@ class ADTRUSTInstance(service.Service): def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, reset_netbios_name, rid_base, secondary_rid_base, - no_msdcs=False, add_sids=False, smbd_user="samba"): + no_msdcs=False, add_sids=False, smbd_user="samba", enable_compat=False): self.fqdn = fqdn self.ip_address = ip_address self.realm = realm_name @@ -724,6 +738,7 @@ class ADTRUSTInstance(service.Service): self.secondary_rid_base = secondary_rid_base self.no_msdcs = no_msdcs self.add_sids = add_sids + self.enable_compat = enable_compat self.smbd_user = smbd_user self.suffix = ipautil.realm_to_suffix(self.realm) self.ldapi_socket = "%%2fvar%%2frun%%2fslapd-%s.socket" % \ @@ -811,6 +826,11 @@ class ADTRUSTInstance(service.Service): self.step("configuring smbd to start on boot", self.__enable) self.step("adding special DNS service records", \ self.__add_dns_service_records) + + if self.enable_compat: + self.step("Enabling trusted domains support for older clients via Schema Compatibility plugin", + self.__enable_compat_tree) + self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ self.__restart_dirsrv) self.step("adding fallback group", self.__add_fallback_group) -- 1.8.3.1 From mkosek at redhat.com Mon Jul 15 16:36:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Jul 2013 18:36:30 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <1373905723.30537.371.camel@willson.li.ssimo.org> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> <1373897712.30537.353.camel@willson.li.ssimo.org> <51E40A18.4010907@redhat.com> <1373905723.30537.371.camel@willson.li.ssimo.org> Message-ID: <51E4250E.9030201@redhat.com> On 07/15/2013 06:28 PM, Simo Sorce wrote: > On Mon, 2013-07-15 at 16:41 +0200, Petr Spacek wrote: >> On 15.7.2013 16:15, Simo Sorce wrote: >>> On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: >>>> On 07/15/2013 03:44 PM, Petr Spacek wrote: >>>>> On 15.7.2013 15:31, Martin Kosek wrote: >>>>>> On 07/11/2013 05:10 PM, Tomas Babej wrote: >>>>>>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >>>>>>> >>>>>>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >>>>>>> >>>>>>>>> boolean_var = {} >>>>>>> >>>>>>>>> - for var in ('persistent_search', 'serial_autoincrement'): >>>>>>> >>>>>>>>> + for var in ('serial_autoincrement'): >>>>>>> >>>>>>>> This won't work - a one element tuple needs a comma at the end: >>>>>>> >>>>>>>> ('serial_autoincrement', ) >>>>>>> >>>>>>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> self.sub_dict = dict(FQDN=self.fqdn, >>>>>>> >>>>>>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >>>>>>> >>>>>>>>> SUFFIX=self.suffix, >>>>>>> >>>>>>>>> OPTIONAL_NTP=optional_ntp, >>>>>>> >>>>>>>>> ZONEMGR=self.zonemgr, >>>>>>> >>>>>>>>> - ZONE_REFRESH=self.zone_refresh, >>>>>>> >>>>>>>>> IPA_CA_RECORD=ipa_ca, >>>>>>> >>>>>>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >>>>>>> >>>>>>>>> + PERSISTENT_SEARCH="yes", >>>>>>> >>>>>>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> But anyway, I think this piece of code is unnecessarily complicated, I >>>>>>>> don't see >>>>>>> >>>>>>>> a need for the 'boolean_var' dict here. I would suggest replacing it with >>>>>>> >>>>>>>> something like: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> and then pass serial_autoincrement to self.sub_dict = dict(...) >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Attached patch refactored the relevant part of the code. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> >>>>>> Thanks for patches! I am just thinking, should we also hide the respective >>>>>> option from ipa global DNS configuration? That's idnszonerefresh attribute. >>>>>> >>>>>> We may want to mark the attribute as invisible in CLI + remove it from Web UI. >>>>>> Petr - what is your take on this? Do you plan to remove idnszonerefresh >>>>>> attribute support in the future (Fedora 20) as persistent search will be >>>>>> mandatory in that time? >>>>> >>>>> Yes, you are right. We completely forgot to web UI. And yes - please remove the >>>>> option from web UI. >>>> >>>> Ok, Tomas please do the changes as proposed above. >>>> >>>>> >>>>> The latest development shows that persistent search will be replaced by RFC >>>>> 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. >>>>> All options related to persistent search and zone_refresh will simply >>>>> disappear. Syncrepl itself doesn't require explicit configuration. >>>> >>>> Ah, so this means that "psearch" option will be also removed from >>>> bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that >>>> cause issues with Fedora 20? Should we already avoid using the "psearch" option >>>> and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? >>> >>> Won't the new bind-dyndb-ldap simply ignore the psearch option when it >>> moves to syncrepl ? >> >> I can do it, but I think that cleanest way is to remove the 'psearch' option >> in upgrade script. > > Sure, but if the upgrade, for whatever reason, fails to remove it > bind-dyndb-ldap should just ignore. > >> Another option is to release new bind-dyndb-ldap to Fedora 19 and change >> default values to 'psearch yes' right now. Do you agree? > > Too much churn, I think it is ok to change it when we are done with > syncrepl and upgrade config, with the fallback failsafe that even if > upgrade doesn't remove the option bind-dyndb-ldap will simply ignore it. > > This will be safer even for people using stuff like cfengine/puppet to > manage configurations and not realizing we changed the conf on upgrade, > their confsystems will push again a conf file with psearch yes but > bnid-dyndb-ldap won't break. > > Simo. > Hmm, that's right, it should be safer. Can bind-dyndb-ldap just yell to error log that there is an unknown configuration option? (if it does not do that already). Martin From abokovoy at redhat.com Mon Jul 15 17:30:03 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Jul 2013 20:30:03 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains Message-ID: <20130715173003.GF18587@redhat.com> Hi! Attached please find two patches against slapi-nis 0.47 to serve trusted domain users and groups to old clients. FreeIPA master needs to be enabled with this, see my patch 0108 (on freeipa-devel@). The patches add both lookup and PAM-based authentication bind for the users returned by SSSD lookup. Here is the logic: 0. Configuration is performed by setting schema-compat-lookup-sssd: schema-compat-sssd-min-id: in corresponding schema-compat plugin tree (cn=users and cn=groups). If schema-compat-sssd-min-id is not set, it will default to 1000. It is used to filter out attempts to fetch system users (<1000 on Fedora by default). 1. On query, we parse query filter to identify what type of request is this: user or group lookup and then issue getpwnam_r()/getgrnam_r() and getsidbyid() for libsss_nss_idmap to fetch all needed information. SSSD caches these requests they should be relatively fast. 2. Once we served the request, it is cached in schema-compat cache map. The entry in the cache is currently not expired explicitly but I'm working on expiring it on wrong authentication -- if PAM stack returns a response telling there is no such user. 3. Authentication bind for cached entries is done via PAM service 'system-auth'. If HBAC rule 'allow_all' is disabled in FreeIPA, one needs to create a rule with service 'system-auth' and allow all users to access it on IPA masters. Since system-auth is never used explicitly by any application (it is always included through PAM stack and only top-level PAM service is used to drive the HBAC ruleset), there is no problem. PAM authentication code is taken from pam_passthru DS plugin. We cannot use it unchanged because pam_passthru expects that LDAP entry will exist in DS, while it is not true for these synthetic entries representing trusted domain users. On Fedora one needs pam-devel and libsss_nss_idmap-devel to build the plugin with new functionality. -- / Alexander Bokovoy -------------- next part -------------- >From d3433f2033015724fc6580c00d89627afbc06c1d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Jul 2013 14:18:52 +0300 Subject: [PATCH 1/2] configure: add configure checks for sss_idmap and define attribute to lookup sssd If schema compat plugin configuration has 'schema-compat-lookup-sssd: user|group' then schema compat plugin will perform lookups of users/groups that were not found in the main store using getpwnam_r()/getgrnam_r() and libsss_idmap library. This is special case to support legacy clients. Schema compat plugin in the case is assumed to be running on FreeIPA master configured with trusts against Active Directory and SSSD configure as ipa_server_mode = True. Additionally, such entries are added to schema compat plugin's map cache and can be used for authentication purposes. They will use PAM authentication pass-through to system-auth service. --- configure.ac | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ src/Makefile.am | 6 ++++++ 2 files changed, 54 insertions(+) diff --git a/configure.ac b/configure.ac index 8d7cbe1..4a47d36 100644 --- a/configure.ac +++ b/configure.ac @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) AC_SUBST(ASYNCNS_LIBS) fi +AC_ARG_WITH(sss_nss_idmap, + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) +if pkg-config sss_nss_idmap 2> /dev/null ; then + if test x$use_sss_nss_idmap != xno ; then + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +else + if test $use_sss_idmap = yes ; then + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +fi +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) +AC_SUBST(SSS_NSS_IDMAP_CFLAGS) +AC_SUBST(SSS_NSS_IDMAP_LIBS) + +if x$SSS_NSS_IDMAP_LIBS != x ; then + AC_CHECK_HEADERS(pam.h) + if test x$ac_cv_header_pam_h = xno ; then + use_pam=yes + else + use_pam=no + fi + + if test $use_pam = yes ; then + PAM_CFLAGS= + PAM_LIBS=-lpam + else + AC_ERROR([ not found and it is required for SSSD mode]) + fi + AC_SUBST(PAM_CFLAGS) + AC_SUBST(PAM_LIBS) +fi + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", attrattr=schema-compat-entry-attribute AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) +sssdattr=schema-compat-lookup-sssd +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) +sssdminidattr=schema-compat-sssd-min-id +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR,"$sssdminidattr", + [Define to name of the attribute which is used to define lower bound of IDs (uid or gid) looked up through sssd. Everything below is not considered belonging to trusted domains.]) + maxvalue_attr=nis-max-value-size AC_DEFINE_UNQUOTED(NIS_PLUGIN_CONFIGURATION_MAXVALUE_ATTR,"$maxvalue_attr", diff --git a/src/Makefile.am b/src/Makefile.am index 6c8666b..59b6948 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA schemacompat_plugin_la_SOURCES = \ back-sch.c \ + back-sch.h \ backend.h \ back-shr.c \ back-shr.h \ @@ -64,6 +65,11 @@ schemacompat_plugin_la_SOURCES = \ wrap.h schemacompat_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(LIBPTHREAD) $(CONFIGURED_LINK_FLAGS) +if SSS_NSS_IDMAP +schemacompat_plugin_la_SOURCES += back-sch-sssd.c back-sch-pam.c +schemacompat_plugin_la_LIBADD += $(SSS_NSS_IDMAP_LIBS) $(PAM_LIBS) +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ -- 1.8.3.1 -------------- next part -------------- >From 4acd44441e71da5cedefaeb512ae13e482bbce5f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Jul 2013 14:30:44 +0300 Subject: [PATCH 2/2] schema-compat: add support for querying trusted domain users through SSSD src/back-sch-sssd.c implements interface to query trusted domain users and groups on FreeIPA master server via getpwnam_r(), getgrnam_r(), and libsss_idmap. src/back-sch-pam.c implements PAM authentication for trusted domain users using system-auth system service when running on FreeIPA master server. Schema-compat plugin can be configured to serve trusted domain users and groups through the plugin configuration entry in directory server: schema-compat-lookup-sssd: schema-compat-sssd-min-id: Separate trees should be configured to look up users and groups. If minimal id value is missing, it will be by default set to 1000. --- src/back-sch-pam.c | 361 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-sssd.c | 335 ++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch.c | 242 ++++++++++++++++++++++++++++------- src/back-sch.h | 83 ++++++++++++ 4 files changed, 976 insertions(+), 45 deletions(-) create mode 100644 src/back-sch-pam.c create mode 100644 src/back-sch-sssd.c create mode 100644 src/back-sch.h diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c new file mode 100644 index 0000000..3266261 --- /dev/null +++ b/src/back-sch-pam.c @@ -0,0 +1,361 @@ +/** BEGIN COPYRIGHT BLOCK + * 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 the Free Software + * Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along with + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple + * Place, Suite 330, Boston, MA 02111-1307 USA. + * + * In addition, as a special exception, Red Hat, Inc. gives You the additional + * right to link the code of this Program with code not covered under the GNU + * General Public License ("Non-GPL Code") and to distribute linked combinations + * including the two, subject to the limitations in this paragraph. Non-GPL Code + * permitted under this exception must only link to the code of this Program + * through those well defined interfaces identified in the file named EXCEPTION + * found in the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline functions from + * the Approved Interfaces without causing the resulting work to be covered by + * the GNU General Public License. Only Red Hat, Inc. may make changes or + * additions to the list of Approved Interfaces. You must obey the GNU General + * Public License in all respects for all of the Program code and other code used + * in conjunction with the Program except the Non-GPL Code covered by this + * exception. If you modify this file, you may extend this exception to your + * version of the file, but you are not obligated to do so. If you do not wish to + * provide this exception without modification, you must delete this exception + * statement from your version and license this file solely under the GPL without + * exception. + * + * + * Copyright (C) 2005 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + + +#include + +/* + * PAM is not thread safe. We have to execute any PAM API calls in + * a critical section. This is the lock that protects that code. + */ +static Slapi_Mutex *PAMLock = NULL; + +/* Utility struct to wrap strings to avoid mallocs if possible - use + stack allocated string space */ +#define MY_STATIC_BUF_SIZE 256 +typedef struct my_str_buf { + char fixbuf[MY_STATIC_BUF_SIZE]; + char *str; +} MyStrBuf; + +static char * +init_my_str_buf(MyStrBuf *buf, const char *s) +{ + PR_ASSERT(buf); + if (s && (strlen(s) < sizeof(buf->fixbuf))) { + strcpy(buf->fixbuf, s); + buf->str = buf->fixbuf; + } else { + buf->str = slapi_ch_strdup(s); + buf->fixbuf[0] = 0; + } + + return buf->str; +} + +static void +delete_my_str_buf(MyStrBuf *buf) +{ + if (buf->str != buf->fixbuf) { + slapi_ch_free_string(&(buf->str)); + } +} + +/* for third arg to pam_start */ +struct my_pam_conv_str { + Slapi_PBlock *pb; + char *pam_identity; +}; + +/* returns a berval value as a null terminated string */ +static char *strdupbv(struct berval *bv) +{ + char *str = slapi_ch_malloc(bv->bv_len+1); + memcpy(str, bv->bv_val, bv->bv_len); + str[bv->bv_len] = 0; + return str; +} + +static void +free_pam_response(int nresp, struct pam_response *resp) +{ + int ii; + for (ii = 0; ii < nresp; ++ii) { + if (resp[ii].resp) { + slapi_ch_free((void **)&(resp[ii].resp)); + } + } + slapi_ch_free((void **)&resp); +} + +/* + * This is the conversation function passed into pam_start(). This is what sets the password + * that PAM uses to authenticate. This function is sort of stupid - it assumes all echo off + * or binary prompts are for the password, and other prompts are for the username. Time will + * tell if this is actually the case. + */ +static int +pam_conv_func(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *mydata) +{ + int ii; + struct berval *creds; + struct my_pam_conv_str *my_data = (struct my_pam_conv_str *)mydata; + struct pam_response *reply; + int ret = PAM_SUCCESS; + + if (num_msg <= 0) { + return PAM_CONV_ERR; + } + + /* empty reply structure */ + reply = (struct pam_response *)slapi_ch_calloc(num_msg, + sizeof(struct pam_response)); + slapi_pblock_get( my_data->pb, SLAPI_BIND_CREDENTIALS, &creds ); /* the password */ + for (ii = 0; ii < num_msg; ++ii) { + /* hard to tell what prompt is for . . . */ + /* assume prompts for password are either BINARY or ECHO_OFF */ + if (msg[ii]->msg_style == PAM_PROMPT_ECHO_OFF) { + reply[ii].resp = strdupbv(creds); +#ifdef LINUX + } else if (msg[ii]->msg_style == PAM_BINARY_PROMPT) { + reply[ii].resp = strdupbv(creds); +#endif + } else if (msg[ii]->msg_style == PAM_PROMPT_ECHO_ON) { /* assume username */ + reply[ii].resp = slapi_ch_strdup(my_data->pam_identity); + } else if (msg[ii]->msg_style == PAM_ERROR_MSG) { + } else if (msg[ii]->msg_style == PAM_TEXT_INFO) { + } else { + ret = PAM_CONV_ERR; + } + } + + if (ret == PAM_CONV_ERR) { + free_pam_response(num_msg, reply); + reply = NULL; + } + + *resp = reply; + + return ret; +} + +/* + * Do the actual work of authenticating with PAM. First, get the PAM identity + * based on the method used to convert the BIND identity to the PAM identity. + * Set up the structures that pam_start needs and call pam_start(). After + * that, call pam_authenticate and pam_acct_mgmt. Check the various return + * values from these functions and map them to their corresponding LDAP BIND + * return values. Return the appropriate LDAP error code. + * This function will also set the appropriate LDAP response controls in + * the given pblock. + * Since this function can be called multiple times, we only want to return + * the errors and controls to the user if this is the final call, so the + * final_method parameter tells us if this is the last one. Coupled with + * the fallback argument, we can tell if we are able to send the response + * back to the client. + */ +static int +do_pam_auth( + Slapi_PBlock *pb, + char *pam_service, /* name of service for pam_start() */ + int pw_response_requested, /* do we need to send pwd policy resp control */ + Slapi_Entry *entry +) +{ + MyStrBuf pam_id; + const char *binddn = NULL; + Slapi_DN *bindsdn = NULL; + int rc = PAM_SUCCESS; + int retcode = LDAP_SUCCESS; + pam_handle_t *pam_handle; + struct my_pam_conv_str my_data; + struct pam_conv my_pam_conv = {pam_conv_func, NULL}; + char *errmsg = NULL; /* free with PR_smprintf_free */ + + slapi_pblock_get( pb, SLAPI_BIND_TARGET_SDN, &bindsdn ); + if (NULL == bindsdn) { + errmsg = PR_smprintf("Null bind dn"); + retcode = LDAP_OPERATIONS_ERROR; + pam_id.str = NULL; /* initialize pam_id.str */ + goto done; /* skip the pam stuff */ + } + binddn = slapi_sdn_get_dn(bindsdn); + + char *val = slapi_entry_attr_get_charptr(entry, "uid"); + init_my_str_buf(&pam_id, val); + slapi_ch_free_string(&val); + + if (!pam_id.str) { + errmsg = PR_smprintf("Bind DN [%s] is invalid or not found", binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + goto done; /* skip the pam stuff */ + } + + /* do the pam stuff */ + my_data.pb = pb; + my_data.pam_identity = pam_id.str; + my_pam_conv.appdata_ptr = &my_data; + slapi_lock_mutex(PAMLock); + /* from this point on we are in the critical section */ + rc = pam_start(pam_service, pam_id.str, &my_pam_conv, &pam_handle); + + if (rc == PAM_SUCCESS) { + /* use PAM_SILENT - there is no user interaction at this point */ + rc = pam_authenticate(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_MAXTRIES) { + errmsg = PR_smprintf("Authentication retry limit exceeded in PAM for " + "user id [%s], bind DN [%s]", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_CONSTRAINT_VIOLATION; /* max retries */ + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* pam config or network problem */ + } + } + + /* if user authenticated successfully, see if there is anything we need + to report back w.r.t. password or account lockout */ + if (rc == PAM_SUCCESS) { + rc = pam_acct_mgmt(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_PERM_DENIED) { + errmsg = PR_smprintf("Access denied for PAM user id [%s], bind DN [%s]" + " - see administrator", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_UNWILLING_TO_PERFORM; + } else if (rc == PAM_ACCT_EXPIRED) { + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc == PAM_NEW_AUTHTOK_REQD) { /* handled same way as ACCT_EXPIRED */ + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* unknown */ + } + } + + rc = pam_end(pam_handle, rc); + slapi_unlock_mutex(PAMLock); + /* not in critical section any more */ + +done: + delete_my_str_buf(&pam_id); + + if ((retcode == LDAP_SUCCESS) && (rc != PAM_SUCCESS)) { + errmsg = PR_smprintf("Unknown PAM error [%d] for user id [%s], bind DN [%s]", + rc, pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; + } + + if (retcode != LDAP_SUCCESS) { + slapi_send_ldap_result(pb, retcode, NULL, errmsg, 0, NULL); + } + + if (errmsg) { + PR_smprintf_free(errmsg); + } + + return retcode; +} + +/* + * Entry point into the PAM auth code. Shields the rest of the app + * from PAM API code. Get our config params, then call the actual + * code that does the PAM auth. Can call that code up to 3 times, + * depending on what methods are set in the config. + */ +int +backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry) +{ + int rc = LDAP_SUCCESS; + MyStrBuf pam_service; /* avoid malloc if possible */ + int pw_response_requested; + LDAPControl **reqctrls = NULL; + + if (!PAMLock && !(PAMLock = slapi_new_mutex())) { + return LDAP_LOCAL_ERROR; + } + + init_my_str_buf(&pam_service, "system-auth"); + + slapi_pblock_get (pb, SLAPI_REQCONTROLS, &reqctrls); + slapi_pblock_get (pb, SLAPI_PWPOLICY, &pw_response_requested); + + /* figure out which method is the last one - we only return error codes, controls + to the client and send a response on the last method */ + + rc = do_pam_auth(pb, pam_service.str, pw_response_requested, entry); + + delete_my_str_buf(&pam_service); + + return rc; +} diff --git a/src/back-sch-sssd.c b/src/back-sch-sssd.c new file mode 100644 index 0000000..8168675 --- /dev/null +++ b/src/back-sch-sssd.c @@ -0,0 +1,335 @@ +/* + * Copyright 2008,2009,2010,2011,2012 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include + +#include "backend.h" +#include "back-shr.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t name_set; + char *name; +}; + +/* Check simple filter to see if it has + * (cn|uid|uidNumber|gidNumber=) or (objectClass=posixGroup) + * Called by slapi_filter_apply(). */ +static int +backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) +{ + struct backend_search_filter_config *config = arg; + struct berval *bval; + char *filter_type; + int f_choice, rc; + + f_choice = slapi_filter_get_choice(filter); + rc = slapi_filter_get_ava(filter, &filter_type, &bval); + if ((LDAP_FILTER_EQUALITY == f_choice) && (0 == rc)) { + if (0 == strcasecmp(filter_type, "uidNumber")) { + config->search_uid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "gidNumber")) { + config->search_gid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "uid")) { + config->search_user = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "cn")) { + config->name_set = TRUE; + } else if ((0 == strcasecmp(filter_type, "objectClass")) && + (0 == strcasecmp(bval->bv_val, "posixGroup"))) { + config->search_group = TRUE; + } + + if ((NULL == config->name) && config->name_set) { + config->name = bval->bv_val; + } + } + + if ((config->search_uid || + config->search_gid || + config->search_user || + config->search_group) && (config->name != NULL)) { + return SLAPI_FILTER_SCAN_STOP; + } + return SLAPI_FILTER_SCAN_CONTINUE; +} + +static Slapi_Entry * +backend_retrieve_user_entry_from_sssd(char *user_name, bool_t is_uid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct passwd pwd, *result; + Slapi_Entry *entry; + int rc; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_uid) { + rc = getpwuid_r(atoi(user_name), &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getpwnam_r(user_name, &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (pwd.pw_uid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixAccount"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "uid", user_name); + slapi_entry_attr_set_int(entry, + "uidNumber", pwd.pw_uid); + slapi_entry_attr_set_int(entry, + "gidNumber", pwd.pw_gid); + slapi_entry_add_string(entry, + "gecos", pwd.pw_gecos); + if (strlen(pwd.pw_gecos) > 0) { + slapi_entry_add_string(entry, + "cn", pwd.pw_gecos); + } else { + slapi_entry_add_string(entry, + "cn", user_name); + } + + slapi_entry_add_string(entry, + "homeDirectory", pwd.pw_dir); + slapi_entry_add_string(entry, + "loginShell", pwd.pw_shell); + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, slapi_ch_smprintf("uid=%s,%s", + user_name, slapi_sdn_get_dn(set_data->container_sdn))); + + rc = sss_nss_getsidbyid(pwd.pw_uid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTUserAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + + return entry; +} + + +static Slapi_Entry * +backend_retrieve_group_entry_from_sssd(char *group_name, bool_t is_gid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct group grp, *result; + const char *sdn; + Slapi_Entry *entry; + int rc, i; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_gid) { + rc = getgrgid_r(atoi(group_name), &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getgrnam_r(group_name, &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (grp.gr_gid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixGroup"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "cn", group_name); + slapi_entry_attr_set_int(entry, + "gidNumber", grp.gr_gid); + + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, + slapi_ch_smprintf("cn=%s,%s", group_name, + slapi_sdn_get_dn(set_data->container_sdn))); + + if (grp.gr_mem) { + if (set_data->sssd_relevant_set != NULL) { + sdn = slapi_sdn_get_dn(set_data->sssd_relevant_set->container_sdn); + } else { + sdn = slapi_sdn_get_dn(set_data->container_sdn); + } + for (i=0; grp.gr_mem[i]; i++) { + slapi_entry_add_string(entry, "memberUid", + slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); + } + } + + rc = sss_nss_getsidbyid(grp.gr_gid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTGroupAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + return entry; +} + +static void +backend_search_sssd_send_entry(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata, + Slapi_Entry *entry) +{ + char *ndn; + if (entry) { + slapi_entry_add_string(entry, + "schema-compat-origin", "sssd"); + cbdata->matched = TRUE; + ndn = slapi_entry_get_ndn(entry); + backend_set_entry(cbdata->pb, entry, set_data); + slapi_send_ldap_search_entry(cbdata->pb, entry, + NULL, cbdata->attrs, + cbdata->attrsonly); + cbdata->n_entries++; + if (cbdata->closest_match) { + free(cbdata->closest_match); + } + cbdata->closest_match = strdup(ndn); + /* Entry is created, cache it via map. + * Next request will be served from the cache */ + //backend_set_entry(cbdata->pb, entry, set_data); + slapi_entry_free(entry); + } +} + +/* Check filter for a component like (uid=) and if found, + * perform look up against SSSD and create entry based on that */ +void +backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + int result, rc; + Slapi_Entry *entry; + struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + + /* There was no match but we asked to check SSSD */ + /* First, we search the filter to see if it includes cn|uid= check */ + result = slapi_filter_apply(cbdata->filter, + backend_search_filter_has_cn_uid, &config, &rc); + if ((result != SLAPI_FILTER_SCAN_STOP) || + (NULL == config.name)) { + return; + } + + /* Drop irrelevant requests. Each set only works with a single type */ + if ((cbdata->check_sssd == SCH_SSSD_GROUP) && + (config.search_uid || config.search_user)) { + return; + } + + if ((cbdata->check_sssd == SCH_SSSD_USER) && + (config.search_gid || config.search_group)) { + return; + } + + if ((config.search_gid || config.search_uid) && + (atol(config.name) < set_data->sssd_min_id)) { + return; + } + + if ((config.search_group || config.search_gid) && + (NULL != config.name)) { + entry = backend_retrieve_group_entry_from_sssd(config.name, + config.search_gid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + return; + } + + if ((config.search_user || config.search_uid) && + (NULL != config.name)) { + entry = backend_retrieve_user_entry_from_sssd(config.name, + config.search_uid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + } +} diff --git a/src/back-sch.c b/src/back-sch.c index 142bdb9..a235998 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -50,23 +50,10 @@ #include "format.h" #include "plugin.h" #include "map.h" +#include "back-sch.h" #define SCH_CONTAINER_CONFIGURATION_FILTER "(&(" SCH_CONTAINER_CONFIGURATION_GROUP_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_BASE_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_FILTER_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_RDN_ATTR "=*))" -/* The data we ask the map cache to keep, for us, for each set. */ -struct backend_set_data { - struct backend_shr_set_data common; - /* Schema compatibility-specific data. */ - Slapi_DN *container_sdn; - char *rdn_format; - char **attribute_format; - bool_t check_access; -}; -struct backend_entry_data { - Slapi_DN *original_entry_dn; - Slapi_Entry *e; -}; - /* Read the name of the NIS master. A dummy function for the schema * compatibility plugin. */ void @@ -98,9 +85,18 @@ backend_set_config_free_config_contents(void *data) format_free_ref_attr_list(set_data->common.ref_attr_list); format_free_ref_attr_list(set_data->common.inref_attr_list); free(set_data->common.entry_filter); + if (set_data->check_sssd != SCH_SSSD_NONE) { + /* Remove association to another set (groups/users) */ + if ((set_data->sssd_relevant_set != NULL) && + (set_data->sssd_relevant_set->sssd_relevant_set == set_data)) { + set_data->sssd_relevant_set->sssd_relevant_set = NULL; + set_data->sssd_relevant_set = NULL; + } + } slapi_sdn_free(&set_data->container_sdn); free(set_data->rdn_format); backend_shr_free_strlist(set_data->attribute_format); + free(set_data->sssd_buffer); } } void @@ -146,6 +142,12 @@ backend_copy_set_config(const struct backend_set_data *data) ret->rdn_format = strdup(data->rdn_format); ret->attribute_format = backend_shr_dup_strlist(data->attribute_format); ret->check_access = data->check_access; + ret->check_sssd = data->check_sssd; + ret->sssd_min_id = data->sssd_min_id; + ret->sssd_buffer = data->sssd_buffer; + ret->sssd_buffer_len = data->sssd_buffer_len; + ret->sssd_relevant_set = data->sssd_relevant_set; + if ((ret->common.group == NULL) || (ret->common.set == NULL) || (ret->common.bases == NULL) || @@ -164,7 +166,7 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, const char *group, const char *container, bool_t *flag, struct backend_shr_set_data **pret) { - char **bases, *entry_filter, **attributes, *rdn_format, *dn; + char **bases, *entry_filter, **attributes, *rdn_format, *dn, *sssd_min_id, *check_sssd; bool_t check_access; struct backend_set_data ret; Slapi_DN *tmp_sdn; @@ -179,6 +181,10 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, check_access = backend_shr_get_vattr_boolean(state, e, SCH_CONTAINER_CONFIGURATION_ACCESS_ATTR, TRUE); + check_sssd = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_ATTR); + sssd_min_id = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR); attributes = backend_shr_get_vattr_strlist(state, e, SCH_CONTAINER_CONFIGURATION_ATTR_ATTR); /* Populate the returned structure. */ @@ -213,6 +219,51 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, ret.rdn_format = rdn_format; ret.attribute_format = attributes; ret.check_access = check_access; + + if (check_sssd != NULL) { + if (strcasecmp(check_sssd, "group") == 0) { + ret.check_sssd = SCH_SSSD_GROUP; + } else if (strcasecmp(check_sssd, "user") == 0) { + ret.check_sssd = SCH_SSSD_USER; + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + ret.sssd_buffer = NULL; + + /* Make sure we don't return system users/groups + * by limiting lower bound on searches */ + ret.sssd_min_id = 1000; /* default in Fedora */ + if (sssd_min_id != NULL) { + ret.sssd_min_id = atol(sssd_min_id); + } + + if (ret.sssd_min_id == 0) { + /* enforce id in case of an error or too low limit */ + ret.sssd_min_id = 1000; + } + + if (ret.check_sssd != SCH_SSSD_NONE) { + /* Auto-populate attributes based on selected SSSD tree + * and add special attribute to track whether the entry requires PAM-based bind */ + backend_shr_add_strlist(&ret.attribute_format, "objectClass=extensibleObject"); + backend_shr_add_strlist(&ret.attribute_format, "schema-compat-origin=%{schema-compat-origin}"); + backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); + + /* Allocate buffer to be used for getpwnam_r/getgrnam_r requests */ + if (ret.check_sssd == SCH_SSSD_USER) { + ret.sssd_buffer_len = sysconf(_SC_GETPW_R_SIZE_MAX); + } else { + ret.sssd_buffer_len = sysconf(_SC_GETGR_R_SIZE_MAX); + } + if ((long) ret.sssd_buffer_len == -1 ) + ret.sssd_buffer_len = 16384; + ret.sssd_buffer = malloc(ret.sssd_buffer_len); + } + + ret.sssd_relevant_set = NULL; *pret = backend_copy_set_config(&ret); free(ret.common.group); free(ret.common.set); @@ -315,7 +366,7 @@ backend_entry_get_usn(Slapi_PBlock *pb, Slapi_Entry *e, } /* Add operational attributes to a synthetic entry. */ -static void +void backend_set_operational_attributes(Slapi_Entry *e, struct plugin_state *state, time_t timestamp, @@ -879,25 +930,6 @@ backend_update_params(Slapi_PBlock *pb, struct plugin_state *state) slapi_entry_free(our_entry); } -/* Intercept a search request, and if it belongs to one of our compatibility - * trees, answer from our cache before letting the default database have a - * crack at it. */ -struct backend_search_cbdata { - Slapi_PBlock *pb; - struct plugin_state *state; - char *target, *strfilter, **attrs; - int scope, sizelimit, timelimit, attrsonly; - bool_t check_access; - Slapi_DN *target_dn; - Slapi_Filter *filter; - - bool_t answer; - int result; - bool_t matched; - char *closest_match, *text; - int n_entries; -}; - static bool_t backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) { @@ -993,11 +1025,17 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, struct backend_set_data *set_data; Slapi_Entry *set_entry; int result, n_entries; + int n_entries_sssd; const char *ndn; cbdata = cb_data; set_data = backend_data; cbdata->check_access = set_data->check_access; + cbdata->check_sssd = set_data->check_sssd; + cbdata->sssd_min_id = set_data->sssd_min_id; + /* If any entries were actually returned by the descending callback, + * avoid to look up in sssd even if this set is marked to look up */ + n_entries_sssd = cbdata->n_entries; /* Check the set itself, unless it's also the group, in which case we * already evaluated it for this search. */ @@ -1054,6 +1092,15 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, backend_search_entry_cb, cbdata); } +#ifdef HAVE_SSS_NSS_IDMAP + /* If we didn't find an exact match for the entry but asked to look up SSSD, + * then try to search SSSD and if successful, return that entry */ + if ((n_entries_sssd == cbdata->n_entries) && + (cbdata->check_sssd != SCH_SSSD_NONE)) { + backend_search_sssd(set_data, cbdata); + } +#endif + /* If we didn't find an exact match for the entry, then store this * container's DN as the closest match. */ if ((!cbdata->matched) && @@ -1409,6 +1456,7 @@ backend_bind_cb(Slapi_PBlock *pb) struct berval ref; struct berval *urls[] = {&ref, NULL}; const char *ndn; + char *is_sssd_origin = NULL; if (wrap_get_call_level() > 0) { return 0; @@ -1418,18 +1466,59 @@ backend_bind_cb(Slapi_PBlock *pb) map_rdlock(); backend_locate(pb, &data); if (data != NULL) { - ndn = slapi_sdn_get_ndn(data->original_entry_dn); - ref.bv_len = strlen("ldap:///") + strlen(ndn); - ref.bv_val = malloc(ref.bv_len + 1); - if (ref.bv_val != NULL) { - sprintf(ref.bv_val, "ldap:///%s", ndn); - slapi_send_ldap_result(pb, LDAP_REFERRAL, - NULL, NULL, 0, urls); - free(ref.bv_val); +#ifdef HAVE_SSS_NSS_IDMAP + is_sssd_origin = slapi_entry_attr_get_charptr(data->e, "schema-compat-origin"); + if ((is_sssd_origin != NULL) && + (strcasecmp(is_sssd_origin, "sssd") == 0)) { + ret = backend_sch_do_pam_auth(pb, data->e); + if (ret != 0) { + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, + NULL, NULL, 0, NULL); + ret = -1; + } else { + /* + * If bind succeeded, change authentication information associated + * with this connection. + */ + if (ret == LDAP_SUCCESS) { + ndn = slapi_ch_strdup(slapi_sdn_get_ndn(data->original_entry_dn)); + if ((slapi_pblock_set(pb, SLAPI_CONN_DN, (void*)ndn) != 0) || + (slapi_pblock_set(pb, SLAPI_CONN_AUTHMETHOD, SLAPD_AUTH_SIMPLE) != 0)) { + ret = LDAP_OPERATIONS_ERROR; + } else { + LDAPControl **reqctrls = NULL; + slapi_pblock_get(pb, SLAPI_REQCONTROLS, &reqctrls); + if (slapi_control_present(reqctrls, LDAP_CONTROL_AUTH_REQUEST, NULL, NULL)) { + slapi_add_auth_response_control(pb, ndn); + } + } + } + + if (ret == LDAP_SUCCESS) { + /* we are handling the result */ + slapi_send_ldap_result(pb, ret, NULL, NULL, 0, NULL); + /* tell bind code we handled the result */ + ret = 0; + } + } } else { - slapi_send_ldap_result(pb, LDAP_BUSY, - NULL, NULL, 0, NULL); +#endif + ndn = slapi_sdn_get_ndn(data->original_entry_dn); + ref.bv_len = strlen("ldap:///") + strlen(ndn); + ref.bv_val = malloc(ref.bv_len + 1); + if (ref.bv_val != NULL) { + sprintf(ref.bv_val, "ldap:///%s", ndn); + slapi_send_ldap_result(pb, LDAP_REFERRAL, + NULL, NULL, 0, urls); + free(ref.bv_val); + } else { + slapi_send_ldap_result(pb, LDAP_BUSY, + NULL, NULL, 0, NULL); + } +#ifdef HAVE_SSS_NSS_IDMAP } + free(is_sssd_origin); +#endif ret = -1; } else { if (backend_check_scope_pb(pb)) { @@ -1488,11 +1577,74 @@ backend_check_empty(struct plugin_state *state, } } +struct backend_start_fixup_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + struct backend_set_data *groups; + struct backend_set_data *users; +}; + +static bool_t +backend_start_fixup_sssd_cb(const char *group, const char *set, bool_t flag, + void *backend_data, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + struct backend_set_data *set_data; + + cbdata = cb_data; + set_data = backend_data; + + switch (set_data->check_sssd) { + case SCH_SSSD_NONE: + break; + case SCH_SSSD_USER: + cbdata->groups = set_data; + break; + case SCH_SSSD_GROUP: + cbdata->users = set_data; + break; + default: + break; + } + + return TRUE; +} + +static bool_t +backend_start_fixup_cb(const char *group, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + cbdata = cb_data; + map_data_foreach_map(cbdata->state, group, + backend_start_fixup_sssd_cb, cbdata); + if ((cbdata->groups != NULL) && + (cbdata->users != NULL)) { + cbdata->groups->sssd_relevant_set = cbdata->users; + cbdata->users->sssd_relevant_set = cbdata->groups; + } + return TRUE; +} + /* Populate our data cache. */ void backend_startup(Slapi_PBlock *pb, struct plugin_state *state) { + struct backend_start_fixup_cbdata cbdata; backend_shr_startup(state, pb, SCH_CONTAINER_CONFIGURATION_FILTER); + /* Walk the list of groups and perform fixups for the cases where + * some sets depend on others. Right now following fixups are done: + * -- SSSD searches for the group tree should know user tree DN to + * produce proper membership + */ + cbdata.state = state; + cbdata.pb = pb; + cbdata.groups = NULL; + cbdata.users = NULL; + wrap_inc_call_level(); + map_rdlock(); + map_data_foreach_domain(state, backend_start_fixup_cb, &cbdata); + map_unlock(); + wrap_dec_call_level(); } int diff --git a/src/back-sch.h b/src/back-sch.h new file mode 100644 index 0000000..85ea86f --- /dev/null +++ b/src/back-sch.h @@ -0,0 +1,83 @@ +/* + * Copyright 2013 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifndef back_sch_h +#define back_sch_h + +enum sch_search_sssd_t { + SCH_SSSD_NONE = 0, + SCH_SSSD_USER, + SCH_SSSD_GROUP +}; + +/* The data we ask the map cache to keep, for us, for each set. */ +struct backend_set_data { + struct backend_shr_set_data common; + /* Schema compatibility-specific data. */ + Slapi_DN *container_sdn; + char *rdn_format; + char **attribute_format; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + long sssd_min_id; + char *sssd_buffer; + ssize_t sssd_buffer_len; + struct backend_set_data *sssd_relevant_set; +}; + +struct backend_entry_data { + Slapi_DN *original_entry_dn; + Slapi_Entry *e; +}; + +/* Intercept a search request, and if it belongs to one of our compatibility + * trees, answer from our cache before letting the default database have a + * crack at it. */ +struct backend_search_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + char *target, *strfilter, **attrs; + int scope, sizelimit, timelimit, attrsonly; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + Slapi_DN *target_dn; + Slapi_Filter *filter; + long sssd_min_id; + + bool_t answer; + int result; + bool_t matched; + char *closest_match, *text; + int n_entries; +}; + +void backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata); + +void backend_set_operational_attributes(Slapi_Entry *e, + struct plugin_state *state, + time_t timestamp, + int n_subordinates, + const char *usn); +int backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry); + + +#endif -- 1.8.3.1 From simo at redhat.com Mon Jul 15 19:07:26 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 15 Jul 2013 15:07:26 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <51E40DF8.80105@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> Message-ID: <1373915246.30537.400.camel@willson.li.ssimo.org> [..] Removed first part that deals with old matters and keeping only the new part. Comments inline as usual. Simo. On Mon, 2013-07-15 at 16:58 +0200, Petr Spacek wrote: > The remaining part is mostly about key management. > > Following text mentions 'DNSSEC keys' many times, so I tried to summarize how > keys are used in DNSSEC. Feel free to skip it. > > == DNSSEC theory == > > Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, > the first key pair) and Zone Signing Key (ZSK, the second key pair). > > - *Parent* zone contains a copy of public part of the KSK. > - Zone itself contains public part of ZSK (and KSK). > - Client uses public part of KSK (obtained from secure parent zone) for ZSK > verification. > - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG > records) and verification on client side. > > Each key and signature contains key-id, so one zone can be signed by multiple > KSKs and ZSKs at the same time. This solves the key roll over problem. > > Each key contains this set of timestamps: > Created, Revoke - self descriptive :-) > Publish - public part of the key will be visible in zone after this time > Active - new signatures with this key can be generated after this time > Inactive - new signatures with this key cannot be generated after this time > Delete - public part of the key will deleted from the zone after this time > > NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change > in parent zone) and ZSK should be changed ~ each 1-3 months. > > The recommendation says [1] that zone should have two ZSKs: One Active (used > for signature generation) and second only Published (ready for roll over in > case of emergency/when the first key pair expires). This mitigates problems > with caches and stale key material during roll-over. > > BIND 9 can do signature maintenance/ZSK key roll over automatically. It needs > only keys stored in files (with proper timestamps) and all signatures will be > generated & removed when the right time passes. Is there any place I can read about the format and requirements of these files ? > KSK has to be rolled over manually because it requires changes in parent zone. > (It could be automated for sub-zones if their parent zone is also managed by > the same IPA server.) Is there any provision for using DNSSEC with private DNS deployments ? Or is this going to make sense only for IPA deployments that have valid delegation from the public DNS system ? Hmmm I guess that as long as the KSK in the 'parent' zone is imported properly a private deployment of corp.myzone.com using the KSK of myzone.com will work just fine even if corp.myzone.com is not actually delegated but is a private DNS tree ? Or is that incorrect ? > == End of DNSSEC theory == > > > > 1) How will we handle generation of key pairs? How will externally generated > keys be imported? > > Personally, I would start with 'classical' command line utilities like > dnssec-keygen etc. and extend 'ipa' tool to import generated keys. (Import = > read keys from text files and create appropriate attributes to LDAP.) If you mean to do this as part of the ipa-dns-install script or additional script (eg ipa-dnssec-enable) I am fine. I am not ok with asking admins to manually run these commands. > Initial key generation is closely related to the question how should we handle > (periodic) key regeneration? (e.g. "Generate new ZSK each month.") We only really need to generate (or import) the KSK of the parent zone, our code should be able to generate any other key, and sign it. > Is it okay to use normal cron job to handle the key generation? I.e. to call > dnssec-keygen with proper parameters each month and store the result in LDAP? No, the problem is that we need to define 'who' generates the keys. Remember FreeIPA is a multimaster system, we cannot have potentially conflicting cron jobs running on multiple servers. > Or should we teach certmonger to take care of DNSSEC keys? Certmonger would > have to call dnssec-keygen and to do some IPA calls. (I assume that key > parsing and import will be handled by IPA framework.) certmonger might have the same issue as a cronjob, how do we know *which* one of 3 DNS server should run the updating job ? Should we just leave it to chance and the first win ? What if 2 end up trying to create new keys at exactly the same time ? > We can postpone the key management for the first version and just provide > interface for key removal and import from file. Well all this key management will be a FreeIPA issue, from the bind-dyndb-ldap development pov we need to provide the mechanism and can certainly defer the key management part, but we will not be able to offer this feature until that is done. > 2) Second question is how and where keys should be stored. AFAIK BIND 9 > expects that keys will be stored in file system: One key pair as two files in > specified directory. We probably want to store keys in LDAP, as usual. > > My proposal is to represent each key pair by object with new class > idnsDNSSECKey. This 'key pair object' will be stored inside zone container. E.g. > DNS zone = idnsname=ipa.test,cn=dns,dc=ipa,dc=test > Key pair = cn=005+01908,idnsname=ipa.test,cn=dns,dc=ipa,dc=test > > Private key is represented by opaque blob (size ~ 1-2 kiB), so octetString > could be the right syntax: > attributetypes: ( x.x.x.x.x NAME 'idnsSecPrivateKey' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) Is this just a key ? Or does it contain further data ? > Public key can be represented with normal DNSKEY record (size ~ 200-500 B), so > it would be possible to use normal DNSKEY attribute. I see two problems with > this approach: > - DNSKEY record (= attribute) is multi-valued by definition, but only one > public key can be present in a key pair. > - DNSKEY records will be managed automatically by BIND so we don't want to let > users to mess with them directly. DNSKEYRecord attribute is not defined at the > moment and I'm not willing to define it now. > > For these reasons I think that we can define new public key attribute in the > same way as private key attribute: > attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) > > The resulting object class could be: > objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP > top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) Will bind read these attributes ? Or will we have to dump these values into files via bind-dyndb-ldap for bind9 to read them back ? > CN attribute is user readable key name. It could be anything. BIND's syntax > follows (text copied from dnssec-keyfromlabel): > This is an identification string for the key files: String of the form > "Knnnn.+aaa+iiiii": > - nnnn is the key name (zone name) > - aaa is the numeric representation of the algorithm > - iiiii is the key identifier (or footprint) > > Naturally, we can omit leading "K" and zone name, because we know the name > from parent object in the LDAP/DIT. Also, it could be nice to indicate the > type of the key - KSK or ZSK. ack, should we have an explicit attribute that tells us what type it is ? > Attribute idnsSecPrivateKey should be readable only by DNS admins (and DNS > servers :-). I'm not sure if we should make restrict read access even more. Is > there a valid reason for admin to read the blob? I don't know, but admin can > read the file on disk anyway ... One weak reason to allow read by admins would be to allow them to migrate away, but I do not like to put these keys completely unprotected in LDAP. Given bind has a keytab I was thinking we may want to encrypt these keys with the DNS long term key, however this complicates the code slightly in 2 ways: 1. we can have multiple DNS Servers (ie multiple keys) 2. we need to allow for roll-over To simplify the matter we would have to use a 'master key' that encrypts all signing keys and is made available to DNS servers encrypted with their keys. Master key needs to allow for roll over in case it is compromised. But we could deal with it by simply rolling also all DNS keys and encrypting the new ones with the new key. After all if the key was compromised we must assume all DNs signing keys may have been compromised so a full roll-over is necessary. This simplifies the problem because it means we will never need to store the same DNS signing key encrypted with multiple 'master keys'. A master key also allows for easy addition/removal of DNS servers as it needs to be re-encrypted only once when a new DNS is added (or removed and readded), and a server removal is just a delete operation. > From user interface point of view, key pairs are bit hard to deal with. > Private key format is algorithm-dependent, so the only universal way to get > standardized fields like valid-from/active-from/valid-to/revoked timestamps > etc. is to call parser from bind-libs. Are these parsers available in public libs ? Should we add these attributes explicitly in the 'idnsSecKeyPair' objetclass instead and reconstruct the private key file from there ? Or would that risk being incompatibile with a future new key type ? If so should we really split key material in 2 attributes? Or should we rather just load the full file content in a single attribute as an opaque blob ? > 3) How will the configuration be stored? > Parameters are: > - DNSSEC enabled/disabled for one zone or globally - proposal: add a new > boolean attribute idnsSecInlineSigning to zone and global config object why not simply iDNSSECenabled: TRUE/FALSE ? > - NSEC3 parameters - proposal: use standard NSEC3PARAM record in the zone What are these ? > The rest of the configuration options are related to the key management > problem. We need to know: > - how many key pairs (e.g. 2 KSKs, 2 ZSKs) Shouldn't we allow an arbitrary number ? Does bind have strict limits ? > - when (e.g. generate new key pair 30 days before active key expires) probably needs to be tunable. new attribute ? > - of which key types (KSK or ZSK) > - with which algorithms > - with which key lengths > should be generated. Note that we need to store configuration about X KSKs and > Y ZSKs. seem all of these needs to be tunables and require their own attributes ? > Again, we can postpone the key management for the first version. We can certainly postpone certain aspects of key management at least to get development time down to a more quantifiable amount. But we'll not be able to offer DNSSEC support in FreeIPA until there is management. > 4) For future versions - do we plan to add support for PKCS#11 HSMs? BIND 9 > can use OpenSSL for this stuff (somehow), but I didn't look into details. I think this can be certainly postponed unless it may require changes in the schema, in which case we may want to discuss if we need anything in there so that the initial code can be future-proof. > [1] http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf > section 9.3 Generation of Public Key-Private Key Pair (DNSSEC-OP1) page 9-5 > > > Congratulations, you reached end of the text :-) Thanks, excellent write-up as always. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Jul 16 07:20:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Jul 2013 09:20:19 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E4250E.9030201@redhat.com> References: <51B86955.6040905@redhat.com> <2651075.rrIjEanXGt@thinkpad7.brq.redhat.com> <51DEBCD9.6060909@redhat.com> <5042202.0Ad4TN1s9Z@thinkpad7.brq.redhat.com> <51E3F9B1.3000401@redhat.com> <51E3FCAD.8050502@redhat.com> <51E3FFBC.8000809@redhat.com> <1373897712.30537.353.camel@willson.li.ssimo.org> <51E40A18.4010907@redhat.com> <1373905723.30537.371.camel@willson.li.ssimo.org> <51E4250E.9030201@redhat.com> Message-ID: <51E4F433.6030901@redhat.com> On 15.7.2013 18:36, Martin Kosek wrote: > On 07/15/2013 06:28 PM, Simo Sorce wrote: >> On Mon, 2013-07-15 at 16:41 +0200, Petr Spacek wrote: >>> On 15.7.2013 16:15, Simo Sorce wrote: >>>> On Mon, 2013-07-15 at 15:57 +0200, Martin Kosek wrote: >>>>> On 07/15/2013 03:44 PM, Petr Spacek wrote: >>>>>> On 15.7.2013 15:31, Martin Kosek wrote: >>>>>>> On 07/11/2013 05:10 PM, Tomas Babej wrote: >>>>>>>> On Thursday 11 of July 2013 16:10:33 Ana Krivokapic wrote: >>>>>>>> >>>>>>>>> On 07/11/2013 11:20 AM, Tomas Babej wrote: >>>>>>>> >>>>>>>>>> boolean_var = {} >>>>>>>> >>>>>>>>>> - for var in ('persistent_search', 'serial_autoincrement'): >>>>>>>> >>>>>>>>>> + for var in ('serial_autoincrement'): >>>>>>>> >>>>>>>>> This won't work - a one element tuple needs a comma at the end: >>>>>>>> >>>>>>>>> ('serial_autoincrement', ) >>>>>>>> >>>>>>>>>> boolean_var[var] = "yes" if getattr(self, var, False) else "no" >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> self.sub_dict = dict(FQDN=self.fqdn, >>>>>>>> >>>>>>>>>> @@ -607,9 +604,8 @@ class BindInstance(service.Service): >>>>>>>> >>>>>>>>>> SUFFIX=self.suffix, >>>>>>>> >>>>>>>>>> OPTIONAL_NTP=optional_ntp, >>>>>>>> >>>>>>>>>> ZONEMGR=self.zonemgr, >>>>>>>> >>>>>>>>>> - ZONE_REFRESH=self.zone_refresh, >>>>>>>> >>>>>>>>>> IPA_CA_RECORD=ipa_ca, >>>>>>>> >>>>>>>>>> - PERSISTENT_SEARCH=boolean_var['persistent_search'], >>>>>>>> >>>>>>>>>> + PERSISTENT_SEARCH="yes", >>>>>>>> >>>>>>>>>> SERIAL_AUTOINCREMENT=boolean_var['serial_autoincrement'],) >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> But anyway, I think this piece of code is unnecessarily complicated, I >>>>>>>>> don't see >>>>>>>> >>>>>>>>> a need for the 'boolean_var' dict here. I would suggest replacing it with >>>>>>>> >>>>>>>>> something like: >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> serial_autoincrement = "yes" if self.serial_autoincrement else "no" >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> and then pass serial_autoincrement to self.sub_dict = dict(...) >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Attached patch refactored the relevant part of the code. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tomas >>>>>>>> >>>>>>> >>>>>>> Thanks for patches! I am just thinking, should we also hide the respective >>>>>>> option from ipa global DNS configuration? That's idnszonerefresh attribute. >>>>>>> >>>>>>> We may want to mark the attribute as invisible in CLI + remove it from Web UI. >>>>>>> Petr - what is your take on this? Do you plan to remove idnszonerefresh >>>>>>> attribute support in the future (Fedora 20) as persistent search will be >>>>>>> mandatory in that time? >>>>>> >>>>>> Yes, you are right. We completely forgot to web UI. And yes - please remove the >>>>>> option from web UI. >>>>> >>>>> Ok, Tomas please do the changes as proposed above. >>>>> >>>>>> >>>>>> The latest development shows that persistent search will be replaced by RFC >>>>>> 4533 (known as 'syncrepl'), but from user's point of view it doesn't matter. >>>>>> All options related to persistent search and zone_refresh will simply >>>>>> disappear. Syncrepl itself doesn't require explicit configuration. >>>>> >>>>> Ah, so this means that "psearch" option will be also removed from >>>>> bind-dyndb-ldap? In Fedora 19 we just plan to hard-code it to "yes", will that >>>>> cause issues with Fedora 20? Should we already avoid using the "psearch" option >>>>> and assume that bind-dyndb-ldap in Fedora 19 is using persistent search by default? >>>> >>>> Won't the new bind-dyndb-ldap simply ignore the psearch option when it >>>> moves to syncrepl ? >>> >>> I can do it, but I think that cleanest way is to remove the 'psearch' option >>> in upgrade script. >> >> Sure, but if the upgrade, for whatever reason, fails to remove it >> bind-dyndb-ldap should just ignore. >> >>> Another option is to release new bind-dyndb-ldap to Fedora 19 and change >>> default values to 'psearch yes' right now. Do you agree? >> >> Too much churn, I think it is ok to change it when we are done with >> syncrepl and upgrade config, with the fallback failsafe that even if >> upgrade doesn't remove the option bind-dyndb-ldap will simply ignore it. >> >> This will be safer even for people using stuff like cfengine/puppet to >> manage configurations and not realizing we changed the conf on upgrade, >> their confsystems will push again a conf file with psearch yes but >> bnid-dyndb-ldap won't break. >> >> Simo. >> > > Hmm, that's right, it should be safer. Can bind-dyndb-ldap just yell to error > log that there is an unknown configuration option? (if it does not do that > already). Yes, I can do that. Generally, bind-dyndb-ldap refuses to load invalid configuration, but I can handle psearch and related options as special-case (for some small number of releases). I will release version 3.5 before end of this week. I have some small fixes ready so it is worth to release it now. To summarize the discussion - please remove following options from configuration file and LDAP schema: cache_ttl psearch (attribute idnsPersistentSearch in idnsConfigObject) zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) -- Petr^2 Spacek From pspacek at redhat.com Tue Jul 16 08:04:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Jul 2013 10:04:06 +0200 Subject: [Freeipa-devel] [PATCH 0175-0177] Prepare transition from persistent search to RFC 4533 Message-ID: <51E4FE76.4070408@redhat.com> Hello, this patch set changes default configuration to 'psearch yes' and changes README and informational messages accordingly. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0175-Enable-persistent-search-by-default.patch Type: text/x-patch Size: 1945 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0176-Deprecate-cache_ttl-option.patch Type: text/x-patch Size: 833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0177-Add-informational-message-about-transition-to-RFC-45.patch Type: text/x-patch Size: 1124 bytes Desc: not available URL: From pspacek at redhat.com Tue Jul 16 08:13:59 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Jul 2013 10:13:59 +0200 Subject: [Freeipa-devel] [PATCH 0178-0179] Preparation for 3.5 release Message-ID: <51E500C7.6090802@redhat.com> Hello, I plan to release 3.5 as soon as all previous patches are ACKed. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0178-Update-NEWS-file-for-upcoming-3.5-release.patch Type: text/x-patch Size: 880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0179-Bump-NVR-to-3.5.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jul 16 08:52:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 16 Jul 2013 10:52:29 +0200 Subject: [Freeipa-devel] [PATCH] 422-424 Web UI integration tests In-Reply-To: <51DC2E1E.2080005@redhat.com> References: <51C41530.7000300@redhat.com> <51DC2E1E.2080005@redhat.com> Message-ID: <51E509CD.5090401@redhat.com> On 07/09/2013 05:37 PM, Ana Krivokapic wrote: > On 06/21/2013 10:56 AM, Petr Vobornik wrote: >> Sending an initial implementation of Web UI integration tests. The effort is >> documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . >> >> The coverage is not complete but rather basic. Sending it now as this is >> ongoing task. >> >> Currently it tries to open all facets and dialogs and perform >> add,mod,find,delete,add/remove associations for every entity except trusts (to >> be implemented). >> >> First two attached patches are changing Web UI to be little more test-friendly >> - they add some names to element and such. Tests are in the last patch. >> >> https://fedorahosted.org/freeipa/ticket/3744 >> > > I tried setting up and running the new tests, and overall it works really well. > The documentation page is very clear and to the point, and the setup script is > especially handy. Thanks! Thanks for the review, comments bellow, updated patch 424 attached. > > Below are some comments (mostly related to the python code in ui_driver.py). > > - I got whitespace warnings when applying patch 424 > - ui_driver.py:110 - Should be 'except IOError, e', as you use 'e' within the > except clause. > - ui_driver.py:110 - There's too much code in the try block. We should have as > little code as possible in the try block (ideally only the code that could > actually raise the exception). I assume you meant get_driver method on line ~150. The code on line 110 consists of three lines. I've changed the block little bit but I'm not sure that it helped. The issue is that there are 4 calls which can raise the exceptions. Catching them separately would only clutter the code with exception handling. > - ui_driver.py:200 - It says 'single' in the docstring, but the argument name is > 'all'. > - ui_driver.py:205 - Instead of raising ValueError, I would prefer something > like: assert expression, 'expression is missing' > - ui_driver.py:643 - There's a print statement, I assume a leftover from some > debugging. :) > All other mentioned issues should be fixed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0422-Better-automated-test-support.patch Type: text/x-patch Size: 5664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0423-Fix-container-element-in-adder-dialogs.patch Type: text/x-patch Size: 2757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0424-1-Upstream-Web-UI-tests.patch Type: text/x-patch Size: 146353 bytes Desc: not available URL: From jhrozek at redhat.com Tue Jul 16 10:08:30 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Jul 2013 12:08:30 +0200 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130715173003.GF18587@redhat.com> References: <20130715173003.GF18587@redhat.com> Message-ID: <20130716100830.GE9163@hendrix.brq.redhat.com> On Mon, Jul 15, 2013 at 08:30:03PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached please find two patches against slapi-nis 0.47 to serve trusted > domain users and groups to old clients. FreeIPA master needs to be > enabled with this, see my patch 0108 (on freeipa-devel@). > > The patches add both lookup and PAM-based authentication bind for the > users returned by SSSD lookup. > > Here is the logic: > > 0. Configuration is performed by setting > > schema-compat-lookup-sssd: > schema-compat-sssd-min-id: > > in corresponding schema-compat plugin tree (cn=users and cn=groups). > > If schema-compat-sssd-min-id is not set, it will default to 1000. It is > used to filter out attempts to fetch system users (<1000 on Fedora by > default). > > 1. On query, we parse query filter to identify what type of request is > this: user or group lookup and then issue getpwnam_r()/getgrnam_r() and > getsidbyid() for libsss_nss_idmap to fetch all needed information. > > SSSD caches these requests they should be relatively fast. > > 2. Once we served the request, it is cached in schema-compat cache map. > The entry in the cache is currently not expired explicitly but I'm > working on expiring it on wrong authentication -- if PAM stack returns a > response telling there is no such user. > > 3. Authentication bind for cached entries is done via PAM service > 'system-auth'. If HBAC rule 'allow_all' is disabled in FreeIPA, one > needs to create a rule with service 'system-auth' and allow all users to > access it on IPA masters. Since system-auth is never used explicitly by > any application (it is always included through PAM stack and only > top-level PAM service is used to drive the HBAC ruleset), there is no > problem. > > PAM authentication code is taken from pam_passthru DS plugin. We cannot > use it unchanged because pam_passthru expects that LDAP entry will exist > in DS, while it is not true for these synthetic entries representing > trusted domain users. > > On Fedora one needs pam-devel and libsss_nss_idmap-devel to build the > plugin with new functionality. > > -- > / Alexander Bokovoy Hi, so far I've only built the code, testing is next. So far I have some comments about the first patch, see inline: > >From d3433f2033015724fc6580c00d89627afbc06c1d Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Mon, 15 Jul 2013 14:18:52 +0300 > Subject: [PATCH 1/2] configure: add configure checks for sss_idmap and define > attribute to lookup sssd > > If schema compat plugin configuration has 'schema-compat-lookup-sssd: user|group' > then schema compat plugin will perform lookups of users/groups that were not found > in the main store using getpwnam_r()/getgrnam_r() and libsss_idmap library. > > This is special case to support legacy clients. Schema compat plugin in the > case is assumed to be running on FreeIPA master configured with trusts against > Active Directory and SSSD configure as ipa_server_mode = True. > > Additionally, such entries are added to schema compat plugin's map cache and can > be used for authentication purposes. They will use PAM authentication pass-through > to system-auth service. > --- > configure.ac | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > src/Makefile.am | 6 ++++++ > 2 files changed, 54 insertions(+) > > diff --git a/configure.ac b/configure.ac > index 8d7cbe1..4a47d36 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) > AC_SUBST(ASYNCNS_LIBS) > fi > > +AC_ARG_WITH(sss_nss_idmap, > + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), > + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) > +if pkg-config sss_nss_idmap 2> /dev/null ; then > + if test x$use_sss_nss_idmap != xno ; then > + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) > + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > + else > + SSS_NSS_IDMAP_CFLAGS= > + SSS_NSS_IDMAP_LIBS= > + fi > +else > + if test $use_sss_idmap = yes ; then > + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > + else > + SSS_NSS_IDMAP_CFLAGS= > + SSS_NSS_IDMAP_LIBS= > + fi > +fi > +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) > +AC_SUBST(SSS_NSS_IDMAP_CFLAGS) > +AC_SUBST(SSS_NSS_IDMAP_LIBS) > + > +if x$SSS_NSS_IDMAP_LIBS != x ; then I think you should use test or square brackets here, otherwise I'm seeing: checking for SSS_NSS_IDMAP... yes ./configure: line 12952: x-lsss_nss_idmap: command not found > + AC_CHECK_HEADERS(pam.h) I don't see any pam.h in pam-devel RPM. In SSSD we look for security/pam_appl.h > + if test x$ac_cv_header_pam_h = xno ; then > + use_pam=yes > + else > + use_pam=no > + fi > + > + if test $use_pam = yes ; then > + PAM_CFLAGS= > + PAM_LIBS=-lpam > + else > + AC_ERROR([ not found and it is required for SSSD mode]) > + fi > + AC_SUBST(PAM_CFLAGS) > + AC_SUBST(PAM_LIBS) > +fi > + > mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` > mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` > case "$server" in > @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", > attrattr=schema-compat-entry-attribute > AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", > [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) > +sssdattr=schema-compat-lookup-sssd > +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", > + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) > +sssdminidattr=schema-compat-sssd-min-id > +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR,"$sssdminidattr", > + [Define to name of the attribute which is used to define lower bound of IDs (uid or gid) looked up through sssd. Everything below is not considered belonging to trusted domains.]) > + > > maxvalue_attr=nis-max-value-size > AC_DEFINE_UNQUOTED(NIS_PLUGIN_CONFIGURATION_MAXVALUE_ATTR,"$maxvalue_attr", > diff --git a/src/Makefile.am b/src/Makefile.am > index 6c8666b..59b6948 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA > > schemacompat_plugin_la_SOURCES = \ > back-sch.c \ > + back-sch.h \ This file is only added in the second patch, so maybe the whole Makefile.am hunk should be moved there. > backend.h \ > back-shr.c \ > back-shr.h \ > @@ -64,6 +65,11 @@ schemacompat_plugin_la_SOURCES = \ > wrap.h > schemacompat_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(LIBPTHREAD) $(CONFIGURED_LINK_FLAGS) > > +if SSS_NSS_IDMAP > +schemacompat_plugin_la_SOURCES += back-sch-sssd.c back-sch-pam.c > +schemacompat_plugin_la_LIBADD += $(SSS_NSS_IDMAP_LIBS) $(PAM_LIBS) > +endif > + > noinst_LTLIBRARIES = dummy-nis-plugin.la > dummy_nis_plugin_la_SOURCES = \ > disp-nis.c \ > -- > 1.8.3.1 > From mkosek at redhat.com Tue Jul 16 10:22:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Jul 2013 12:22:57 +0200 Subject: [Freeipa-devel] [PATCH] 410-411 Drop selinux subpackage In-Reply-To: <51BF2D86.2010700@redhat.com> References: <51B9C94A.4020507@redhat.com> <51BAFD8F.5050800@redhat.com> <51BF2D86.2010700@redhat.com> Message-ID: <51E51F01.7050907@redhat.com> On 06/17/2013 05:38 PM, Martin Kosek wrote: > On 06/14/2013 01:25 PM, Petr Viktorin wrote: >> On 06/13/2013 03:29 PM, Martin Kosek wrote: >>> All SELinux policy needed by FreeIPA server is now part of the global >>> system SELinux policy which makes the subpackage redundant and slowing >>> down the installation. This patch drops it. >>> >>> Second patch removes /var/cache/ipa/sessions which was redundant. >>> >>> Martin >> >> Works for me, cautious ACK > > The change got also agreed by Rob and Alexander. Let's do it then. > > Pushed to master. > > Martin > I backported and pushed the dropping patches also for ipa-3-2. This backporting effort is done with intent to fix SELinux policy inconsistency issues in Fedora 19, see related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=980635 https://bugzilla.redhat.com/show_bug.cgi?id=979379 These should be fixed in next SELinux policy update along with a FreeIPA 3.2.2 release which is about to be released this week. Martin From abokovoy at redhat.com Tue Jul 16 10:23:41 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Jul 2013 13:23:41 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130716100830.GE9163@hendrix.brq.redhat.com> References: <20130715173003.GF18587@redhat.com> <20130716100830.GE9163@hendrix.brq.redhat.com> Message-ID: <20130716102341.GH18587@redhat.com> Hi! On Tue, 16 Jul 2013, Jakub Hrozek wrote: >> +AC_ARG_WITH(sss_nss_idmap, >> + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), >> + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) >> +if pkg-config sss_nss_idmap 2> /dev/null ; then >> + if test x$use_sss_nss_idmap != xno ; then >> + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) >> + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> + else >> + SSS_NSS_IDMAP_CFLAGS= >> + SSS_NSS_IDMAP_LIBS= >> + fi >> +else >> + if test $use_sss_idmap = yes ; then >> + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> + else >> + SSS_NSS_IDMAP_CFLAGS= >> + SSS_NSS_IDMAP_LIBS= >> + fi >> +fi >> +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) >> +AC_SUBST(SSS_NSS_IDMAP_CFLAGS) >> +AC_SUBST(SSS_NSS_IDMAP_LIBS) >> + >> +if x$SSS_NSS_IDMAP_LIBS != x ; then > >I think you should use test or square brackets here, otherwise I'm >seeing: > >checking for SSS_NSS_IDMAP... yes >./configure: line 12952: x-lsss_nss_idmap: command not found Thanks, added 'test ...' > >> + AC_CHECK_HEADERS(pam.h) > >I don't see any pam.h in pam-devel RPM. In SSSD we look for >security/pam_appl.h Right. Fixed. >> --- a/src/Makefile.am >> +++ b/src/Makefile.am >> @@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA >> >> schemacompat_plugin_la_SOURCES = \ >> back-sch.c \ >> + back-sch.h \ > >This file is only added in the second patch, so maybe the whole >Makefile.am hunk should be moved there. Yes, moved to the second patch. New patchset is attached. -- / Alexander Bokovoy -------------- next part -------------- >From 3e413ce8f71f28b9fd58eb6cd391fd4c3e9cc7fd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 16 Jul 2013 13:17:03 +0300 Subject: [PATCH 1/2] configure: add configure checks for sss_idmap and define attribute to lookup sssd If schema compat plugin configuration has 'schema-compat-lookup-sssd: user|group' then schema compat plugin will perform lookups of users/groups that were not found in the main store using getpwnam_r()/getgrnam_r() and libsss_idmap library. This is special case to support legacy clients. Schema compat plugin in the case is assumed to be running on FreeIPA master configured with trusts against Active Directory and SSSD configure as ipa_server_mode = True. Additionally, such entries are added to schema compat plugin's map cache and can be used for authentication purposes. They will use PAM authentication pass-through to system-auth service. --- configure.ac | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/configure.ac b/configure.ac index 8d7cbe1..aac52e2 100644 --- a/configure.ac +++ b/configure.ac @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) AC_SUBST(ASYNCNS_LIBS) fi +AC_ARG_WITH(sss_nss_idmap, + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) +if pkg-config sss_nss_idmap 2> /dev/null ; then + if test x$use_sss_nss_idmap != xno ; then + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +else + if test $use_sss_idmap = yes ; then + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +fi +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) +AC_SUBST(SSS_NSS_IDMAP_CFLAGS) +AC_SUBST(SSS_NSS_IDMAP_LIBS) + +if test x$SSS_NSS_IDMAP_LIBS != x ; then + AC_CHECK_HEADERS(security/pam_appl.h) + if test x$ac_cv_header_pam_h = xno ; then + use_pam=yes + else + use_pam=no + fi + + if test $use_pam = yes ; then + PAM_CFLAGS= + PAM_LIBS=-lpam + else + AC_ERROR([ not found and it is required for SSSD mode]) + fi + AC_SUBST(PAM_CFLAGS) + AC_SUBST(PAM_LIBS) +fi + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", attrattr=schema-compat-entry-attribute AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) +sssdattr=schema-compat-lookup-sssd +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) +sssdminidattr=schema-compat-sssd-min-id +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR,"$sssdminidattr", + [Define to name of the attribute which is used to define lower bound of IDs (uid or gid) looked up through sssd. Everything below is not considered belonging to trusted domains.]) + maxvalue_attr=nis-max-value-size AC_DEFINE_UNQUOTED(NIS_PLUGIN_CONFIGURATION_MAXVALUE_ATTR,"$maxvalue_attr", -- 1.8.3.1 -------------- next part -------------- >From c22dadee3cbbada2763e364e64669e211c456424 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 16 Jul 2013 13:18:35 +0300 Subject: [PATCH 2/2] schema-compat: add support for querying trusted domain users through SSSD src/back-sch-sssd.c implements interface to query trusted domain users and groups on FreeIPA master server via getpwnam_r(), getgrnam_r(), and libsss_idmap. src/back-sch-pam.c implements PAM authentication for trusted domain users using system-auth system service when running on FreeIPA master server. Schema-compat plugin can be configured to serve trusted domain users and groups through the plugin configuration entry in directory server: schema-compat-lookup-sssd: schema-compat-sssd-min-id: Separate trees should be configured to look up users and groups. If minimal id value is missing, it will be by default set to 1000. --- src/Makefile.am | 6 + src/back-sch-pam.c | 361 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-sssd.c | 335 ++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch.c | 242 ++++++++++++++++++++++++++++------- src/back-sch.h | 83 ++++++++++++ 5 files changed, 982 insertions(+), 45 deletions(-) create mode 100644 src/back-sch-pam.c create mode 100644 src/back-sch-sssd.c create mode 100644 src/back-sch.h diff --git a/src/Makefile.am b/src/Makefile.am index 6c8666b..59b6948 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA schemacompat_plugin_la_SOURCES = \ back-sch.c \ + back-sch.h \ backend.h \ back-shr.c \ back-shr.h \ @@ -64,6 +65,11 @@ schemacompat_plugin_la_SOURCES = \ wrap.h schemacompat_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(LIBPTHREAD) $(CONFIGURED_LINK_FLAGS) +if SSS_NSS_IDMAP +schemacompat_plugin_la_SOURCES += back-sch-sssd.c back-sch-pam.c +schemacompat_plugin_la_LIBADD += $(SSS_NSS_IDMAP_LIBS) $(PAM_LIBS) +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c new file mode 100644 index 0000000..3266261 --- /dev/null +++ b/src/back-sch-pam.c @@ -0,0 +1,361 @@ +/** BEGIN COPYRIGHT BLOCK + * 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 the Free Software + * Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along with + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple + * Place, Suite 330, Boston, MA 02111-1307 USA. + * + * In addition, as a special exception, Red Hat, Inc. gives You the additional + * right to link the code of this Program with code not covered under the GNU + * General Public License ("Non-GPL Code") and to distribute linked combinations + * including the two, subject to the limitations in this paragraph. Non-GPL Code + * permitted under this exception must only link to the code of this Program + * through those well defined interfaces identified in the file named EXCEPTION + * found in the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline functions from + * the Approved Interfaces without causing the resulting work to be covered by + * the GNU General Public License. Only Red Hat, Inc. may make changes or + * additions to the list of Approved Interfaces. You must obey the GNU General + * Public License in all respects for all of the Program code and other code used + * in conjunction with the Program except the Non-GPL Code covered by this + * exception. If you modify this file, you may extend this exception to your + * version of the file, but you are not obligated to do so. If you do not wish to + * provide this exception without modification, you must delete this exception + * statement from your version and license this file solely under the GPL without + * exception. + * + * + * Copyright (C) 2005 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + + +#include + +/* + * PAM is not thread safe. We have to execute any PAM API calls in + * a critical section. This is the lock that protects that code. + */ +static Slapi_Mutex *PAMLock = NULL; + +/* Utility struct to wrap strings to avoid mallocs if possible - use + stack allocated string space */ +#define MY_STATIC_BUF_SIZE 256 +typedef struct my_str_buf { + char fixbuf[MY_STATIC_BUF_SIZE]; + char *str; +} MyStrBuf; + +static char * +init_my_str_buf(MyStrBuf *buf, const char *s) +{ + PR_ASSERT(buf); + if (s && (strlen(s) < sizeof(buf->fixbuf))) { + strcpy(buf->fixbuf, s); + buf->str = buf->fixbuf; + } else { + buf->str = slapi_ch_strdup(s); + buf->fixbuf[0] = 0; + } + + return buf->str; +} + +static void +delete_my_str_buf(MyStrBuf *buf) +{ + if (buf->str != buf->fixbuf) { + slapi_ch_free_string(&(buf->str)); + } +} + +/* for third arg to pam_start */ +struct my_pam_conv_str { + Slapi_PBlock *pb; + char *pam_identity; +}; + +/* returns a berval value as a null terminated string */ +static char *strdupbv(struct berval *bv) +{ + char *str = slapi_ch_malloc(bv->bv_len+1); + memcpy(str, bv->bv_val, bv->bv_len); + str[bv->bv_len] = 0; + return str; +} + +static void +free_pam_response(int nresp, struct pam_response *resp) +{ + int ii; + for (ii = 0; ii < nresp; ++ii) { + if (resp[ii].resp) { + slapi_ch_free((void **)&(resp[ii].resp)); + } + } + slapi_ch_free((void **)&resp); +} + +/* + * This is the conversation function passed into pam_start(). This is what sets the password + * that PAM uses to authenticate. This function is sort of stupid - it assumes all echo off + * or binary prompts are for the password, and other prompts are for the username. Time will + * tell if this is actually the case. + */ +static int +pam_conv_func(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *mydata) +{ + int ii; + struct berval *creds; + struct my_pam_conv_str *my_data = (struct my_pam_conv_str *)mydata; + struct pam_response *reply; + int ret = PAM_SUCCESS; + + if (num_msg <= 0) { + return PAM_CONV_ERR; + } + + /* empty reply structure */ + reply = (struct pam_response *)slapi_ch_calloc(num_msg, + sizeof(struct pam_response)); + slapi_pblock_get( my_data->pb, SLAPI_BIND_CREDENTIALS, &creds ); /* the password */ + for (ii = 0; ii < num_msg; ++ii) { + /* hard to tell what prompt is for . . . */ + /* assume prompts for password are either BINARY or ECHO_OFF */ + if (msg[ii]->msg_style == PAM_PROMPT_ECHO_OFF) { + reply[ii].resp = strdupbv(creds); +#ifdef LINUX + } else if (msg[ii]->msg_style == PAM_BINARY_PROMPT) { + reply[ii].resp = strdupbv(creds); +#endif + } else if (msg[ii]->msg_style == PAM_PROMPT_ECHO_ON) { /* assume username */ + reply[ii].resp = slapi_ch_strdup(my_data->pam_identity); + } else if (msg[ii]->msg_style == PAM_ERROR_MSG) { + } else if (msg[ii]->msg_style == PAM_TEXT_INFO) { + } else { + ret = PAM_CONV_ERR; + } + } + + if (ret == PAM_CONV_ERR) { + free_pam_response(num_msg, reply); + reply = NULL; + } + + *resp = reply; + + return ret; +} + +/* + * Do the actual work of authenticating with PAM. First, get the PAM identity + * based on the method used to convert the BIND identity to the PAM identity. + * Set up the structures that pam_start needs and call pam_start(). After + * that, call pam_authenticate and pam_acct_mgmt. Check the various return + * values from these functions and map them to their corresponding LDAP BIND + * return values. Return the appropriate LDAP error code. + * This function will also set the appropriate LDAP response controls in + * the given pblock. + * Since this function can be called multiple times, we only want to return + * the errors and controls to the user if this is the final call, so the + * final_method parameter tells us if this is the last one. Coupled with + * the fallback argument, we can tell if we are able to send the response + * back to the client. + */ +static int +do_pam_auth( + Slapi_PBlock *pb, + char *pam_service, /* name of service for pam_start() */ + int pw_response_requested, /* do we need to send pwd policy resp control */ + Slapi_Entry *entry +) +{ + MyStrBuf pam_id; + const char *binddn = NULL; + Slapi_DN *bindsdn = NULL; + int rc = PAM_SUCCESS; + int retcode = LDAP_SUCCESS; + pam_handle_t *pam_handle; + struct my_pam_conv_str my_data; + struct pam_conv my_pam_conv = {pam_conv_func, NULL}; + char *errmsg = NULL; /* free with PR_smprintf_free */ + + slapi_pblock_get( pb, SLAPI_BIND_TARGET_SDN, &bindsdn ); + if (NULL == bindsdn) { + errmsg = PR_smprintf("Null bind dn"); + retcode = LDAP_OPERATIONS_ERROR; + pam_id.str = NULL; /* initialize pam_id.str */ + goto done; /* skip the pam stuff */ + } + binddn = slapi_sdn_get_dn(bindsdn); + + char *val = slapi_entry_attr_get_charptr(entry, "uid"); + init_my_str_buf(&pam_id, val); + slapi_ch_free_string(&val); + + if (!pam_id.str) { + errmsg = PR_smprintf("Bind DN [%s] is invalid or not found", binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + goto done; /* skip the pam stuff */ + } + + /* do the pam stuff */ + my_data.pb = pb; + my_data.pam_identity = pam_id.str; + my_pam_conv.appdata_ptr = &my_data; + slapi_lock_mutex(PAMLock); + /* from this point on we are in the critical section */ + rc = pam_start(pam_service, pam_id.str, &my_pam_conv, &pam_handle); + + if (rc == PAM_SUCCESS) { + /* use PAM_SILENT - there is no user interaction at this point */ + rc = pam_authenticate(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_MAXTRIES) { + errmsg = PR_smprintf("Authentication retry limit exceeded in PAM for " + "user id [%s], bind DN [%s]", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_CONSTRAINT_VIOLATION; /* max retries */ + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* pam config or network problem */ + } + } + + /* if user authenticated successfully, see if there is anything we need + to report back w.r.t. password or account lockout */ + if (rc == PAM_SUCCESS) { + rc = pam_acct_mgmt(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_PERM_DENIED) { + errmsg = PR_smprintf("Access denied for PAM user id [%s], bind DN [%s]" + " - see administrator", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_UNWILLING_TO_PERFORM; + } else if (rc == PAM_ACCT_EXPIRED) { + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc == PAM_NEW_AUTHTOK_REQD) { /* handled same way as ACCT_EXPIRED */ + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* unknown */ + } + } + + rc = pam_end(pam_handle, rc); + slapi_unlock_mutex(PAMLock); + /* not in critical section any more */ + +done: + delete_my_str_buf(&pam_id); + + if ((retcode == LDAP_SUCCESS) && (rc != PAM_SUCCESS)) { + errmsg = PR_smprintf("Unknown PAM error [%d] for user id [%s], bind DN [%s]", + rc, pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; + } + + if (retcode != LDAP_SUCCESS) { + slapi_send_ldap_result(pb, retcode, NULL, errmsg, 0, NULL); + } + + if (errmsg) { + PR_smprintf_free(errmsg); + } + + return retcode; +} + +/* + * Entry point into the PAM auth code. Shields the rest of the app + * from PAM API code. Get our config params, then call the actual + * code that does the PAM auth. Can call that code up to 3 times, + * depending on what methods are set in the config. + */ +int +backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry) +{ + int rc = LDAP_SUCCESS; + MyStrBuf pam_service; /* avoid malloc if possible */ + int pw_response_requested; + LDAPControl **reqctrls = NULL; + + if (!PAMLock && !(PAMLock = slapi_new_mutex())) { + return LDAP_LOCAL_ERROR; + } + + init_my_str_buf(&pam_service, "system-auth"); + + slapi_pblock_get (pb, SLAPI_REQCONTROLS, &reqctrls); + slapi_pblock_get (pb, SLAPI_PWPOLICY, &pw_response_requested); + + /* figure out which method is the last one - we only return error codes, controls + to the client and send a response on the last method */ + + rc = do_pam_auth(pb, pam_service.str, pw_response_requested, entry); + + delete_my_str_buf(&pam_service); + + return rc; +} diff --git a/src/back-sch-sssd.c b/src/back-sch-sssd.c new file mode 100644 index 0000000..8168675 --- /dev/null +++ b/src/back-sch-sssd.c @@ -0,0 +1,335 @@ +/* + * Copyright 2008,2009,2010,2011,2012 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include + +#include "backend.h" +#include "back-shr.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t name_set; + char *name; +}; + +/* Check simple filter to see if it has + * (cn|uid|uidNumber|gidNumber=) or (objectClass=posixGroup) + * Called by slapi_filter_apply(). */ +static int +backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) +{ + struct backend_search_filter_config *config = arg; + struct berval *bval; + char *filter_type; + int f_choice, rc; + + f_choice = slapi_filter_get_choice(filter); + rc = slapi_filter_get_ava(filter, &filter_type, &bval); + if ((LDAP_FILTER_EQUALITY == f_choice) && (0 == rc)) { + if (0 == strcasecmp(filter_type, "uidNumber")) { + config->search_uid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "gidNumber")) { + config->search_gid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "uid")) { + config->search_user = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "cn")) { + config->name_set = TRUE; + } else if ((0 == strcasecmp(filter_type, "objectClass")) && + (0 == strcasecmp(bval->bv_val, "posixGroup"))) { + config->search_group = TRUE; + } + + if ((NULL == config->name) && config->name_set) { + config->name = bval->bv_val; + } + } + + if ((config->search_uid || + config->search_gid || + config->search_user || + config->search_group) && (config->name != NULL)) { + return SLAPI_FILTER_SCAN_STOP; + } + return SLAPI_FILTER_SCAN_CONTINUE; +} + +static Slapi_Entry * +backend_retrieve_user_entry_from_sssd(char *user_name, bool_t is_uid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct passwd pwd, *result; + Slapi_Entry *entry; + int rc; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_uid) { + rc = getpwuid_r(atoi(user_name), &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getpwnam_r(user_name, &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (pwd.pw_uid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixAccount"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "uid", user_name); + slapi_entry_attr_set_int(entry, + "uidNumber", pwd.pw_uid); + slapi_entry_attr_set_int(entry, + "gidNumber", pwd.pw_gid); + slapi_entry_add_string(entry, + "gecos", pwd.pw_gecos); + if (strlen(pwd.pw_gecos) > 0) { + slapi_entry_add_string(entry, + "cn", pwd.pw_gecos); + } else { + slapi_entry_add_string(entry, + "cn", user_name); + } + + slapi_entry_add_string(entry, + "homeDirectory", pwd.pw_dir); + slapi_entry_add_string(entry, + "loginShell", pwd.pw_shell); + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, slapi_ch_smprintf("uid=%s,%s", + user_name, slapi_sdn_get_dn(set_data->container_sdn))); + + rc = sss_nss_getsidbyid(pwd.pw_uid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTUserAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + + return entry; +} + + +static Slapi_Entry * +backend_retrieve_group_entry_from_sssd(char *group_name, bool_t is_gid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct group grp, *result; + const char *sdn; + Slapi_Entry *entry; + int rc, i; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_gid) { + rc = getgrgid_r(atoi(group_name), &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getgrnam_r(group_name, &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (grp.gr_gid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixGroup"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "cn", group_name); + slapi_entry_attr_set_int(entry, + "gidNumber", grp.gr_gid); + + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, + slapi_ch_smprintf("cn=%s,%s", group_name, + slapi_sdn_get_dn(set_data->container_sdn))); + + if (grp.gr_mem) { + if (set_data->sssd_relevant_set != NULL) { + sdn = slapi_sdn_get_dn(set_data->sssd_relevant_set->container_sdn); + } else { + sdn = slapi_sdn_get_dn(set_data->container_sdn); + } + for (i=0; grp.gr_mem[i]; i++) { + slapi_entry_add_string(entry, "memberUid", + slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); + } + } + + rc = sss_nss_getsidbyid(grp.gr_gid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTGroupAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + return entry; +} + +static void +backend_search_sssd_send_entry(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata, + Slapi_Entry *entry) +{ + char *ndn; + if (entry) { + slapi_entry_add_string(entry, + "schema-compat-origin", "sssd"); + cbdata->matched = TRUE; + ndn = slapi_entry_get_ndn(entry); + backend_set_entry(cbdata->pb, entry, set_data); + slapi_send_ldap_search_entry(cbdata->pb, entry, + NULL, cbdata->attrs, + cbdata->attrsonly); + cbdata->n_entries++; + if (cbdata->closest_match) { + free(cbdata->closest_match); + } + cbdata->closest_match = strdup(ndn); + /* Entry is created, cache it via map. + * Next request will be served from the cache */ + //backend_set_entry(cbdata->pb, entry, set_data); + slapi_entry_free(entry); + } +} + +/* Check filter for a component like (uid=) and if found, + * perform look up against SSSD and create entry based on that */ +void +backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + int result, rc; + Slapi_Entry *entry; + struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + + /* There was no match but we asked to check SSSD */ + /* First, we search the filter to see if it includes cn|uid= check */ + result = slapi_filter_apply(cbdata->filter, + backend_search_filter_has_cn_uid, &config, &rc); + if ((result != SLAPI_FILTER_SCAN_STOP) || + (NULL == config.name)) { + return; + } + + /* Drop irrelevant requests. Each set only works with a single type */ + if ((cbdata->check_sssd == SCH_SSSD_GROUP) && + (config.search_uid || config.search_user)) { + return; + } + + if ((cbdata->check_sssd == SCH_SSSD_USER) && + (config.search_gid || config.search_group)) { + return; + } + + if ((config.search_gid || config.search_uid) && + (atol(config.name) < set_data->sssd_min_id)) { + return; + } + + if ((config.search_group || config.search_gid) && + (NULL != config.name)) { + entry = backend_retrieve_group_entry_from_sssd(config.name, + config.search_gid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + return; + } + + if ((config.search_user || config.search_uid) && + (NULL != config.name)) { + entry = backend_retrieve_user_entry_from_sssd(config.name, + config.search_uid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + } +} diff --git a/src/back-sch.c b/src/back-sch.c index 142bdb9..a235998 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -50,23 +50,10 @@ #include "format.h" #include "plugin.h" #include "map.h" +#include "back-sch.h" #define SCH_CONTAINER_CONFIGURATION_FILTER "(&(" SCH_CONTAINER_CONFIGURATION_GROUP_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_BASE_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_FILTER_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_RDN_ATTR "=*))" -/* The data we ask the map cache to keep, for us, for each set. */ -struct backend_set_data { - struct backend_shr_set_data common; - /* Schema compatibility-specific data. */ - Slapi_DN *container_sdn; - char *rdn_format; - char **attribute_format; - bool_t check_access; -}; -struct backend_entry_data { - Slapi_DN *original_entry_dn; - Slapi_Entry *e; -}; - /* Read the name of the NIS master. A dummy function for the schema * compatibility plugin. */ void @@ -98,9 +85,18 @@ backend_set_config_free_config_contents(void *data) format_free_ref_attr_list(set_data->common.ref_attr_list); format_free_ref_attr_list(set_data->common.inref_attr_list); free(set_data->common.entry_filter); + if (set_data->check_sssd != SCH_SSSD_NONE) { + /* Remove association to another set (groups/users) */ + if ((set_data->sssd_relevant_set != NULL) && + (set_data->sssd_relevant_set->sssd_relevant_set == set_data)) { + set_data->sssd_relevant_set->sssd_relevant_set = NULL; + set_data->sssd_relevant_set = NULL; + } + } slapi_sdn_free(&set_data->container_sdn); free(set_data->rdn_format); backend_shr_free_strlist(set_data->attribute_format); + free(set_data->sssd_buffer); } } void @@ -146,6 +142,12 @@ backend_copy_set_config(const struct backend_set_data *data) ret->rdn_format = strdup(data->rdn_format); ret->attribute_format = backend_shr_dup_strlist(data->attribute_format); ret->check_access = data->check_access; + ret->check_sssd = data->check_sssd; + ret->sssd_min_id = data->sssd_min_id; + ret->sssd_buffer = data->sssd_buffer; + ret->sssd_buffer_len = data->sssd_buffer_len; + ret->sssd_relevant_set = data->sssd_relevant_set; + if ((ret->common.group == NULL) || (ret->common.set == NULL) || (ret->common.bases == NULL) || @@ -164,7 +166,7 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, const char *group, const char *container, bool_t *flag, struct backend_shr_set_data **pret) { - char **bases, *entry_filter, **attributes, *rdn_format, *dn; + char **bases, *entry_filter, **attributes, *rdn_format, *dn, *sssd_min_id, *check_sssd; bool_t check_access; struct backend_set_data ret; Slapi_DN *tmp_sdn; @@ -179,6 +181,10 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, check_access = backend_shr_get_vattr_boolean(state, e, SCH_CONTAINER_CONFIGURATION_ACCESS_ATTR, TRUE); + check_sssd = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_ATTR); + sssd_min_id = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR); attributes = backend_shr_get_vattr_strlist(state, e, SCH_CONTAINER_CONFIGURATION_ATTR_ATTR); /* Populate the returned structure. */ @@ -213,6 +219,51 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, ret.rdn_format = rdn_format; ret.attribute_format = attributes; ret.check_access = check_access; + + if (check_sssd != NULL) { + if (strcasecmp(check_sssd, "group") == 0) { + ret.check_sssd = SCH_SSSD_GROUP; + } else if (strcasecmp(check_sssd, "user") == 0) { + ret.check_sssd = SCH_SSSD_USER; + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + ret.sssd_buffer = NULL; + + /* Make sure we don't return system users/groups + * by limiting lower bound on searches */ + ret.sssd_min_id = 1000; /* default in Fedora */ + if (sssd_min_id != NULL) { + ret.sssd_min_id = atol(sssd_min_id); + } + + if (ret.sssd_min_id == 0) { + /* enforce id in case of an error or too low limit */ + ret.sssd_min_id = 1000; + } + + if (ret.check_sssd != SCH_SSSD_NONE) { + /* Auto-populate attributes based on selected SSSD tree + * and add special attribute to track whether the entry requires PAM-based bind */ + backend_shr_add_strlist(&ret.attribute_format, "objectClass=extensibleObject"); + backend_shr_add_strlist(&ret.attribute_format, "schema-compat-origin=%{schema-compat-origin}"); + backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); + + /* Allocate buffer to be used for getpwnam_r/getgrnam_r requests */ + if (ret.check_sssd == SCH_SSSD_USER) { + ret.sssd_buffer_len = sysconf(_SC_GETPW_R_SIZE_MAX); + } else { + ret.sssd_buffer_len = sysconf(_SC_GETGR_R_SIZE_MAX); + } + if ((long) ret.sssd_buffer_len == -1 ) + ret.sssd_buffer_len = 16384; + ret.sssd_buffer = malloc(ret.sssd_buffer_len); + } + + ret.sssd_relevant_set = NULL; *pret = backend_copy_set_config(&ret); free(ret.common.group); free(ret.common.set); @@ -315,7 +366,7 @@ backend_entry_get_usn(Slapi_PBlock *pb, Slapi_Entry *e, } /* Add operational attributes to a synthetic entry. */ -static void +void backend_set_operational_attributes(Slapi_Entry *e, struct plugin_state *state, time_t timestamp, @@ -879,25 +930,6 @@ backend_update_params(Slapi_PBlock *pb, struct plugin_state *state) slapi_entry_free(our_entry); } -/* Intercept a search request, and if it belongs to one of our compatibility - * trees, answer from our cache before letting the default database have a - * crack at it. */ -struct backend_search_cbdata { - Slapi_PBlock *pb; - struct plugin_state *state; - char *target, *strfilter, **attrs; - int scope, sizelimit, timelimit, attrsonly; - bool_t check_access; - Slapi_DN *target_dn; - Slapi_Filter *filter; - - bool_t answer; - int result; - bool_t matched; - char *closest_match, *text; - int n_entries; -}; - static bool_t backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) { @@ -993,11 +1025,17 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, struct backend_set_data *set_data; Slapi_Entry *set_entry; int result, n_entries; + int n_entries_sssd; const char *ndn; cbdata = cb_data; set_data = backend_data; cbdata->check_access = set_data->check_access; + cbdata->check_sssd = set_data->check_sssd; + cbdata->sssd_min_id = set_data->sssd_min_id; + /* If any entries were actually returned by the descending callback, + * avoid to look up in sssd even if this set is marked to look up */ + n_entries_sssd = cbdata->n_entries; /* Check the set itself, unless it's also the group, in which case we * already evaluated it for this search. */ @@ -1054,6 +1092,15 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, backend_search_entry_cb, cbdata); } +#ifdef HAVE_SSS_NSS_IDMAP + /* If we didn't find an exact match for the entry but asked to look up SSSD, + * then try to search SSSD and if successful, return that entry */ + if ((n_entries_sssd == cbdata->n_entries) && + (cbdata->check_sssd != SCH_SSSD_NONE)) { + backend_search_sssd(set_data, cbdata); + } +#endif + /* If we didn't find an exact match for the entry, then store this * container's DN as the closest match. */ if ((!cbdata->matched) && @@ -1409,6 +1456,7 @@ backend_bind_cb(Slapi_PBlock *pb) struct berval ref; struct berval *urls[] = {&ref, NULL}; const char *ndn; + char *is_sssd_origin = NULL; if (wrap_get_call_level() > 0) { return 0; @@ -1418,18 +1466,59 @@ backend_bind_cb(Slapi_PBlock *pb) map_rdlock(); backend_locate(pb, &data); if (data != NULL) { - ndn = slapi_sdn_get_ndn(data->original_entry_dn); - ref.bv_len = strlen("ldap:///") + strlen(ndn); - ref.bv_val = malloc(ref.bv_len + 1); - if (ref.bv_val != NULL) { - sprintf(ref.bv_val, "ldap:///%s", ndn); - slapi_send_ldap_result(pb, LDAP_REFERRAL, - NULL, NULL, 0, urls); - free(ref.bv_val); +#ifdef HAVE_SSS_NSS_IDMAP + is_sssd_origin = slapi_entry_attr_get_charptr(data->e, "schema-compat-origin"); + if ((is_sssd_origin != NULL) && + (strcasecmp(is_sssd_origin, "sssd") == 0)) { + ret = backend_sch_do_pam_auth(pb, data->e); + if (ret != 0) { + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, + NULL, NULL, 0, NULL); + ret = -1; + } else { + /* + * If bind succeeded, change authentication information associated + * with this connection. + */ + if (ret == LDAP_SUCCESS) { + ndn = slapi_ch_strdup(slapi_sdn_get_ndn(data->original_entry_dn)); + if ((slapi_pblock_set(pb, SLAPI_CONN_DN, (void*)ndn) != 0) || + (slapi_pblock_set(pb, SLAPI_CONN_AUTHMETHOD, SLAPD_AUTH_SIMPLE) != 0)) { + ret = LDAP_OPERATIONS_ERROR; + } else { + LDAPControl **reqctrls = NULL; + slapi_pblock_get(pb, SLAPI_REQCONTROLS, &reqctrls); + if (slapi_control_present(reqctrls, LDAP_CONTROL_AUTH_REQUEST, NULL, NULL)) { + slapi_add_auth_response_control(pb, ndn); + } + } + } + + if (ret == LDAP_SUCCESS) { + /* we are handling the result */ + slapi_send_ldap_result(pb, ret, NULL, NULL, 0, NULL); + /* tell bind code we handled the result */ + ret = 0; + } + } } else { - slapi_send_ldap_result(pb, LDAP_BUSY, - NULL, NULL, 0, NULL); +#endif + ndn = slapi_sdn_get_ndn(data->original_entry_dn); + ref.bv_len = strlen("ldap:///") + strlen(ndn); + ref.bv_val = malloc(ref.bv_len + 1); + if (ref.bv_val != NULL) { + sprintf(ref.bv_val, "ldap:///%s", ndn); + slapi_send_ldap_result(pb, LDAP_REFERRAL, + NULL, NULL, 0, urls); + free(ref.bv_val); + } else { + slapi_send_ldap_result(pb, LDAP_BUSY, + NULL, NULL, 0, NULL); + } +#ifdef HAVE_SSS_NSS_IDMAP } + free(is_sssd_origin); +#endif ret = -1; } else { if (backend_check_scope_pb(pb)) { @@ -1488,11 +1577,74 @@ backend_check_empty(struct plugin_state *state, } } +struct backend_start_fixup_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + struct backend_set_data *groups; + struct backend_set_data *users; +}; + +static bool_t +backend_start_fixup_sssd_cb(const char *group, const char *set, bool_t flag, + void *backend_data, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + struct backend_set_data *set_data; + + cbdata = cb_data; + set_data = backend_data; + + switch (set_data->check_sssd) { + case SCH_SSSD_NONE: + break; + case SCH_SSSD_USER: + cbdata->groups = set_data; + break; + case SCH_SSSD_GROUP: + cbdata->users = set_data; + break; + default: + break; + } + + return TRUE; +} + +static bool_t +backend_start_fixup_cb(const char *group, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + cbdata = cb_data; + map_data_foreach_map(cbdata->state, group, + backend_start_fixup_sssd_cb, cbdata); + if ((cbdata->groups != NULL) && + (cbdata->users != NULL)) { + cbdata->groups->sssd_relevant_set = cbdata->users; + cbdata->users->sssd_relevant_set = cbdata->groups; + } + return TRUE; +} + /* Populate our data cache. */ void backend_startup(Slapi_PBlock *pb, struct plugin_state *state) { + struct backend_start_fixup_cbdata cbdata; backend_shr_startup(state, pb, SCH_CONTAINER_CONFIGURATION_FILTER); + /* Walk the list of groups and perform fixups for the cases where + * some sets depend on others. Right now following fixups are done: + * -- SSSD searches for the group tree should know user tree DN to + * produce proper membership + */ + cbdata.state = state; + cbdata.pb = pb; + cbdata.groups = NULL; + cbdata.users = NULL; + wrap_inc_call_level(); + map_rdlock(); + map_data_foreach_domain(state, backend_start_fixup_cb, &cbdata); + map_unlock(); + wrap_dec_call_level(); } int diff --git a/src/back-sch.h b/src/back-sch.h new file mode 100644 index 0000000..85ea86f --- /dev/null +++ b/src/back-sch.h @@ -0,0 +1,83 @@ +/* + * Copyright 2013 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifndef back_sch_h +#define back_sch_h + +enum sch_search_sssd_t { + SCH_SSSD_NONE = 0, + SCH_SSSD_USER, + SCH_SSSD_GROUP +}; + +/* The data we ask the map cache to keep, for us, for each set. */ +struct backend_set_data { + struct backend_shr_set_data common; + /* Schema compatibility-specific data. */ + Slapi_DN *container_sdn; + char *rdn_format; + char **attribute_format; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + long sssd_min_id; + char *sssd_buffer; + ssize_t sssd_buffer_len; + struct backend_set_data *sssd_relevant_set; +}; + +struct backend_entry_data { + Slapi_DN *original_entry_dn; + Slapi_Entry *e; +}; + +/* Intercept a search request, and if it belongs to one of our compatibility + * trees, answer from our cache before letting the default database have a + * crack at it. */ +struct backend_search_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + char *target, *strfilter, **attrs; + int scope, sizelimit, timelimit, attrsonly; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + Slapi_DN *target_dn; + Slapi_Filter *filter; + long sssd_min_id; + + bool_t answer; + int result; + bool_t matched; + char *closest_match, *text; + int n_entries; +}; + +void backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata); + +void backend_set_operational_attributes(Slapi_Entry *e, + struct plugin_state *state, + time_t timestamp, + int n_subordinates, + const char *usn); +int backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry); + + +#endif -- 1.8.3.1 From mkosek at redhat.com Tue Jul 16 10:24:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Jul 2013 12:24:00 +0200 Subject: [Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes In-Reply-To: <20130715132751.GC18587@redhat.com> References: <51C31C1F.2040307@redhat.com> <20130708063256.GE3956@redhat.com> <51DD8D93.2040100@redhat.com> <20130711093603.GE18587@redhat.com> <20130711093850.GF18587@redhat.com> <51DEA7DE.70205@redhat.com> <20130711150337.GS18587@redhat.com> <51E3F81D.2090407@redhat.com> <20130715132751.GC18587@redhat.com> Message-ID: <51E51F40.2070505@redhat.com> On 07/15/2013 03:27 PM, Alexander Bokovoy wrote: > On Mon, 15 Jul 2013, Martin Kosek wrote: >> On 07/11/2013 05:03 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Jul 2013, Ana Krivokapic wrote: >>>> On 07/11/2013 11:38 AM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Jul 2013, Alexander Bokovoy wrote: >>>>>> On Wed, 10 Jul 2013, Ana Krivokapic wrote: >>>>>>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Attached patches fix systemd and ipactl related bugs: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3730 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3729 >>>>>>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on >>>>>>>> upgrade properly and everything else has failed afterwards. >>>>>>>> >>>>>>> >>>>>>> This was caused due to 'systemctl is-active' returning exit status 3 >>>>>>> ('activating'), and our code treating the non-zero exit status as a >>>>>>> failure. I >>>>>>> handled this case in the updated patch. >>>>>>> >>>>>>> As for the ipa.service and dependency ordering, I have done some further >>>>>>> testing >>>>>>> and found out the adding the '--ignore-dependencies' switch alone solves >>>>>>> the >>>>>>> shutdown issue. So I think that no modification of ipa.service file is >>>>>>> necessary. >>>>>>> >>>>>>> Updated patches are attached. >>>>>> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and >>>>>> dogtag: >>>>> What's important is the fact that now I can issue reboot and VM >>>>> restarts, not hangs, and then IPA starts properly on boot -- this is >>>>> because when ns-slapd gets a signal from systemd, it automatically shuts >>>>> itself down properly and the same happens to dogtag. This is good >>>>> enough so that I push current patches to master but please proceed on >>>>> fixing 'ipactl stop' issue. >>>>> >>>>> >>>> >>>> Thanks for catching that. I am attaching a patch which should solve this >>>> issue. >>> Works now, I tried stop/start/restart, all processes were properly addressed. >>> >>> Thanks! >>> >> >> Is that an ACK? If yes, please push the patches :-) > It is already in master, I only forgot to respond on the list: > af7807aacc6cf1beb25e53483b54bd599bd6421d Pushed to ipa-3-2 as well. Martin From akrivoka at redhat.com Tue Jul 16 10:33:30 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Jul 2013 12:33:30 +0200 Subject: [Freeipa-devel] [PATCH] 422-424 Web UI integration tests In-Reply-To: <51E509CD.5090401@redhat.com> References: <51C41530.7000300@redhat.com> <51DC2E1E.2080005@redhat.com> <51E509CD.5090401@redhat.com> Message-ID: <51E5217A.3010000@redhat.com> On 07/16/2013 10:52 AM, Petr Vobornik wrote: > On 07/09/2013 05:37 PM, Ana Krivokapic wrote: >> On 06/21/2013 10:56 AM, Petr Vobornik wrote: >>> Sending an initial implementation of Web UI integration tests. The effort is >>> documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . >>> >>> The coverage is not complete but rather basic. Sending it now as this is >>> ongoing task. >>> >>> Currently it tries to open all facets and dialogs and perform >>> add,mod,find,delete,add/remove associations for every entity except trusts (to >>> be implemented). >>> >>> First two attached patches are changing Web UI to be little more test-friendly >>> - they add some names to element and such. Tests are in the last patch. >>> >>> https://fedorahosted.org/freeipa/ticket/3744 >>> > >> >> I tried setting up and running the new tests, and overall it works really well. >> The documentation page is very clear and to the point, and the setup script is >> especially handy. Thanks! > > Thanks for the review, comments bellow, updated patch 424 attached. > >> >> Below are some comments (mostly related to the python code in ui_driver.py). >> >> - I got whitespace warnings when applying patch 424 >> - ui_driver.py:110 - Should be 'except IOError, e', as you use 'e' within the >> except clause. >> - ui_driver.py:110 - There's too much code in the try block. We should have as >> little code as possible in the try block (ideally only the code that could >> actually raise the exception). > > I assume you meant get_driver method on line ~150. The code on line 110 > consists of three lines. I've changed the block little bit but I'm not sure > that it helped. The issue is that there are 4 calls which can raise the > exceptions. Catching them separately would only clutter the code with > exception handling. Yes, that's what I meant. Sorry about the typo. It looks better now, thanks. > >> - ui_driver.py:200 - It says 'single' in the docstring, but the argument name is >> 'all'. >> - ui_driver.py:205 - Instead of raising ValueError, I would prefer something >> like: assert expression, 'expression is missing' >> - ui_driver.py:643 - There's a print statement, I assume a leftover from some >> debugging. :) >> > > All other mentioned issues should be fixed. Just one more nitpick (sorry for not catching it the first time). I don't see a reason for nested ifs here: if browser == 'chrome' or browser == 'chromium': capabilities = DesiredCapabilities.CHROME if browser == 'chromium': capabilities = options.to_capabilities() elif browser == 'ie': capabilities = DesiredCapabilities.INTERNETEXPLORER else: capabilities = DesiredCapabilities.FIREFOX It can be written simply as: if browser == 'chrome': ... elif browser == 'chromium': ... elif browser == 'ie': ... else: ... -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Tue Jul 16 10:35:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Jul 2013 12:35:53 +0200 Subject: [Freeipa-devel] [PATCH 0075] Change group ownership of CRL publish directory In-Reply-To: <51CBF5B5.4000501@redhat.com> References: <51C31C8C.2010200@redhat.com> <51C320E1.4040303@redhat.com> <1371743048.17111.61.camel@willson.li.ssimo.org> <51C3242B.4070604@redhat.com> <1371744027.17111.69.camel@willson.li.ssimo.org> <51C442FD.2000009@redhat.com> <51C443DD.1090202@redhat.com> <51C444AF.3070709@redhat.com> <51CBF5B5.4000501@redhat.com> Message-ID: <51E52209.4050709@redhat.com> On 06/27/2013 10:20 AM, Martin Kosek wrote: > On 06/21/2013 02:18 PM, Tomas Babej wrote: >> On 06/21/2013 02:15 PM, Martin Kosek wrote: >>> On 06/21/2013 02:11 PM, Tomas Babej wrote: >>>> On 06/20/2013 06:00 PM, Simo Sorce wrote: >>>>> On Thu, 2013-06-20 at 17:47 +0200, Martin Kosek wrote: >>>>>> On 06/20/2013 05:44 PM, Simo Sorce wrote: >>>>>>> On Thu, 2013-06-20 at 17:33 +0200, Martin Kosek wrote: >>>>>>>> On 06/20/2013 05:15 PM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Spec file modified so that /var/lib/ipa/pki-ca/publish/ is owned >>>>>>>>> by pkiuser group. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3727 >>>>>>>>> >>>>>>>>> Tomas >>>>>>>>> >>>>>>>> NACK. This won't fly. pkiuser is created by FreeIPA when server is >>>>>>>> installed, >>>>>>>> thus you cannot just simply change ownership in our spec file because in >>>>>>>> the >>>>>>>> time when package is installed or updated, pkiuser may not exist. >>>>>>>> >>>>>>>> I think you need to delete the %attr from spec file and set the correct >>>>>>>> ownership during ipa-{server,ca}-install. When CA is configured, we should >>>>>>>> also >>>>>>>> probably let ipa-upgradeconfig check this directory and amend when >>>>>>>> necessary >>>>>>>> (to fix affected IPA CA instances). >>>>>>> Probably even better to not create the directory via rpm at all, but >>>>>>> make ipa-ca-install create it and remove it when --uninstall is run. >>>>>>> >>>>>>> Simo. >>>>>> This could also work, sure. Could we then at least mark this directory in our >>>>>> spec file as %ghost? So that "rpm -qf /var/lib/ipa/pki-ca/publish/" gives >>>>>> some >>>>>> information? >>>>> I guess so. >>>>> >>>>> Simo. >>>>> >>>> Updated version attached. >>>> >>>> Tomas >>> Looks good by reading (I did not test it), maybe just one nitpick: >>> >>> + root_logger.warning("Error while removing CRL publish " >>> + "directory: %s" % str(e)) >>> >>> This should read: >>> + root_logger.warning("Error while removing CRL publish " >>> + "directory: %s", e) >>> >>> We do not need to format the string before it is really logged and we also do >>> not need to convert it to "str" as we already requested the conversion to >>> string by "%s". >>> >>> Martin >> Fixed. >> >> Tomas > > The patch itself works fine, but there are still SELinux related questions and > concerns which may also affect the patch (currently it does not work with > enforced SELinux). > > I posted them to the relevant Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=976308 > > Martin > I decided not to wait for SELinux bugs to be fixed, the patch will not change when they are fixed anyway. I will deal with them in another patch. So ACK, pushed to master, ipa-3-2. Martin From pvoborni at redhat.com Tue Jul 16 10:54:31 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 16 Jul 2013 12:54:31 +0200 Subject: [Freeipa-devel] [PATCH] 422-424 Web UI integration tests In-Reply-To: <51E5217A.3010000@redhat.com> References: <51C41530.7000300@redhat.com> <51DC2E1E.2080005@redhat.com> <51E509CD.5090401@redhat.com> <51E5217A.3010000@redhat.com> Message-ID: <51E52667.3030000@redhat.com> On 07/16/2013 12:33 PM, Ana Krivokapic wrote: > On 07/16/2013 10:52 AM, Petr Vobornik wrote: >> On 07/09/2013 05:37 PM, Ana Krivokapic wrote: >>> On 06/21/2013 10:56 AM, Petr Vobornik wrote: >>>> Sending an initial implementation of Web UI integration tests. The effort is >>>> documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . >>>> >>>> The coverage is not complete but rather basic. Sending it now as this is >>>> ongoing task. >>>> >>>> Currently it tries to open all facets and dialogs and perform >>>> add,mod,find,delete,add/remove associations for every entity except trusts (to >>>> be implemented). >>>> >>>> First two attached patches are changing Web UI to be little more test-friendly >>>> - they add some names to element and such. Tests are in the last patch. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3744 >>>> >> >>> >>> I tried setting up and running the new tests, and overall it works really well. >>> The documentation page is very clear and to the point, and the setup script is >>> especially handy. Thanks! >> >> Thanks for the review, comments bellow, updated patch 424 attached. >> >>> >>> Below are some comments (mostly related to the python code in ui_driver.py). >>> >>> - I got whitespace warnings when applying patch 424 >>> - ui_driver.py:110 - Should be 'except IOError, e', as you use 'e' within the >>> except clause. >>> - ui_driver.py:110 - There's too much code in the try block. We should have as >>> little code as possible in the try block (ideally only the code that could >>> actually raise the exception). >> >> I assume you meant get_driver method on line ~150. The code on line 110 >> consists of three lines. I've changed the block little bit but I'm not sure >> that it helped. The issue is that there are 4 calls which can raise the >> exceptions. Catching them separately would only clutter the code with >> exception handling. > Yes, that's what I meant. Sorry about the typo. It looks better now, thanks. >> >>> - ui_driver.py:200 - It says 'single' in the docstring, but the argument name is >>> 'all'. >>> - ui_driver.py:205 - Instead of raising ValueError, I would prefer something >>> like: assert expression, 'expression is missing' >>> - ui_driver.py:643 - There's a print statement, I assume a leftover from some >>> debugging. :) >>> >> >> All other mentioned issues should be fixed. > > Just one more nitpick (sorry for not catching it the first time). I don't see a > reason for nested ifs here: > > if browser == 'chrome' or browser == 'chromium': > capabilities = DesiredCapabilities.CHROME > if browser == 'chromium': > capabilities = options.to_capabilities() > elif browser == 'ie': > capabilities = DesiredCapabilities.INTERNETEXPLORER > else: > capabilities = DesiredCapabilities.FIREFOX > > It can be written simply as: > > if browser == 'chrome': > ... > elif browser == 'chromium': > ... > elif browser == 'ie': > ... > else: > ... > You are right. Fixed. Patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0422-Better-automated-test-support.patch Type: text/x-patch Size: 5664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0423-Fix-container-element-in-adder-dialogs.patch Type: text/x-patch Size: 2757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0424-2-Upstream-Web-UI-tests.patch Type: text/x-patch Size: 146322 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jul 16 10:58:47 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Jul 2013 12:58:47 +0200 Subject: [Freeipa-devel] [PATCH] 422-424 Web UI integration tests In-Reply-To: <51E52667.3030000@redhat.com> References: <51C41530.7000300@redhat.com> <51DC2E1E.2080005@redhat.com> <51E509CD.5090401@redhat.com> <51E5217A.3010000@redhat.com> <51E52667.3030000@redhat.com> Message-ID: <51E52767.5090809@redhat.com> On 07/16/2013 12:54 PM, Petr Vobornik wrote: > On 07/16/2013 12:33 PM, Ana Krivokapic wrote: >> On 07/16/2013 10:52 AM, Petr Vobornik wrote: >>> On 07/09/2013 05:37 PM, Ana Krivokapic wrote: >>>> On 06/21/2013 10:56 AM, Petr Vobornik wrote: >>>>> Sending an initial implementation of Web UI integration tests. The effort is >>>>> documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . >>>>> >>>>> The coverage is not complete but rather basic. Sending it now as this is >>>>> ongoing task. >>>>> >>>>> Currently it tries to open all facets and dialogs and perform >>>>> add,mod,find,delete,add/remove associations for every entity except trusts >>>>> (to >>>>> be implemented). >>>>> >>>>> First two attached patches are changing Web UI to be little more >>>>> test-friendly >>>>> - they add some names to element and such. Tests are in the last patch. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3744 >>>>> >>> >>>> >>>> I tried setting up and running the new tests, and overall it works really >>>> well. >>>> The documentation page is very clear and to the point, and the setup script is >>>> especially handy. Thanks! >>> >>> Thanks for the review, comments bellow, updated patch 424 attached. >>> >>>> >>>> Below are some comments (mostly related to the python code in ui_driver.py). >>>> >>>> - I got whitespace warnings when applying patch 424 >>>> - ui_driver.py:110 - Should be 'except IOError, e', as you use 'e' within the >>>> except clause. >>>> - ui_driver.py:110 - There's too much code in the try block. We should have as >>>> little code as possible in the try block (ideally only the code that could >>>> actually raise the exception). >>> >>> I assume you meant get_driver method on line ~150. The code on line 110 >>> consists of three lines. I've changed the block little bit but I'm not sure >>> that it helped. The issue is that there are 4 calls which can raise the >>> exceptions. Catching them separately would only clutter the code with >>> exception handling. >> Yes, that's what I meant. Sorry about the typo. It looks better now, thanks. >>> >>>> - ui_driver.py:200 - It says 'single' in the docstring, but the argument >>>> name is >>>> 'all'. >>>> - ui_driver.py:205 - Instead of raising ValueError, I would prefer something >>>> like: assert expression, 'expression is missing' >>>> - ui_driver.py:643 - There's a print statement, I assume a leftover from some >>>> debugging. :) >>>> >>> >>> All other mentioned issues should be fixed. >> >> Just one more nitpick (sorry for not catching it the first time). I don't see a >> reason for nested ifs here: >> >> if browser == 'chrome' or browser == 'chromium': >> capabilities = DesiredCapabilities.CHROME >> if browser == 'chromium': >> capabilities = options.to_capabilities() >> elif browser == 'ie': >> capabilities = DesiredCapabilities.INTERNETEXPLORER >> else: >> capabilities = DesiredCapabilities.FIREFOX >> >> It can be written simply as: >> >> if browser == 'chrome': >> ... >> elif browser == 'chromium': >> ... >> elif browser == 'ie': >> ... >> else: >> ... >> > > You are right. Fixed. Patch attached. > ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Tue Jul 16 11:03:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Jul 2013 13:03:05 +0200 Subject: [Freeipa-devel] [PATCH] 412 Remove entitlement support In-Reply-To: <20130711150249.GR18587@redhat.com> References: <51C1683B.60308@redhat.com> <51C16C6D.5080700@redhat.com> <51CAD8AF.3090605@redhat.com> <51CC14B4.7020505@redhat.com> <51CC52B6.30908@redhat.com> <20130711150249.GR18587@redhat.com> Message-ID: <51E52869.50501@redhat.com> On 07/11/2013 05:02 PM, Alexander Bokovoy wrote: > On Thu, 27 Jun 2013, Martin Kosek wrote: >> On 06/27/2013 12:32 PM, Jan Cholasta wrote: >>> On 26.6.2013 14:03, Tomas Babej wrote: >>>> On 06/19/2013 10:31 AM, Petr Vobornik wrote: >>>>> On 06/19/2013 10:13 AM, Martin Kosek wrote: >>>>>> Entitlements code was not tested nor supported upstream since >>>>>> version 3.0. Remove the associated code. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3739 >>>>>> >>>>>> ---- >>>>>> >>>>>> As agreed on Triage meeting, I plan to push this patch to ipa-3-2 and >>>>>> master >>>>>> branches. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> >>>>> ACK on Web UI part. >>>> >>>> ACK on the IPA part >>>> >>>> Tomas >>>> >>> >>> ipa-upgradeconfig fails for me when upgrading from version with entitlement >>> plugin to version without entitlement plugin: >>> >>> 2013-06-26T22:22:43Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with >>> options: {'debug': False, 'quiet': True} >>> 2013-06-26T22:22:43Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2013-06-26T22:22:43Z DEBUG importing all plugin modules in >>> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >>> >>> 2013-06-26T22:22:43Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py' >>> 2013-06-26T22:22:43Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, >>> in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-upgradeconfig", line 872, in main >>> api.finalize() >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 674, in >>> finalize >>> self.__do_if_not_done('load_plugins') >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 454, in >>> __do_if_not_done >>> getattr(self, name)() >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 613, in >>> load_plugins >>> self.import_plugins('ipalib') >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 655, in >>> import_plugins >>> __import__(fullname) >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 180, >>> in >>> class entitle(LDAPObject): >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py", line 184, >>> in entitle >>> container_dn = api.env.container_entitlements >>> >>> 2013-06-26T22:22:43Z DEBUG The ipa-upgradeconfig command failed, exception: >>> AttributeError: 'Env' object has no attribute 'container_entitlements' >>> >>> Honza >>> >> >> This happens because we run ipa-upgradeconfig in %post while there was still >> entitlements plugin. I think that clean solution for this plugin (and also for >> other future occurrences of this issue) is to run upgrade/server restart >> process only in %posttrans. >> >> In the end, I iterated to the attached patch. With this spec change, I was able >> to upgrade from FreeIPA 3.2 to current master version without any entitlements >> related upgrade error. >> >> Adding Alexander and Rob to CC to double-check this upgrade-related change, I >> want to be sure I didn't do something stupid. > The patch needed rebase and it also had formatting errors. > I've fixed the patch (attached) and tested it, all works. I see you commited that to master, thanks. I pushed the change also to ipa-3-2 (where entitlements were removed as well). Martin From pvoborni at redhat.com Tue Jul 16 11:24:04 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 16 Jul 2013 13:24:04 +0200 Subject: [Freeipa-devel] [PATCH] 422-424 Web UI integration tests In-Reply-To: <51E52767.5090809@redhat.com> References: <51C41530.7000300@redhat.com> <51DC2E1E.2080005@redhat.com> <51E509CD.5090401@redhat.com> <51E5217A.3010000@redhat.com> <51E52667.3030000@redhat.com> <51E52767.5090809@redhat.com> Message-ID: <51E52D54.1050904@redhat.com> On 07/16/2013 12:58 PM, Ana Krivokapic wrote: > On 07/16/2013 12:54 PM, Petr Vobornik wrote: >> On 07/16/2013 12:33 PM, Ana Krivokapic wrote: >>> On 07/16/2013 10:52 AM, Petr Vobornik wrote: >>>> On 07/09/2013 05:37 PM, Ana Krivokapic wrote: >>>>> On 06/21/2013 10:56 AM, Petr Vobornik wrote: >>>>>> Sending an initial implementation of Web UI integration tests. The effort is >>>>>> documented at http://www.freeipa.org/page/Web_UI_Integration_Tests . >>>>>> >>>>>> The coverage is not complete but rather basic. Sending it now as this is >>>>>> ongoing task. >>>>>> >>>>>> Currently it tries to open all facets and dialogs and perform >>>>>> add,mod,find,delete,add/remove associations for every entity except trusts >>>>>> (to >>>>>> be implemented). >>>>>> >>>>>> First two attached patches are changing Web UI to be little more >>>>>> test-friendly >>>>>> - they add some names to element and such. Tests are in the last patch. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3744 >>>>>> 8><----- >> >> You are right. Fixed. Patch attached. >> > > ACK > Pushed to master. I'll have some additional tests ready soon so I'm leaving the ticket open. -- Petr Vobornik From jcholast at redhat.com Tue Jul 16 12:10:44 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Jul 2013 14:10:44 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51C420AA.4080007@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C1D8BF.8070809@redhat.com> <51C1D9C9.7090002@redhat.com> <51C1DA1A.6040800@redhat.com> <51C1DC78.5020209@redhat.com> <20130619164601.GM24492@redhat.com> <51C1E157.4090308@redhat.com> <20130619165652.GA10478@redhat.com> <51C1F34C.5000805@redhat.com> <51C1F8D7.3070109@redhat.com> <20130619185656.GC10478@redhat.com> <51C2AF68.3020606@redhat.com> <51C2B0D6.1020607@redhat.com> <51C2D954.1030207@redhat.com> <51C2DEF8.1040400@redhat.com> <51C3FDBB.7060902@redhat.com> <51C40182.9000306@redhat.com> <51C420AA.4080007@redhat.com> Message-ID: <51E53844.7030709@redhat.com> On 21.6.2013 11:45, Tomas Babej wrote: > Newly added features: > > - options propagated to plugins > - made plugin content creation more comfortable, now 3 classes of > output are > available (debug, comment, command) > > Now pretty much everything that comes into my mind is addressed, so > please have a look > at the current implementation. The patch needs a rebase. + class AdviceLogger(object): Please don't use nested classes. If you want AdviceLogger to be private-ish, you can rename it to _AdviceLogger. Also I think AdviceLogger is a little bit misleading name, I would prefer AdviceOutput or something like that. Functionally the patch is OK, but I have some second thoughts about the design. I'm not sure if using API plugins is truly the right thing to do, as advises seem to be pretty much orthogonal to the rest of our API. There are some negative side effects, such as initializing the API every time ipa-advise is run, for each and every advice, which takes some time, so there is a short but noticable delay. What are the benefits of using API plugins for this, besides code reuse? (I'm not saying this must be changed, just give it some thought, using something simpler might be better.) Honza -- Jan Cholasta From jhrozek at redhat.com Tue Jul 16 12:09:54 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Jul 2013 14:09:54 +0200 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130716102341.GH18587@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130716100830.GE9163@hendrix.brq.redhat.com> <20130716102341.GH18587@redhat.com> Message-ID: <20130716120954.GI9163@hendrix.brq.redhat.com> On Tue, Jul 16, 2013 at 01:23:41PM +0300, Alexander Bokovoy wrote: > Hi! > > On Tue, 16 Jul 2013, Jakub Hrozek wrote: > >>+AC_ARG_WITH(sss_nss_idmap, > >>+ AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), > >>+ use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) > >>+if pkg-config sss_nss_idmap 2> /dev/null ; then > >>+ if test x$use_sss_nss_idmap != xno ; then > >>+ AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) > >>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > >>+ else > >>+ SSS_NSS_IDMAP_CFLAGS= > >>+ SSS_NSS_IDMAP_LIBS= > >>+ fi > >>+else > >>+ if test $use_sss_idmap = yes ; then > >>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > >>+ else > >>+ SSS_NSS_IDMAP_CFLAGS= > >>+ SSS_NSS_IDMAP_LIBS= > >>+ fi > >>+fi > >>+AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) > >>+AC_SUBST(SSS_NSS_IDMAP_CFLAGS) > >>+AC_SUBST(SSS_NSS_IDMAP_LIBS) > >>+ > >>+if x$SSS_NSS_IDMAP_LIBS != x ; then > > > >I think you should use test or square brackets here, otherwise I'm > >seeing: > > > >checking for SSS_NSS_IDMAP... yes > >./configure: line 12952: x-lsss_nss_idmap: command not found > Thanks, added 'test ...' > > > > >>+ AC_CHECK_HEADERS(pam.h) > > > >I don't see any pam.h in pam-devel RPM. In SSSD we look for > >security/pam_appl.h > Right. Fixed. > > >>--- a/src/Makefile.am > >>+++ b/src/Makefile.am > >>@@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA > >> > >> schemacompat_plugin_la_SOURCES = \ > >> back-sch.c \ > >>+ back-sch.h \ > > > >This file is only added in the second patch, so maybe the whole > >Makefile.am hunk should be moved there. > Yes, moved to the second patch. > > New patchset is attached. > -- > / Alexander Bokovoy Thanks for the changes, one more comment about patch #1: > +if test x$SSS_NSS_IDMAP_LIBS != x ; then > + AC_CHECK_HEADERS(security/pam_appl.h) > + if test x$ac_cv_header_pam_h = xno ; then I think you need to check for ac_cv_header_security_pam_appl_h here. Also the condition seems reversed to me, it was complaining about missing PAM-devel even when I had one. After changing the test to use ac_cv_header_security_pam_appl_h the and reverting the condition configure seems to have worked correctly for me. Here is the git diff I made: diff --git a/configure.ac b/configure.ac index aac52e2..085f51d 100644 --- a/configure.ac +++ b/configure.ac @@ -334,7 +334,7 @@ AC_SUBST(SSS_NSS_IDMAP_LIBS) if test x$SSS_NSS_IDMAP_LIBS != x ; then AC_CHECK_HEADERS(security/pam_appl.h) - if test x$ac_cv_header_pam_h = xno ; then + if test x$ac_cv_header_security_pam_appl_h = xyes ; then use_pam=yes else use_pam=no From jcholast at redhat.com Tue Jul 16 12:14:24 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Jul 2013 14:14:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0244 Integration testing framework In-Reply-To: <51E40AA8.4090607@redhat.com> References: <51A88DA9.806@redhat.com> <51B5E72E.80000@redhat.com> <51B9B824.7030301@redhat.com> <51BB2674.602@redhat.com> <51BB2B8C.9020403@redhat.com> <51BB3A63.3090002@redhat.com> <51C9883C.8030204@redhat.com> <51DD4DAD.7050408@redhat.com> <51DD82CE.3080001@redhat.com> <51DE96C4.8000401@redhat.com> <51E40AA8.4090607@redhat.com> Message-ID: <51E53920.6030006@redhat.com> On 15.7.2013 16:43, Petr Viktorin wrote: > On 07/11/2013 01:28 PM, Jan Cholasta wrote: >> On 10.7.2013 17:50, Petr Viktorin wrote: >>> Yes, I believe that for the integration tests it's better to see what is >>> going on. Both for manual runs, and also this way the information is >>> more easily picked up by CI tools. >> >> It's harder to see what's going on with so much noise IMHO, I would >> prefer less verbose output for manual runs by default. > > On the other hand, the integration tests take too long and without > output they may seem stuck. I'd rather not make that the default. > I'll try to find some balance and make it more easily configurable in > future patches. Thanks. Anyway, it's nothing critical, so don't jump through hoops. >> >>>> Both the tests in test_simple_replication.py fail for me. I suspect it >>>> is because the data isn't replicated fast enough, a little delay >>>> between >>>> user-show and user-add might fix this. >>> >>> Hm, they worked for me. >>> I've added a delay. It seems fragile, I wonder what the proper way to >>> do this would be. >> >> Hmm, the "replica -> master" test still fails for me, even with delay >> increased to 20 s. > > Is there anything in the DS logs? Let me check. > >> Something less fragile than delay would certainly be nice. > > I'll read up on the DS replication docs, and ask for some guidance. Great, thank you. Honza -- Jan Cholasta From abokovoy at redhat.com Tue Jul 16 12:33:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Jul 2013 15:33:49 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130716120954.GI9163@hendrix.brq.redhat.com> References: <20130715173003.GF18587@redhat.com> <20130716100830.GE9163@hendrix.brq.redhat.com> <20130716102341.GH18587@redhat.com> <20130716120954.GI9163@hendrix.brq.redhat.com> Message-ID: <20130716123349.GJ18587@redhat.com> On Tue, 16 Jul 2013, Jakub Hrozek wrote: >On Tue, Jul 16, 2013 at 01:23:41PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> On Tue, 16 Jul 2013, Jakub Hrozek wrote: >> >>+AC_ARG_WITH(sss_nss_idmap, >> >>+ AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), >> >>+ use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) >> >>+if pkg-config sss_nss_idmap 2> /dev/null ; then >> >>+ if test x$use_sss_nss_idmap != xno ; then >> >>+ AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) >> >>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> >>+ else >> >>+ SSS_NSS_IDMAP_CFLAGS= >> >>+ SSS_NSS_IDMAP_LIBS= >> >>+ fi >> >>+else >> >>+ if test $use_sss_idmap = yes ; then >> >>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> >>+ else >> >>+ SSS_NSS_IDMAP_CFLAGS= >> >>+ SSS_NSS_IDMAP_LIBS= >> >>+ fi >> >>+fi >> >>+AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) >> >>+AC_SUBST(SSS_NSS_IDMAP_CFLAGS) >> >>+AC_SUBST(SSS_NSS_IDMAP_LIBS) >> >>+ >> >>+if x$SSS_NSS_IDMAP_LIBS != x ; then >> > >> >I think you should use test or square brackets here, otherwise I'm >> >seeing: >> > >> >checking for SSS_NSS_IDMAP... yes >> >./configure: line 12952: x-lsss_nss_idmap: command not found >> Thanks, added 'test ...' >> >> > >> >>+ AC_CHECK_HEADERS(pam.h) >> > >> >I don't see any pam.h in pam-devel RPM. In SSSD we look for >> >security/pam_appl.h >> Right. Fixed. >> >> >>--- a/src/Makefile.am >> >>+++ b/src/Makefile.am >> >>@@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA >> >> >> >> schemacompat_plugin_la_SOURCES = \ >> >> back-sch.c \ >> >>+ back-sch.h \ >> > >> >This file is only added in the second patch, so maybe the whole >> >Makefile.am hunk should be moved there. >> Yes, moved to the second patch. >> >> New patchset is attached. >> -- >> / Alexander Bokovoy > >Thanks for the changes, one more comment about patch #1: > >> +if test x$SSS_NSS_IDMAP_LIBS != x ; then >> + AC_CHECK_HEADERS(security/pam_appl.h) >> + if test x$ac_cv_header_pam_h = xno ; then > >I think you need to check for ac_cv_header_security_pam_appl_h here. >Also the condition seems reversed to me, it was complaining about >missing PAM-devel even when I had one. > >After changing the test to use ac_cv_header_security_pam_appl_h the >and reverting the condition configure seems to have worked correctly for me. > >Here is the git diff I made: >diff --git a/configure.ac b/configure.ac >index aac52e2..085f51d 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -334,7 +334,7 @@ AC_SUBST(SSS_NSS_IDMAP_LIBS) > > if test x$SSS_NSS_IDMAP_LIBS != x ; then > AC_CHECK_HEADERS(security/pam_appl.h) >- if test x$ac_cv_header_pam_h = xno ; then >+ if test x$ac_cv_header_security_pam_appl_h = xyes ; then > use_pam=yes > else > use_pam=no Thanks! I was too fast :) New patchset is attached, resending all patches to make easier tracking. -- / Alexander Bokovoy -------------- next part -------------- >From 6909b33edbfb30292645f0998b60a4ffb38891dd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 16 Jul 2013 13:17:03 +0300 Subject: [PATCH 1/2] configure: add configure checks for sss_idmap and define attribute to lookup sssd If schema compat plugin configuration has 'schema-compat-lookup-sssd: user|group' then schema compat plugin will perform lookups of users/groups that were not found in the main store using getpwnam_r()/getgrnam_r() and libsss_idmap library. This is special case to support legacy clients. Schema compat plugin in the case is assumed to be running on FreeIPA master configured with trusts against Active Directory and SSSD configure as ipa_server_mode = True. Additionally, such entries are added to schema compat plugin's map cache and can be used for authentication purposes. They will use PAM authentication pass-through to system-auth service. --- configure.ac | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/configure.ac b/configure.ac index 8d7cbe1..085f51d 100644 --- a/configure.ac +++ b/configure.ac @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) AC_SUBST(ASYNCNS_LIBS) fi +AC_ARG_WITH(sss_nss_idmap, + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) +if pkg-config sss_nss_idmap 2> /dev/null ; then + if test x$use_sss_nss_idmap != xno ; then + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +else + if test $use_sss_idmap = yes ; then + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) + else + SSS_NSS_IDMAP_CFLAGS= + SSS_NSS_IDMAP_LIBS= + fi +fi +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) +AC_SUBST(SSS_NSS_IDMAP_CFLAGS) +AC_SUBST(SSS_NSS_IDMAP_LIBS) + +if test x$SSS_NSS_IDMAP_LIBS != x ; then + AC_CHECK_HEADERS(security/pam_appl.h) + if test x$ac_cv_header_security_pam_appl_h = xyes ; then + use_pam=yes + else + use_pam=no + fi + + if test $use_pam = yes ; then + PAM_CFLAGS= + PAM_LIBS=-lpam + else + AC_ERROR([ not found and it is required for SSSD mode]) + fi + AC_SUBST(PAM_CFLAGS) + AC_SUBST(PAM_LIBS) +fi + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", attrattr=schema-compat-entry-attribute AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) +sssdattr=schema-compat-lookup-sssd +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) +sssdminidattr=schema-compat-sssd-min-id +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR,"$sssdminidattr", + [Define to name of the attribute which is used to define lower bound of IDs (uid or gid) looked up through sssd. Everything below is not considered belonging to trusted domains.]) + maxvalue_attr=nis-max-value-size AC_DEFINE_UNQUOTED(NIS_PLUGIN_CONFIGURATION_MAXVALUE_ATTR,"$maxvalue_attr", -- 1.8.3.1 -------------- next part -------------- >From 633c4c92b73efeb3d660b70480108b0db41fa3bd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 16 Jul 2013 13:18:35 +0300 Subject: [PATCH 2/2] schema-compat: add support for querying trusted domain users through SSSD src/back-sch-sssd.c implements interface to query trusted domain users and groups on FreeIPA master server via getpwnam_r(), getgrnam_r(), and libsss_idmap. src/back-sch-pam.c implements PAM authentication for trusted domain users using system-auth system service when running on FreeIPA master server. Schema-compat plugin can be configured to serve trusted domain users and groups through the plugin configuration entry in directory server: schema-compat-lookup-sssd: schema-compat-sssd-min-id: Separate trees should be configured to look up users and groups. If minimal id value is missing, it will be by default set to 1000. --- src/Makefile.am | 6 + src/back-sch-pam.c | 361 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-sssd.c | 335 ++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch.c | 242 ++++++++++++++++++++++++++++------- src/back-sch.h | 83 ++++++++++++ 5 files changed, 982 insertions(+), 45 deletions(-) create mode 100644 src/back-sch-pam.c create mode 100644 src/back-sch-sssd.c create mode 100644 src/back-sch.h diff --git a/src/Makefile.am b/src/Makefile.am index 6c8666b..59b6948 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA schemacompat_plugin_la_SOURCES = \ back-sch.c \ + back-sch.h \ backend.h \ back-shr.c \ back-shr.h \ @@ -64,6 +65,11 @@ schemacompat_plugin_la_SOURCES = \ wrap.h schemacompat_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(LIBPTHREAD) $(CONFIGURED_LINK_FLAGS) +if SSS_NSS_IDMAP +schemacompat_plugin_la_SOURCES += back-sch-sssd.c back-sch-pam.c +schemacompat_plugin_la_LIBADD += $(SSS_NSS_IDMAP_LIBS) $(PAM_LIBS) +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c new file mode 100644 index 0000000..3266261 --- /dev/null +++ b/src/back-sch-pam.c @@ -0,0 +1,361 @@ +/** BEGIN COPYRIGHT BLOCK + * 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 the Free Software + * Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along with + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple + * Place, Suite 330, Boston, MA 02111-1307 USA. + * + * In addition, as a special exception, Red Hat, Inc. gives You the additional + * right to link the code of this Program with code not covered under the GNU + * General Public License ("Non-GPL Code") and to distribute linked combinations + * including the two, subject to the limitations in this paragraph. Non-GPL Code + * permitted under this exception must only link to the code of this Program + * through those well defined interfaces identified in the file named EXCEPTION + * found in the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline functions from + * the Approved Interfaces without causing the resulting work to be covered by + * the GNU General Public License. Only Red Hat, Inc. may make changes or + * additions to the list of Approved Interfaces. You must obey the GNU General + * Public License in all respects for all of the Program code and other code used + * in conjunction with the Program except the Non-GPL Code covered by this + * exception. If you modify this file, you may extend this exception to your + * version of the file, but you are not obligated to do so. If you do not wish to + * provide this exception without modification, you must delete this exception + * statement from your version and license this file solely under the GPL without + * exception. + * + * + * Copyright (C) 2005 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + + +#include + +/* + * PAM is not thread safe. We have to execute any PAM API calls in + * a critical section. This is the lock that protects that code. + */ +static Slapi_Mutex *PAMLock = NULL; + +/* Utility struct to wrap strings to avoid mallocs if possible - use + stack allocated string space */ +#define MY_STATIC_BUF_SIZE 256 +typedef struct my_str_buf { + char fixbuf[MY_STATIC_BUF_SIZE]; + char *str; +} MyStrBuf; + +static char * +init_my_str_buf(MyStrBuf *buf, const char *s) +{ + PR_ASSERT(buf); + if (s && (strlen(s) < sizeof(buf->fixbuf))) { + strcpy(buf->fixbuf, s); + buf->str = buf->fixbuf; + } else { + buf->str = slapi_ch_strdup(s); + buf->fixbuf[0] = 0; + } + + return buf->str; +} + +static void +delete_my_str_buf(MyStrBuf *buf) +{ + if (buf->str != buf->fixbuf) { + slapi_ch_free_string(&(buf->str)); + } +} + +/* for third arg to pam_start */ +struct my_pam_conv_str { + Slapi_PBlock *pb; + char *pam_identity; +}; + +/* returns a berval value as a null terminated string */ +static char *strdupbv(struct berval *bv) +{ + char *str = slapi_ch_malloc(bv->bv_len+1); + memcpy(str, bv->bv_val, bv->bv_len); + str[bv->bv_len] = 0; + return str; +} + +static void +free_pam_response(int nresp, struct pam_response *resp) +{ + int ii; + for (ii = 0; ii < nresp; ++ii) { + if (resp[ii].resp) { + slapi_ch_free((void **)&(resp[ii].resp)); + } + } + slapi_ch_free((void **)&resp); +} + +/* + * This is the conversation function passed into pam_start(). This is what sets the password + * that PAM uses to authenticate. This function is sort of stupid - it assumes all echo off + * or binary prompts are for the password, and other prompts are for the username. Time will + * tell if this is actually the case. + */ +static int +pam_conv_func(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *mydata) +{ + int ii; + struct berval *creds; + struct my_pam_conv_str *my_data = (struct my_pam_conv_str *)mydata; + struct pam_response *reply; + int ret = PAM_SUCCESS; + + if (num_msg <= 0) { + return PAM_CONV_ERR; + } + + /* empty reply structure */ + reply = (struct pam_response *)slapi_ch_calloc(num_msg, + sizeof(struct pam_response)); + slapi_pblock_get( my_data->pb, SLAPI_BIND_CREDENTIALS, &creds ); /* the password */ + for (ii = 0; ii < num_msg; ++ii) { + /* hard to tell what prompt is for . . . */ + /* assume prompts for password are either BINARY or ECHO_OFF */ + if (msg[ii]->msg_style == PAM_PROMPT_ECHO_OFF) { + reply[ii].resp = strdupbv(creds); +#ifdef LINUX + } else if (msg[ii]->msg_style == PAM_BINARY_PROMPT) { + reply[ii].resp = strdupbv(creds); +#endif + } else if (msg[ii]->msg_style == PAM_PROMPT_ECHO_ON) { /* assume username */ + reply[ii].resp = slapi_ch_strdup(my_data->pam_identity); + } else if (msg[ii]->msg_style == PAM_ERROR_MSG) { + } else if (msg[ii]->msg_style == PAM_TEXT_INFO) { + } else { + ret = PAM_CONV_ERR; + } + } + + if (ret == PAM_CONV_ERR) { + free_pam_response(num_msg, reply); + reply = NULL; + } + + *resp = reply; + + return ret; +} + +/* + * Do the actual work of authenticating with PAM. First, get the PAM identity + * based on the method used to convert the BIND identity to the PAM identity. + * Set up the structures that pam_start needs and call pam_start(). After + * that, call pam_authenticate and pam_acct_mgmt. Check the various return + * values from these functions and map them to their corresponding LDAP BIND + * return values. Return the appropriate LDAP error code. + * This function will also set the appropriate LDAP response controls in + * the given pblock. + * Since this function can be called multiple times, we only want to return + * the errors and controls to the user if this is the final call, so the + * final_method parameter tells us if this is the last one. Coupled with + * the fallback argument, we can tell if we are able to send the response + * back to the client. + */ +static int +do_pam_auth( + Slapi_PBlock *pb, + char *pam_service, /* name of service for pam_start() */ + int pw_response_requested, /* do we need to send pwd policy resp control */ + Slapi_Entry *entry +) +{ + MyStrBuf pam_id; + const char *binddn = NULL; + Slapi_DN *bindsdn = NULL; + int rc = PAM_SUCCESS; + int retcode = LDAP_SUCCESS; + pam_handle_t *pam_handle; + struct my_pam_conv_str my_data; + struct pam_conv my_pam_conv = {pam_conv_func, NULL}; + char *errmsg = NULL; /* free with PR_smprintf_free */ + + slapi_pblock_get( pb, SLAPI_BIND_TARGET_SDN, &bindsdn ); + if (NULL == bindsdn) { + errmsg = PR_smprintf("Null bind dn"); + retcode = LDAP_OPERATIONS_ERROR; + pam_id.str = NULL; /* initialize pam_id.str */ + goto done; /* skip the pam stuff */ + } + binddn = slapi_sdn_get_dn(bindsdn); + + char *val = slapi_entry_attr_get_charptr(entry, "uid"); + init_my_str_buf(&pam_id, val); + slapi_ch_free_string(&val); + + if (!pam_id.str) { + errmsg = PR_smprintf("Bind DN [%s] is invalid or not found", binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + goto done; /* skip the pam stuff */ + } + + /* do the pam stuff */ + my_data.pb = pb; + my_data.pam_identity = pam_id.str; + my_pam_conv.appdata_ptr = &my_data; + slapi_lock_mutex(PAMLock); + /* from this point on we are in the critical section */ + rc = pam_start(pam_service, pam_id.str, &my_pam_conv, &pam_handle); + + if (rc == PAM_SUCCESS) { + /* use PAM_SILENT - there is no user interaction at this point */ + rc = pam_authenticate(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_MAXTRIES) { + errmsg = PR_smprintf("Authentication retry limit exceeded in PAM for " + "user id [%s], bind DN [%s]", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_CONSTRAINT_VIOLATION; /* max retries */ + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* pam config or network problem */ + } + } + + /* if user authenticated successfully, see if there is anything we need + to report back w.r.t. password or account lockout */ + if (rc == PAM_SUCCESS) { + rc = pam_acct_mgmt(pam_handle, 0); + /* check different types of errors here */ + if (rc == PAM_USER_UNKNOWN) { + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", + pam_id.str, binddn); + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ + } else if (rc == PAM_AUTH_ERR) { + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", + pam_id.str, binddn); + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ + } else if (rc == PAM_PERM_DENIED) { + errmsg = PR_smprintf("Access denied for PAM user id [%s], bind DN [%s]" + " - see administrator", + pam_id.str, binddn); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); + } + retcode = LDAP_UNWILLING_TO_PERFORM; + } else if (rc == PAM_ACCT_EXPIRED) { + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc == PAM_NEW_AUTHTOK_REQD) { /* handled same way as ACCT_EXPIRED */ + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " + "reset required", + pam_id.str, binddn); + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); + if (pw_response_requested) { + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); + } + retcode = LDAP_INVALID_CREDENTIALS; + } else if (rc != PAM_SUCCESS) { + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", + pam_strerror(pam_handle, rc), pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; /* unknown */ + } + } + + rc = pam_end(pam_handle, rc); + slapi_unlock_mutex(PAMLock); + /* not in critical section any more */ + +done: + delete_my_str_buf(&pam_id); + + if ((retcode == LDAP_SUCCESS) && (rc != PAM_SUCCESS)) { + errmsg = PR_smprintf("Unknown PAM error [%d] for user id [%s], bind DN [%s]", + rc, pam_id.str, binddn); + retcode = LDAP_OPERATIONS_ERROR; + } + + if (retcode != LDAP_SUCCESS) { + slapi_send_ldap_result(pb, retcode, NULL, errmsg, 0, NULL); + } + + if (errmsg) { + PR_smprintf_free(errmsg); + } + + return retcode; +} + +/* + * Entry point into the PAM auth code. Shields the rest of the app + * from PAM API code. Get our config params, then call the actual + * code that does the PAM auth. Can call that code up to 3 times, + * depending on what methods are set in the config. + */ +int +backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry) +{ + int rc = LDAP_SUCCESS; + MyStrBuf pam_service; /* avoid malloc if possible */ + int pw_response_requested; + LDAPControl **reqctrls = NULL; + + if (!PAMLock && !(PAMLock = slapi_new_mutex())) { + return LDAP_LOCAL_ERROR; + } + + init_my_str_buf(&pam_service, "system-auth"); + + slapi_pblock_get (pb, SLAPI_REQCONTROLS, &reqctrls); + slapi_pblock_get (pb, SLAPI_PWPOLICY, &pw_response_requested); + + /* figure out which method is the last one - we only return error codes, controls + to the client and send a response on the last method */ + + rc = do_pam_auth(pb, pam_service.str, pw_response_requested, entry); + + delete_my_str_buf(&pam_service); + + return rc; +} diff --git a/src/back-sch-sssd.c b/src/back-sch-sssd.c new file mode 100644 index 0000000..8168675 --- /dev/null +++ b/src/back-sch-sssd.c @@ -0,0 +1,335 @@ +/* + * Copyright 2008,2009,2010,2011,2012 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include + +#include "backend.h" +#include "back-shr.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t name_set; + char *name; +}; + +/* Check simple filter to see if it has + * (cn|uid|uidNumber|gidNumber=) or (objectClass=posixGroup) + * Called by slapi_filter_apply(). */ +static int +backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) +{ + struct backend_search_filter_config *config = arg; + struct berval *bval; + char *filter_type; + int f_choice, rc; + + f_choice = slapi_filter_get_choice(filter); + rc = slapi_filter_get_ava(filter, &filter_type, &bval); + if ((LDAP_FILTER_EQUALITY == f_choice) && (0 == rc)) { + if (0 == strcasecmp(filter_type, "uidNumber")) { + config->search_uid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "gidNumber")) { + config->search_gid = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "uid")) { + config->search_user = TRUE; + config->name_set = TRUE; + } else if (0 == strcasecmp(filter_type, "cn")) { + config->name_set = TRUE; + } else if ((0 == strcasecmp(filter_type, "objectClass")) && + (0 == strcasecmp(bval->bv_val, "posixGroup"))) { + config->search_group = TRUE; + } + + if ((NULL == config->name) && config->name_set) { + config->name = bval->bv_val; + } + } + + if ((config->search_uid || + config->search_gid || + config->search_user || + config->search_group) && (config->name != NULL)) { + return SLAPI_FILTER_SCAN_STOP; + } + return SLAPI_FILTER_SCAN_CONTINUE; +} + +static Slapi_Entry * +backend_retrieve_user_entry_from_sssd(char *user_name, bool_t is_uid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct passwd pwd, *result; + Slapi_Entry *entry; + int rc; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_uid) { + rc = getpwuid_r(atoi(user_name), &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getpwnam_r(user_name, &pwd, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (pwd.pw_uid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixAccount"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "uid", user_name); + slapi_entry_attr_set_int(entry, + "uidNumber", pwd.pw_uid); + slapi_entry_attr_set_int(entry, + "gidNumber", pwd.pw_gid); + slapi_entry_add_string(entry, + "gecos", pwd.pw_gecos); + if (strlen(pwd.pw_gecos) > 0) { + slapi_entry_add_string(entry, + "cn", pwd.pw_gecos); + } else { + slapi_entry_add_string(entry, + "cn", user_name); + } + + slapi_entry_add_string(entry, + "homeDirectory", pwd.pw_dir); + slapi_entry_add_string(entry, + "loginShell", pwd.pw_shell); + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, slapi_ch_smprintf("uid=%s,%s", + user_name, slapi_sdn_get_dn(set_data->container_sdn))); + + rc = sss_nss_getsidbyid(pwd.pw_uid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTUserAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + + return entry; +} + + +static Slapi_Entry * +backend_retrieve_group_entry_from_sssd(char *group_name, bool_t is_gid, + struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + struct group grp, *result; + const char *sdn; + Slapi_Entry *entry; + int rc, i; + enum sss_id_type id_type; + char *sid_str; + + if (set_data->sssd_buffer == NULL) { + return NULL; + } + + if (is_gid) { + rc = getgrgid_r(atoi(group_name), &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } else { + rc = getgrnam_r(group_name, &grp, + set_data->sssd_buffer, + set_data->sssd_buffer_len, &result); + } + if ((result == NULL) || (rc != 0)) { + return NULL; + } + + if (grp.gr_gid < cbdata->sssd_min_id) { + return NULL; + } + + entry = slapi_entry_alloc(); + if (entry == NULL) { + return NULL; + } + + slapi_entry_add_string(entry, + "objectClass", "top"); + slapi_entry_add_string(entry, + "objectClass", "posixGroup"); + slapi_entry_add_string(entry, + "objectClass", "extensibleObject"); + slapi_entry_add_string(entry, + "cn", group_name); + slapi_entry_attr_set_int(entry, + "gidNumber", grp.gr_gid); + + slapi_entry_set_sdn(entry, set_data->container_sdn); + slapi_entry_set_dn(entry, + slapi_ch_smprintf("cn=%s,%s", group_name, + slapi_sdn_get_dn(set_data->container_sdn))); + + if (grp.gr_mem) { + if (set_data->sssd_relevant_set != NULL) { + sdn = slapi_sdn_get_dn(set_data->sssd_relevant_set->container_sdn); + } else { + sdn = slapi_sdn_get_dn(set_data->container_sdn); + } + for (i=0; grp.gr_mem[i]; i++) { + slapi_entry_add_string(entry, "memberUid", + slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); + } + } + + rc = sss_nss_getsidbyid(grp.gr_gid, &sid_str, &id_type); + if ((rc == 0) && (sid_str != NULL)) { + slapi_entry_add_string(entry, "objectClass", "ipaNTGroupAttrs"); + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); + free(sid_str); + } + + return entry; +} + +static void +backend_search_sssd_send_entry(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata, + Slapi_Entry *entry) +{ + char *ndn; + if (entry) { + slapi_entry_add_string(entry, + "schema-compat-origin", "sssd"); + cbdata->matched = TRUE; + ndn = slapi_entry_get_ndn(entry); + backend_set_entry(cbdata->pb, entry, set_data); + slapi_send_ldap_search_entry(cbdata->pb, entry, + NULL, cbdata->attrs, + cbdata->attrsonly); + cbdata->n_entries++; + if (cbdata->closest_match) { + free(cbdata->closest_match); + } + cbdata->closest_match = strdup(ndn); + /* Entry is created, cache it via map. + * Next request will be served from the cache */ + //backend_set_entry(cbdata->pb, entry, set_data); + slapi_entry_free(entry); + } +} + +/* Check filter for a component like (uid=) and if found, + * perform look up against SSSD and create entry based on that */ +void +backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata) +{ + int result, rc; + Slapi_Entry *entry; + struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + + /* There was no match but we asked to check SSSD */ + /* First, we search the filter to see if it includes cn|uid= check */ + result = slapi_filter_apply(cbdata->filter, + backend_search_filter_has_cn_uid, &config, &rc); + if ((result != SLAPI_FILTER_SCAN_STOP) || + (NULL == config.name)) { + return; + } + + /* Drop irrelevant requests. Each set only works with a single type */ + if ((cbdata->check_sssd == SCH_SSSD_GROUP) && + (config.search_uid || config.search_user)) { + return; + } + + if ((cbdata->check_sssd == SCH_SSSD_USER) && + (config.search_gid || config.search_group)) { + return; + } + + if ((config.search_gid || config.search_uid) && + (atol(config.name) < set_data->sssd_min_id)) { + return; + } + + if ((config.search_group || config.search_gid) && + (NULL != config.name)) { + entry = backend_retrieve_group_entry_from_sssd(config.name, + config.search_gid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + return; + } + + if ((config.search_user || config.search_uid) && + (NULL != config.name)) { + entry = backend_retrieve_user_entry_from_sssd(config.name, + config.search_uid, set_data, cbdata); + backend_search_sssd_send_entry(set_data, cbdata, entry); + } +} diff --git a/src/back-sch.c b/src/back-sch.c index 142bdb9..a235998 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -50,23 +50,10 @@ #include "format.h" #include "plugin.h" #include "map.h" +#include "back-sch.h" #define SCH_CONTAINER_CONFIGURATION_FILTER "(&(" SCH_CONTAINER_CONFIGURATION_GROUP_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_BASE_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_FILTER_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_RDN_ATTR "=*))" -/* The data we ask the map cache to keep, for us, for each set. */ -struct backend_set_data { - struct backend_shr_set_data common; - /* Schema compatibility-specific data. */ - Slapi_DN *container_sdn; - char *rdn_format; - char **attribute_format; - bool_t check_access; -}; -struct backend_entry_data { - Slapi_DN *original_entry_dn; - Slapi_Entry *e; -}; - /* Read the name of the NIS master. A dummy function for the schema * compatibility plugin. */ void @@ -98,9 +85,18 @@ backend_set_config_free_config_contents(void *data) format_free_ref_attr_list(set_data->common.ref_attr_list); format_free_ref_attr_list(set_data->common.inref_attr_list); free(set_data->common.entry_filter); + if (set_data->check_sssd != SCH_SSSD_NONE) { + /* Remove association to another set (groups/users) */ + if ((set_data->sssd_relevant_set != NULL) && + (set_data->sssd_relevant_set->sssd_relevant_set == set_data)) { + set_data->sssd_relevant_set->sssd_relevant_set = NULL; + set_data->sssd_relevant_set = NULL; + } + } slapi_sdn_free(&set_data->container_sdn); free(set_data->rdn_format); backend_shr_free_strlist(set_data->attribute_format); + free(set_data->sssd_buffer); } } void @@ -146,6 +142,12 @@ backend_copy_set_config(const struct backend_set_data *data) ret->rdn_format = strdup(data->rdn_format); ret->attribute_format = backend_shr_dup_strlist(data->attribute_format); ret->check_access = data->check_access; + ret->check_sssd = data->check_sssd; + ret->sssd_min_id = data->sssd_min_id; + ret->sssd_buffer = data->sssd_buffer; + ret->sssd_buffer_len = data->sssd_buffer_len; + ret->sssd_relevant_set = data->sssd_relevant_set; + if ((ret->common.group == NULL) || (ret->common.set == NULL) || (ret->common.bases == NULL) || @@ -164,7 +166,7 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, const char *group, const char *container, bool_t *flag, struct backend_shr_set_data **pret) { - char **bases, *entry_filter, **attributes, *rdn_format, *dn; + char **bases, *entry_filter, **attributes, *rdn_format, *dn, *sssd_min_id, *check_sssd; bool_t check_access; struct backend_set_data ret; Slapi_DN *tmp_sdn; @@ -179,6 +181,10 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, check_access = backend_shr_get_vattr_boolean(state, e, SCH_CONTAINER_CONFIGURATION_ACCESS_ATTR, TRUE); + check_sssd = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_ATTR); + sssd_min_id = backend_shr_get_vattr_str(state, e, + SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR); attributes = backend_shr_get_vattr_strlist(state, e, SCH_CONTAINER_CONFIGURATION_ATTR_ATTR); /* Populate the returned structure. */ @@ -213,6 +219,51 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, ret.rdn_format = rdn_format; ret.attribute_format = attributes; ret.check_access = check_access; + + if (check_sssd != NULL) { + if (strcasecmp(check_sssd, "group") == 0) { + ret.check_sssd = SCH_SSSD_GROUP; + } else if (strcasecmp(check_sssd, "user") == 0) { + ret.check_sssd = SCH_SSSD_USER; + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + } else { + ret.check_sssd = SCH_SSSD_NONE; + } + ret.sssd_buffer = NULL; + + /* Make sure we don't return system users/groups + * by limiting lower bound on searches */ + ret.sssd_min_id = 1000; /* default in Fedora */ + if (sssd_min_id != NULL) { + ret.sssd_min_id = atol(sssd_min_id); + } + + if (ret.sssd_min_id == 0) { + /* enforce id in case of an error or too low limit */ + ret.sssd_min_id = 1000; + } + + if (ret.check_sssd != SCH_SSSD_NONE) { + /* Auto-populate attributes based on selected SSSD tree + * and add special attribute to track whether the entry requires PAM-based bind */ + backend_shr_add_strlist(&ret.attribute_format, "objectClass=extensibleObject"); + backend_shr_add_strlist(&ret.attribute_format, "schema-compat-origin=%{schema-compat-origin}"); + backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); + + /* Allocate buffer to be used for getpwnam_r/getgrnam_r requests */ + if (ret.check_sssd == SCH_SSSD_USER) { + ret.sssd_buffer_len = sysconf(_SC_GETPW_R_SIZE_MAX); + } else { + ret.sssd_buffer_len = sysconf(_SC_GETGR_R_SIZE_MAX); + } + if ((long) ret.sssd_buffer_len == -1 ) + ret.sssd_buffer_len = 16384; + ret.sssd_buffer = malloc(ret.sssd_buffer_len); + } + + ret.sssd_relevant_set = NULL; *pret = backend_copy_set_config(&ret); free(ret.common.group); free(ret.common.set); @@ -315,7 +366,7 @@ backend_entry_get_usn(Slapi_PBlock *pb, Slapi_Entry *e, } /* Add operational attributes to a synthetic entry. */ -static void +void backend_set_operational_attributes(Slapi_Entry *e, struct plugin_state *state, time_t timestamp, @@ -879,25 +930,6 @@ backend_update_params(Slapi_PBlock *pb, struct plugin_state *state) slapi_entry_free(our_entry); } -/* Intercept a search request, and if it belongs to one of our compatibility - * trees, answer from our cache before letting the default database have a - * crack at it. */ -struct backend_search_cbdata { - Slapi_PBlock *pb; - struct plugin_state *state; - char *target, *strfilter, **attrs; - int scope, sizelimit, timelimit, attrsonly; - bool_t check_access; - Slapi_DN *target_dn; - Slapi_Filter *filter; - - bool_t answer; - int result; - bool_t matched; - char *closest_match, *text; - int n_entries; -}; - static bool_t backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) { @@ -993,11 +1025,17 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, struct backend_set_data *set_data; Slapi_Entry *set_entry; int result, n_entries; + int n_entries_sssd; const char *ndn; cbdata = cb_data; set_data = backend_data; cbdata->check_access = set_data->check_access; + cbdata->check_sssd = set_data->check_sssd; + cbdata->sssd_min_id = set_data->sssd_min_id; + /* If any entries were actually returned by the descending callback, + * avoid to look up in sssd even if this set is marked to look up */ + n_entries_sssd = cbdata->n_entries; /* Check the set itself, unless it's also the group, in which case we * already evaluated it for this search. */ @@ -1054,6 +1092,15 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, backend_search_entry_cb, cbdata); } +#ifdef HAVE_SSS_NSS_IDMAP + /* If we didn't find an exact match for the entry but asked to look up SSSD, + * then try to search SSSD and if successful, return that entry */ + if ((n_entries_sssd == cbdata->n_entries) && + (cbdata->check_sssd != SCH_SSSD_NONE)) { + backend_search_sssd(set_data, cbdata); + } +#endif + /* If we didn't find an exact match for the entry, then store this * container's DN as the closest match. */ if ((!cbdata->matched) && @@ -1409,6 +1456,7 @@ backend_bind_cb(Slapi_PBlock *pb) struct berval ref; struct berval *urls[] = {&ref, NULL}; const char *ndn; + char *is_sssd_origin = NULL; if (wrap_get_call_level() > 0) { return 0; @@ -1418,18 +1466,59 @@ backend_bind_cb(Slapi_PBlock *pb) map_rdlock(); backend_locate(pb, &data); if (data != NULL) { - ndn = slapi_sdn_get_ndn(data->original_entry_dn); - ref.bv_len = strlen("ldap:///") + strlen(ndn); - ref.bv_val = malloc(ref.bv_len + 1); - if (ref.bv_val != NULL) { - sprintf(ref.bv_val, "ldap:///%s", ndn); - slapi_send_ldap_result(pb, LDAP_REFERRAL, - NULL, NULL, 0, urls); - free(ref.bv_val); +#ifdef HAVE_SSS_NSS_IDMAP + is_sssd_origin = slapi_entry_attr_get_charptr(data->e, "schema-compat-origin"); + if ((is_sssd_origin != NULL) && + (strcasecmp(is_sssd_origin, "sssd") == 0)) { + ret = backend_sch_do_pam_auth(pb, data->e); + if (ret != 0) { + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, + NULL, NULL, 0, NULL); + ret = -1; + } else { + /* + * If bind succeeded, change authentication information associated + * with this connection. + */ + if (ret == LDAP_SUCCESS) { + ndn = slapi_ch_strdup(slapi_sdn_get_ndn(data->original_entry_dn)); + if ((slapi_pblock_set(pb, SLAPI_CONN_DN, (void*)ndn) != 0) || + (slapi_pblock_set(pb, SLAPI_CONN_AUTHMETHOD, SLAPD_AUTH_SIMPLE) != 0)) { + ret = LDAP_OPERATIONS_ERROR; + } else { + LDAPControl **reqctrls = NULL; + slapi_pblock_get(pb, SLAPI_REQCONTROLS, &reqctrls); + if (slapi_control_present(reqctrls, LDAP_CONTROL_AUTH_REQUEST, NULL, NULL)) { + slapi_add_auth_response_control(pb, ndn); + } + } + } + + if (ret == LDAP_SUCCESS) { + /* we are handling the result */ + slapi_send_ldap_result(pb, ret, NULL, NULL, 0, NULL); + /* tell bind code we handled the result */ + ret = 0; + } + } } else { - slapi_send_ldap_result(pb, LDAP_BUSY, - NULL, NULL, 0, NULL); +#endif + ndn = slapi_sdn_get_ndn(data->original_entry_dn); + ref.bv_len = strlen("ldap:///") + strlen(ndn); + ref.bv_val = malloc(ref.bv_len + 1); + if (ref.bv_val != NULL) { + sprintf(ref.bv_val, "ldap:///%s", ndn); + slapi_send_ldap_result(pb, LDAP_REFERRAL, + NULL, NULL, 0, urls); + free(ref.bv_val); + } else { + slapi_send_ldap_result(pb, LDAP_BUSY, + NULL, NULL, 0, NULL); + } +#ifdef HAVE_SSS_NSS_IDMAP } + free(is_sssd_origin); +#endif ret = -1; } else { if (backend_check_scope_pb(pb)) { @@ -1488,11 +1577,74 @@ backend_check_empty(struct plugin_state *state, } } +struct backend_start_fixup_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + struct backend_set_data *groups; + struct backend_set_data *users; +}; + +static bool_t +backend_start_fixup_sssd_cb(const char *group, const char *set, bool_t flag, + void *backend_data, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + struct backend_set_data *set_data; + + cbdata = cb_data; + set_data = backend_data; + + switch (set_data->check_sssd) { + case SCH_SSSD_NONE: + break; + case SCH_SSSD_USER: + cbdata->groups = set_data; + break; + case SCH_SSSD_GROUP: + cbdata->users = set_data; + break; + default: + break; + } + + return TRUE; +} + +static bool_t +backend_start_fixup_cb(const char *group, void *cb_data) +{ + struct backend_start_fixup_cbdata *cbdata; + cbdata = cb_data; + map_data_foreach_map(cbdata->state, group, + backend_start_fixup_sssd_cb, cbdata); + if ((cbdata->groups != NULL) && + (cbdata->users != NULL)) { + cbdata->groups->sssd_relevant_set = cbdata->users; + cbdata->users->sssd_relevant_set = cbdata->groups; + } + return TRUE; +} + /* Populate our data cache. */ void backend_startup(Slapi_PBlock *pb, struct plugin_state *state) { + struct backend_start_fixup_cbdata cbdata; backend_shr_startup(state, pb, SCH_CONTAINER_CONFIGURATION_FILTER); + /* Walk the list of groups and perform fixups for the cases where + * some sets depend on others. Right now following fixups are done: + * -- SSSD searches for the group tree should know user tree DN to + * produce proper membership + */ + cbdata.state = state; + cbdata.pb = pb; + cbdata.groups = NULL; + cbdata.users = NULL; + wrap_inc_call_level(); + map_rdlock(); + map_data_foreach_domain(state, backend_start_fixup_cb, &cbdata); + map_unlock(); + wrap_dec_call_level(); } int diff --git a/src/back-sch.h b/src/back-sch.h new file mode 100644 index 0000000..85ea86f --- /dev/null +++ b/src/back-sch.h @@ -0,0 +1,83 @@ +/* + * Copyright 2013 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 + * the Free Software Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifndef back_sch_h +#define back_sch_h + +enum sch_search_sssd_t { + SCH_SSSD_NONE = 0, + SCH_SSSD_USER, + SCH_SSSD_GROUP +}; + +/* The data we ask the map cache to keep, for us, for each set. */ +struct backend_set_data { + struct backend_shr_set_data common; + /* Schema compatibility-specific data. */ + Slapi_DN *container_sdn; + char *rdn_format; + char **attribute_format; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + long sssd_min_id; + char *sssd_buffer; + ssize_t sssd_buffer_len; + struct backend_set_data *sssd_relevant_set; +}; + +struct backend_entry_data { + Slapi_DN *original_entry_dn; + Slapi_Entry *e; +}; + +/* Intercept a search request, and if it belongs to one of our compatibility + * trees, answer from our cache before letting the default database have a + * crack at it. */ +struct backend_search_cbdata { + Slapi_PBlock *pb; + struct plugin_state *state; + char *target, *strfilter, **attrs; + int scope, sizelimit, timelimit, attrsonly; + bool_t check_access; + enum sch_search_sssd_t check_sssd; + Slapi_DN *target_dn; + Slapi_Filter *filter; + long sssd_min_id; + + bool_t answer; + int result; + bool_t matched; + char *closest_match, *text; + int n_entries; +}; + +void backend_search_sssd(struct backend_set_data *set_data, + struct backend_search_cbdata *cbdata); + +void backend_set_operational_attributes(Slapi_Entry *e, + struct plugin_state *state, + time_t timestamp, + int n_subordinates, + const char *usn); +int backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry); + + +#endif -- 1.8.3.1 From jhrozek at redhat.com Tue Jul 16 12:54:47 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Jul 2013 14:54:47 +0200 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users In-Reply-To: <20130715171452.GE18587@redhat.com> References: <20130715171452.GE18587@redhat.com> Message-ID: <20130716125447.GJ9163@hendrix.brq.redhat.com> On Mon, Jul 15, 2013 at 08:14:52PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached patch allows to enable serving trusted domain users and groups > through Schema Compatibilty plugin. > > The patch only does FreeIPA master configuration settings, the real work > is done by the changes to slapi-nis plugin (in a separate email). > > Since ipa-adtrust-install can safely be run multiple times, one can > re-run it on the IPA master to enable serving old clients, by specifying > > ipa-adtrust-install --enable-compat > > or answering 'yes' to the interactive question. > > I have expanded man page for ipa-adtrust-install to cover this option. > > Once enabled, following is possible: > --------------------------------------------------------------------------- > # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li '(&(cn=domain admins at ad.lan)(objectclass=posixgroup))' > SASL/GSSAPI authentication started > SASL username: admin at VDA.LI > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(cn=domain admins at ad.lan)(objectclass=posixgroup)) > # requesting: ALL > # > > # domain admins at ad.lan, groups, compat, vda.li > dn: cn=domain admins at ad.lan,cn=groups,cn=compat,dc=vda,dc=li > objectClass: posixGroup > objectClass: extensibleObject > objectClass: top > gidNumber: 1442800512 > memberUid: uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li > schema-compat-origin: sssd > ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-512 > cn: domain admins at ad.lan > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > --------------------------------------------------------------------------- > > and for users: > --------------------------------------------------------------------------- > # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li > # '(uid=administrator at ad.lan)' > SASL/GSSAPI authentication started > SASL username: admin at VDA.LI > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=administrator at ad.lan) > # requesting: ALL > # > > # administrator at ad.lan, users, compat, vda.li > dn: uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li > objectClass: posixAccount > objectClass: extensibleObject > objectClass: top > gecos: Administrator > cn: Administrator > uidNumber: 1442800500 > gidNumber: 1442800500 > homeDirectory: / > schema-compat-origin: sssd > ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-500 > uid: administrator at ad.lan > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > ---------------------------------------------------------------------------- > > Currently PAM authentication is a bit broken due to yet-to-hunt bug in > SSSD or my environment (Jakub was unable to reproduce it) where SSSD > thinks that AD DC is offline during authentication step. > > However, if you don't hit the bug, you can check authentication by doing > following bind and entering a password for your AD administrator: > # ldapsearch -D uid=administrator at ad.lan,cn=users,cn=compat,dc=vda,dc=li \ > -W -x -C -a always -b dc=vda,dc=li '(uid=admin)' > > The bind operation needs to be performed _after_ user lookup. > > All these commands are only examples, I'm currently working on seeing > how to configure pam_ldap/nss_ldap to use compat plugin this way. > -- > / Alexander Bokovoy Hi, the patch looks mostly good to me. I only have some small nitpicks: > +++ b/install/tools/man/ipa-adtrust-install.1 > @@ -106,6 +106,24 @@ The password of the user with administrative privileges for this IPA server. Wil > .TP > The credentials of the admin user will be used to obtain Kerberos ticket before configuring cross-realm trusts support and afterwards, to ensure that the ticket contains MS-PAC information required to actually add a trust with Active Directory domain via 'ipa trust-add --type=ad' command. > .TP > +\fB\-\-enable\-compat\fR > +Enables support for trusted domains users for old clients through Schema Compatibility plugin. > +SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that ^^^^^^^^ The word "platform" looks a little extra here to me. > +lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi\-nis package > +needs to be installed and schema\-compat\-plugin will be configured to provide lookup of > +users and groups from trusted domains via SSSD on IPA server. These users and groups will be > +available under \fBcn=users,cn=compat,$SUFFIX\fR and \fBcn=groups,cn=compat,$SUFFIX\fR trees. > +SSSD will normalize names of users and groups to lower case. > +.IP > +In addition to providing these users and groups through the compat tree, this option enables > +authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN > +\fBuid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX\fR. This authentication is related > +to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled HBAC rule 'allow_all', then > +make sure there is special service called '\fBsystem\-auth\fR' created and HBAC rule to allow > +access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service > +is not used directly by any other application, therefore it is safe to create one specifically > +to support trusted domain users via compatibility path. The last sentence wasn't really clear to me, were you suggesting to create a special PAM service? > +.TP > .SH "EXIT STATUS" > 0 if the installation was successful > > diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py > index 4eb20d9..9ecc7e9 100644 > --- a/ipaserver/install/adtrustinstance.py > +++ b/ipaserver/install/adtrustinstance.py > @@ -664,6 +664,20 @@ class ADTRUSTInstance(service.Service): > except Exception, e: > root_logger.critical("Checking replicas for cifs principals failed with error '%s'" % e) > > + def __enable_compat_tree(self): > + try: > + compat_plugin_dn = DN("cn=Schema Compatibility,cn=plugins,cn=config") > + lookup_sssd_name = "schema-compat-lookup-sssd" > + for config in (("cn=users", "user"), ("cn=groups", "group")): > + entry_dn = DN(config[0], compat_plugin_dn) > + current = self.admin_conn.get_entry(entry_dn) > + lookup_sssd = current.get(lookup_sssd_name, []) > + if not(config[1] in lookup_sssd): > + current[lookup_sssd_name] = [config[1]] > + self.admin_conn.update_entry(entry_dn, current) > + except Exception, e: > + root_logger.critical("Enabling SSSD support in slapi-nis failed with error '%s'" % e) > + > def __start(self): > try: > self.start() > @@ -713,7 +727,7 @@ class ADTRUSTInstance(service.Service): > > def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, > reset_netbios_name, rid_base, secondary_rid_base, > - no_msdcs=False, add_sids=False, smbd_user="samba"): > + no_msdcs=False, add_sids=False, smbd_user="samba", enable_compat=False): > self.fqdn = fqdn > self.ip_address = ip_address > self.realm = realm_name > @@ -724,6 +738,7 @@ class ADTRUSTInstance(service.Service): > self.secondary_rid_base = secondary_rid_base > self.no_msdcs = no_msdcs > self.add_sids = add_sids > + self.enable_compat = enable_compat > self.smbd_user = smbd_user > self.suffix = ipautil.realm_to_suffix(self.realm) > self.ldapi_socket = "%%2fvar%%2frun%%2fslapd-%s.socket" % \ > @@ -811,6 +826,11 @@ class ADTRUSTInstance(service.Service): > self.step("configuring smbd to start on boot", self.__enable) > self.step("adding special DNS service records", \ > self.__add_dns_service_records) > + > + if self.enable_compat: > + self.step("Enabling trusted domains support for older clients via Schema Compatibility plugin", ^^^^ Nitpick: all the other steps begin with lowercased letter. Only this one is uppercased, which makes the tool output looks inconsistent: [15/21]: adding special DNS service records [16/21]: Enabling trusted domains support for older clients via Schema Compatibility plugin [17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes into account > + self.__enable_compat_tree) > + > self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ > self.__restart_dirsrv) > self.step("adding fallback group", self.__add_fallback_group) > -- > 1.8.3.1 > Othwerwise looks good to me and seems to be working fine. From abokovoy at redhat.com Tue Jul 16 13:22:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Jul 2013 16:22:01 +0300 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users In-Reply-To: <20130716125447.GJ9163@hendrix.brq.redhat.com> References: <20130715171452.GE18587@redhat.com> <20130716125447.GJ9163@hendrix.brq.redhat.com> Message-ID: <20130716132201.GK18587@redhat.com> On Tue, 16 Jul 2013, Jakub Hrozek wrote: >the patch looks mostly good to me. I only have some small nitpicks: > >> +++ b/install/tools/man/ipa-adtrust-install.1 >> @@ -106,6 +106,24 @@ The password of the user with administrative privileges for this IPA server. Wil >> .TP >> The credentials of the admin user will be used to obtain Kerberos ticket before configuring cross-realm trusts support and afterwards, to ensure that the ticket contains MS-PAC information required to actually add a trust with Active Directory domain via 'ipa trust-add --type=ad' command. >> .TP >> +\fB\-\-enable\-compat\fR >> +Enables support for trusted domains users for old clients through Schema Compatibility plugin. >> +SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that > ^^^^^^^^ > The word "platform" > looks a little > extra here to me. Removed. I initially had statement there to talk about Linux and non-Linux platforms, this word slipped when I edited platform talk out. >> +lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi\-nis package >> +needs to be installed and schema\-compat\-plugin will be configured to provide lookup of >> +users and groups from trusted domains via SSSD on IPA server. These users and groups will be >> +available under \fBcn=users,cn=compat,$SUFFIX\fR and \fBcn=groups,cn=compat,$SUFFIX\fR trees. >> +SSSD will normalize names of users and groups to lower case. >> +.IP >> +In addition to providing these users and groups through the compat tree, this option enables >> +authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN >> +\fBuid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX\fR. This authentication is related >> +to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled HBAC rule 'allow_all', then >> +make sure there is special service called '\fBsystem\-auth\fR' created and HBAC rule to allow >> +access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service >> +is not used directly by any other application, therefore it is safe to create one specifically >> +to support trusted domain users via compatibility path. > >The last sentence wasn't really clear to me, were you suggesting to >create a special PAM service? I refactored the statement. system-auth is a PAM service (/etc/pam.d/system-auth) provided by pam RPM package. You don't need to create it as it is created and maintained by the system (and authconfig). What this sentence talks about is that PAM authentication means also verifying HBAC rules. If you have disable 'allow_all' HBAC rule, then for all PAM services there should be HBAC rule that allows access to it if that is required. As in case of trusted AD users they don't exist in LDAP, we cannot really refer to them in HBAC rules so we only can have an HBAC rule that allows 'all' to access 'system-auth' service on 'ipa masters' host group. system-auth PAM service is not used by any other application directly. Instead, their own PAM services include system-auth through PAM stack. That's why I selected system-auth -- enabling HBAC rules to access it does not compromise any other service because of the way how PAM stacking works -- access to an app is granted through PAM service name that application runs against. I.e. ssh runs against /etc/pam.d/ssh, so HBAC rule would need to be created against 'ssh' service. /etc/pam.d/ssh is including system-auth through PAM stack and system-auth is configured to use pam_sss but 'system-auth' as service name is never seen or used by anyone through PAM API. >> + if self.enable_compat: >> + self.step("Enabling trusted domains support for older clients via Schema Compatibility plugin", > > ^^^^ > Nitpick: all the other steps begin with lowercased > letter. Only this one is uppercased, which makes the > tool output looks inconsistent: > [15/21]: adding special DNS service records > [16/21]: Enabling trusted domains support for older clients via Schema Compatibility plugin > [17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes into account Thanks. Lowcased it. Updated patch is attached. -- / Alexander Bokovoy -------------- next part -------------- >From bbfb7620de54c8b55886f3e7a616096afa9ce58e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 15 Jul 2013 19:13:50 +0300 Subject: [PATCH] ipa-adtrust-install: configure compatibility tree to serve trusted domain users Enables support for trusted domains users for old clients through Schema Compatibility plugin. SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi-nis package needs to be installed and schema-compat-plugin will be configured to provide lookup of users and groups from trusted domains via SSSD on IPA server. These users and groups will be available under cn=users,cn=compat,$SUFFIX and cn=groups,cn=compat,$SUFFIX trees. SSSD will normalize names of users and groups to lower case. In addition to providing these users and groups through the compat tree, this option enables authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN uid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX. This authentication is related to PAM stack using 'system-auth' PAM service. If you have disabled HBAC rule 'allow_all', then make sure there is special service called 'system-auth' created and HBAC rule to allow access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service is not used directly by any other application, therefore it is safe to create one specifically to support trusted domain users via compatibility path. https://fedorahosted.org/freeipa/ticket/3567 --- install/tools/ipa-adtrust-install | 18 +++++++++++++++++- install/tools/man/ipa-adtrust-install.1 | 23 +++++++++++++++++++++++ ipaserver/install/adtrustinstance.py | 22 +++++++++++++++++++++- 3 files changed, 61 insertions(+), 2 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 5744c6f..838f722 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -62,6 +62,9 @@ def parse_options(): parser.add_option("--add-sids", dest="add_sids", action="store_true", default=False, help="Add SIDs for existing users and" \ " groups as the final step") + parser.add_option("--enable-compat", + dest="enable_compat", default=False, action="store_true", + help="Enable support for trusted domains for old clients") options, args = parser.parse_args() safe_options = parser.get_safe_opts(options) @@ -194,6 +197,15 @@ def ensure_admin_kinit(admin_name, admin_password): return False return True +def enable_compat_tree(): + print "Do you want to enable support for trusted domains in Schema Compatibility plugin?" + print "This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users." + print "" + enable_compat = ipautil.user_input("Enable trusted domains support in slapi-nis?", default = False, allow_empty = False) + print "" + return enable_compat + + def main(): safe_options, options = parse_options() @@ -244,6 +256,9 @@ def main(): sys.exit("Aborting installation.") break + if not options.unattended and not options.enable_compat: + options.enable_compat = enable_compat_tree() + # Check we have a public IP that is associated with the hostname ip = None try: @@ -363,7 +378,8 @@ def main(): smb.setup(api.env.host, ip_address, api.env.realm, api.env.domain, netbios_name, reset_netbios_name, options.rid_base, options.secondary_rid_base, - options.no_msdcs, options.add_sids) + options.no_msdcs, options.add_sids, + enable_compat = options.enable_compat) smb.find_local_id_range() smb.create_instance() diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 38957f3..7f0566e 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -106,6 +106,29 @@ The password of the user with administrative privileges for this IPA server. Wil .TP The credentials of the admin user will be used to obtain Kerberos ticket before configuring cross-realm trusts support and afterwards, to ensure that the ticket contains MS-PAC information required to actually add a trust with Active Directory domain via 'ipa trust-add --type=ad' command. .TP +\fB\-\-enable\-compat\fR +Enables support for trusted domains users for old clients through Schema Compatibility plugin. +SSSD supports trusted domains natively starting with version 1.9. For platforms that +lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi\-nis package +needs to be installed and schema\-compat\-plugin will be configured to provide lookup of +users and groups from trusted domains via SSSD on IPA server. These users and groups will be +available under \fBcn=users,cn=compat,$SUFFIX\fR and \fBcn=groups,cn=compat,$SUFFIX\fR trees. +SSSD will normalize names of users and groups to lower case. +.IP +In addition to providing these users and groups through the compat tree, this option enables +authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN +\fBuid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX\fR. +.IP +LDAP authentication performed by the compat tree is done via PAM '\fBsystem\-auth\fR' service. +This service exists by default on Linux systems and is provided by pam package as /etc/pam.d/system\-auth. +If your IPA install does not have default HBAC rule 'allow_all' enabled, then make sure +to define in IPA special service called '\fBsystem\-auth\fR' and create an HBAC +rule to allow access to anyone to this rule on IPA masters. +.IP +As '\fBsystem\-auth\fR' PAM service is not used directly by any other +application, it is safe to use it for trusted domain users via compatibility +path. +.TP .SH "EXIT STATUS" 0 if the installation was successful diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 4eb20d9..f072a6a 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -664,6 +664,20 @@ class ADTRUSTInstance(service.Service): except Exception, e: root_logger.critical("Checking replicas for cifs principals failed with error '%s'" % e) + def __enable_compat_tree(self): + try: + compat_plugin_dn = DN("cn=Schema Compatibility,cn=plugins,cn=config") + lookup_sssd_name = "schema-compat-lookup-sssd" + for config in (("cn=users", "user"), ("cn=groups", "group")): + entry_dn = DN(config[0], compat_plugin_dn) + current = self.admin_conn.get_entry(entry_dn) + lookup_sssd = current.get(lookup_sssd_name, []) + if not(config[1] in lookup_sssd): + current[lookup_sssd_name] = [config[1]] + self.admin_conn.update_entry(entry_dn, current) + except Exception, e: + root_logger.critical("Enabling SSSD support in slapi-nis failed with error '%s'" % e) + def __start(self): try: self.start() @@ -713,7 +727,7 @@ class ADTRUSTInstance(service.Service): def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, reset_netbios_name, rid_base, secondary_rid_base, - no_msdcs=False, add_sids=False, smbd_user="samba"): + no_msdcs=False, add_sids=False, smbd_user="samba", enable_compat=False): self.fqdn = fqdn self.ip_address = ip_address self.realm = realm_name @@ -724,6 +738,7 @@ class ADTRUSTInstance(service.Service): self.secondary_rid_base = secondary_rid_base self.no_msdcs = no_msdcs self.add_sids = add_sids + self.enable_compat = enable_compat self.smbd_user = smbd_user self.suffix = ipautil.realm_to_suffix(self.realm) self.ldapi_socket = "%%2fvar%%2frun%%2fslapd-%s.socket" % \ @@ -811,6 +826,11 @@ class ADTRUSTInstance(service.Service): self.step("configuring smbd to start on boot", self.__enable) self.step("adding special DNS service records", \ self.__add_dns_service_records) + + if self.enable_compat: + self.step("enabling trusted domains support for older clients via Schema Compatibility plugin", + self.__enable_compat_tree) + self.step("restarting Directory Server to take MS PAC and LDAP plugins changes into account", \ self.__restart_dirsrv) self.step("adding fallback group", self.__add_fallback_group) -- 1.8.3.1 From tbabej at redhat.com Tue Jul 16 15:11:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Jul 2013 17:11:46 +0200 Subject: [Freeipa-devel] [PATCH 0078] Refactor the interactive prompt logic in idrange_add Message-ID: <3110373.bFp2SkEW4Y@thinkpad7.brq.redhat.com> Hi, Make the interactive prompts interpret the following logic: - AD range (dom-sid/dom-name set): require RID base if not set - local range(dom-sid/dom-name not set): a) server with adtrust support: require both RID base and secondary RID base b) server without adtrust support: if any of RID base, secondary RID base set, require both of them https://fedorahosted.org/freeipa/ticket/3786 Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Jul 16 15:13:17 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Jul 2013 17:13:17 +0200 Subject: [Freeipa-devel] [PATCH 0078] Refactor the interactive prompt logic in idrange_add In-Reply-To: <3110373.bFp2SkEW4Y@thinkpad7.brq.redhat.com> References: <3110373.bFp2SkEW4Y@thinkpad7.brq.redhat.com> Message-ID: <52847480.ImKuNIMyXu@thinkpad7.brq.redhat.com> On Tuesday 16 of July 2013 17:11:46 Tomas Babej wrote: > Hi, > > Make the interactive prompts interpret the following logic: > > - AD range (dom-sid/dom-name set): > require RID base if not set > > - local range(dom-sid/dom-name not set): > a) server with adtrust support: > require both RID base and secondary RID base > b) server without adtrust support: > if any of RID base, secondary RID base set, > require both of them > > https://fedorahosted.org/freeipa/ticket/3786 > > Tomas Too quick once again. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0078-Refactor-the-interactive-prompt-logic-in-idrange_add.patch Type: text/x-patch Size: 4486 bytes Desc: not available URL: From pspacek at redhat.com Tue Jul 16 15:15:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Jul 2013 17:15:02 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1373915246.30537.400.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> Message-ID: <51E56376.6000606@redhat.com> On 15.7.2013 21:07, Simo Sorce wrote: > On Mon, 2013-07-15 at 16:58 +0200, Petr Spacek wrote: >> The remaining part is mostly about key management. >> >> Following text mentions 'DNSSEC keys' many times, so I tried to summarize how >> keys are used in DNSSEC. Feel free to skip it. >> >> == DNSSEC theory == >> >> Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, >> the first key pair) and Zone Signing Key (ZSK, the second key pair). >> >> - *Parent* zone contains a copy of public part of the KSK. >> - Zone itself contains public part of ZSK (and KSK). >> - Client uses public part of KSK (obtained from secure parent zone) for ZSK >> verification. >> - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG >> records) and verification on client side. >> >> Each key and signature contains key-id, so one zone can be signed by multiple >> KSKs and ZSKs at the same time. This solves the key roll over problem. >> >> Each key contains this set of timestamps: >> Created, Revoke - self descriptive :-) >> Publish - public part of the key will be visible in zone after this time >> Active - new signatures with this key can be generated after this time >> Inactive - new signatures with this key cannot be generated after this time >> Delete - public part of the key will deleted from the zone after this time >> >> NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change >> in parent zone) and ZSK should be changed ~ each 1-3 months. >> >> The recommendation says [1] that zone should have two ZSKs: One Active (used >> for signature generation) and second only Published (ready for roll over in >> case of emergency/when the first key pair expires). This mitigates problems >> with caches and stale key material during roll-over. >> >> BIND 9 can do signature maintenance/ZSK key roll over automatically. It needs >> only keys stored in files (with proper timestamps) and all signatures will be >> generated & removed when the right time passes. > > Is there any place I can read about the format and requirements of these > files ? There is no single format, because it is algorithm-dependent. See below. AFAIK it is nothing supported by OpenSSL, but I can be wrong. >> KSK has to be rolled over manually because it requires changes in parent zone. >> (It could be automated for sub-zones if their parent zone is also managed by >> the same IPA server.) > > Is there any provision for using DNSSEC with private DNS deployments ? Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS resolvers can be configured with 'trust anchors' explicitly. E.g. 'trust domain example.com only if it is signed by /this/ key, use root key for rest of the Internet' etc. [Terminology] http://tools.ietf.org/html/rfc4033#section-2 > Or is this going to make sense only for IPA deployments that have valid > delegation from the public DNS system ? > > Hmmm I guess that as long as the KSK in the 'parent' zone is imported > properly a private deployment of corp.myzone.com using the KSK of > myzone.com will work just fine even if corp.myzone.com is not actually > delegated but is a private DNS tree ? > Or is that incorrect ? AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from the parent, but IMHO it could work if only the public key for internal zones is published (without any delegation to internal name servers etc.). I didn't try it, so 'here be dragons'. Normally it should work this way: . (root zone is signed with well known key) - root contains DS record for com. - DS contains hash of the public key used in com. domain com. - DNSKEY record contains whole public key for domain com. - key is accepted only if hash of the key matches DS record from parent (.) - DS record for example.com. is stored in com. example.com. - DNSKEY record contains whole public key for domain example.com. - the key is accepted only if hash of the key matches DS record from parent (com.) etc. Client walks from the root zone down to the desired record and verifies signatures with keys obtained from DNSKEY record. The DNSKEY record itself has to be authenticated by DS -> DNSKEY -> DS -> DNSKEY -> ... -> DNSKEY chain (from root down to the zone). Yes, publishing of DS record creates information leak - about existence of a sub-domain - but this information leaks anyway in e-mail headers etc. IMHO it is much better than messing with private Trust Anchors etc. [DS] http://tools.ietf.org/html/rfc4034#section-5 >> == End of DNSSEC theory == >> >> >> >> 1) How will we handle generation of key pairs? How will externally generated >> keys be imported? >> >> Personally, I would start with 'classical' command line utilities like >> dnssec-keygen etc. and extend 'ipa' tool to import generated keys. (Import = >> read keys from text files and create appropriate attributes to LDAP.) > > If you mean to do this as part of the ipa-dns-install script or > additional script (eg ipa-dnssec-enable) I am fine. I am not ok with > asking admins to manually run these commands. Okay. I meant something like extension of 'ipa' command. >> Initial key generation is closely related to the question how should we handle >> (periodic) key regeneration? (e.g. "Generate new ZSK each month.") > > We only really need to generate (or import) the KSK of the parent zone, It seems that there is slight misunderstanding. KSK is the 'master key' for particular zone. This master key (KSK) signs other keys (ZSKs) and data are signed by ZSKs. It works in the same way as key generation in PKI: The holder (e.g. company domain, example.com) generates key pair and sends the public part (in our case the hash of the public key) to the authority (to the parent zone). Parent should never get private key, so there is nothing to import from parent. I.e. we should create a new zone, generate KSKs, generate hashes and send hashes to the administrator of the parent zone. (I.e. generate text with explanation and values to send to the parent's admin.) > our code should be able to generate any other key, and sign it. > >> Is it okay to use normal cron job to handle the key generation? I.e. to call >> dnssec-keygen with proper parameters each month and store the result in LDAP? > > No, the problem is that we need to define 'who' generates the keys. > Remember FreeIPA is a multimaster system, we cannot have potentially > conflicting cron jobs running on multiple servers. Right. It sounds like the CRL generation problem. Should we do the same for DNSSEC key regeneration? I.e. select one super-master and let it to handle key regeneration? Or should we find some more robust solution? I'm not against any of these possibilities :-) >> Or should we teach certmonger to take care of DNSSEC keys? Certmonger would >> have to call dnssec-keygen and to do some IPA calls. (I assume that key >> parsing and import will be handled by IPA framework.) > > certmonger might have the same issue as a cronjob, how do we know > *which* one of 3 DNS server should run the updating job ? > > Should we just leave it to chance and the first win ? What if 2 end up > trying to create new keys at exactly the same time ? > >> We can postpone the key management for the first version and just provide >> interface for key removal and import from file. > > Well all this key management will be a FreeIPA issue, from the > bind-dyndb-ldap development pov we need to provide the mechanism and can > certainly defer the key management part, but we will not be able to > offer this feature until that is done. I agree. I didn't realize how complex the key management part will be. >> 2) Second question is how and where keys should be stored. AFAIK BIND 9 >> expects that keys will be stored in file system: One key pair as two files in >> specified directory. We probably want to store keys in LDAP, as usual. >> >> My proposal is to represent each key pair by object with new class >> idnsDNSSECKey. This 'key pair object' will be stored inside zone container. E.g. >> DNS zone = idnsname=ipa.test,cn=dns,dc=ipa,dc=test >> Key pair = cn=005+01908,idnsname=ipa.test,cn=dns,dc=ipa,dc=test >> >> Private key is represented by opaque blob (size ~ 1-2 kiB), so octetString >> could be the right syntax: >> attributetypes: ( x.x.x.x.x NAME 'idnsSecPrivateKey' SYNTAX >> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) > > Is this just a key ? Or does it contain further data ? It contains some meta data (mainly timestamps): created on/public from/active from/valid to/revoked/key type (KSK/ZSK)/algorithm. >> Public key can be represented with normal DNSKEY record (size ~ 200-500 B), so >> it would be possible to use normal DNSKEY attribute. I see two problems with >> this approach: >> - DNSKEY record (= attribute) is multi-valued by definition, but only one >> public key can be present in a key pair. >> - DNSKEY records will be managed automatically by BIND so we don't want to let >> users to mess with them directly. DNSKEYRecord attribute is not defined at the >> moment and I'm not willing to define it now. >> >> For these reasons I think that we can define new public key attribute in the >> same way as private key attribute: >> attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX >> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) >> >> The resulting object class could be: >> objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP >> top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) > > Will bind read these attributes ? > Or will we have to dump these values into files via bind-dyndb-ldap for > bind9 to read them back ? AFAIK it has to be in files: Private key in one file and public key in the other file. I can't find any support for reading private keys from buffers. >> CN attribute is user readable key name. It could be anything. BIND's syntax >> follows (text copied from dnssec-keyfromlabel): >> This is an identification string for the key files: String of the form >> "Knnnn.+aaa+iiiii": >> - nnnn is the key name (zone name) >> - aaa is the numeric representation of the algorithm >> - iiiii is the key identifier (or footprint) >> >> Naturally, we can omit leading "K" and zone name, because we know the name >> from parent object in the LDAP/DIT. Also, it could be nice to indicate the >> type of the key - KSK or ZSK. > > ack, should we have an explicit attribute that tells us what type it > is ? May be, we will see. It is possible that we will need to store key algorithm and key ID explicitly for some reason. I'm still not sure that I understand to all aspects of key management in BIND. >> Attribute idnsSecPrivateKey should be readable only by DNS admins (and DNS >> servers :-). I'm not sure if we should make restrict read access even more. Is >> there a valid reason for admin to read the blob? I don't know, but admin can >> read the file on disk anyway ... > > One weak reason to allow read by admins would be to allow them to > migrate away, but I do not like to put these keys completely unprotected > in LDAP. Given bind has a keytab I was thinking we may want to encrypt > these keys with the DNS long term key, however this complicates the code > slightly in 2 ways: > 1. we can have multiple DNS Servers (ie multiple keys) > 2. we need to allow for roll-over I see two more problems: 3. it would make Kerberos required (now the plugin doesn't require Kerberos) 4. we use SASL but I think that your approach would require direct manipulation with keytab > To simplify the matter we would have to use a 'master key' that encrypts > all signing keys and is made available to DNS servers encrypted with > their keys. > > Master key needs to allow for roll over in case it is compromised. But > we could deal with it by simply rolling also all DNS keys and encrypting > the new ones with the new key. After all if the key was compromised we > must assume all DNs signing keys may have been compromised so a full > roll-over is necessary. This simplifies the problem because it means we > will never need to store the same DNS signing key encrypted with > multiple 'master keys'. > > A master key also allows for easy addition/removal of DNS servers as it > needs to be re-encrypted only once when a new DNS is added (or removed > and readded), and a server removal is just a delete operation. Oooo, lots of fun. Are you aware of any abstraction layer which could all the magic for us? Something from OpenSSL/SASL/GSSAPI? I didn't mention Dogtag because dependency on Dogtag might become my nightmare... :-) >> From user interface point of view, key pairs are bit hard to deal with. >> Private key format is algorithm-dependent, so the only universal way to get >> standardized fields like valid-from/active-from/valid-to/revoked timestamps >> etc. is to call parser from bind-libs. > > Are these parsers available in public libs ? It seems that all necessary parts are available via package bind-libs, /usr/include/bind9/dst/dst.h. > Should we add these attributes explicitly in the 'idnsSecKeyPair' > objetclass instead and reconstruct the private key file from there ? > Or would that risk being incompatibile with a future new key type ? That is exactly why I proposed the 'blob' approach. Each algorithm needs different values, so RSA and DSA key formats differ. See attachments - these files were written by dnssec-keygen for RSASHA1 and DSA. Formats are *similar* at the moment, but the problem is that parsers for each algorithm can diverge in the future. > If so should we really split key material in 2 attributes? Or should we > rather just load the full file content in a single attribute as an > opaque blob ? BIND 9 stores public and private keys separately in two files, so I would imitate it's approach - with two separate attributes. >> 3) How will the configuration be stored? >> Parameters are: >> - DNSSEC enabled/disabled for one zone or globally - proposal: add a new >> boolean attribute idnsSecInlineSigning to zone and global config object > > why not simply iDNSSECenabled: TRUE/FALSE ? I would like to imitate BIND's config - we plan to do the same thing as BIND's option 'inline-signing'. BIND will do signing for us, but at some point in the future we could decide to do signing ourselves etc. More specific name prevents confusion when we need to change behaviour. >> - NSEC3 parameters - proposal: use standard NSEC3PARAM record in the zone > > What are these ? Short answer: http://www.simpledns.com/help/v52/rec_nsec3param.htm Long answer: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence http://tools.ietf.org/html/rfc5155#section-4 >> The rest of the configuration options are related to the key management >> problem. We need to know: >> - how many key pairs (e.g. 2 KSKs, 2 ZSKs) > > Shouldn't we allow an arbitrary number ? Does bind have strict limits ? Yes, arbitrary number sounds fine. 2 + 2 was just an example. >> - when (e.g. generate new key pair 30 days before active key expires) > > probably needs to be tunable. new attribute ? > >> - of which key types (KSK or ZSK) >> - with which algorithms >> - with which key lengths >> should be generated. Note that we need to store configuration about X KSKs and >> Y ZSKs. > > seem all of these needs to be tunables and require their own > attributes ? I agree. The question is how to group the attributes to make it useful. IMHO it should express something like this: - I want to use 1 KSK with algorithm RSASHA1, key length 2048 bits, the key should be used for 1 year. - I want to have 1 other KSK (with same parameters) ready for roll over at any time. - Roll over period is 1 month. (The time required for incremental resigning with the new key, i.e. the time period when old and new signatures will co-exist.) The result should be: In time 0 (zone creation), generate 2 KSKs: The KSK 'A' would have these timestamps: - created = published = active from = 0 (generate signatures immediately) - inactive = 0 + 1 year - 1 month (stop generating signatures after 11 months) - delete = 0 + 1 year (one month was transitional period for incremental resigning with the new key, then delete the key 'A') The KSK 'B' would be generated at the same time as 'A': - created = published = 0 (publish key, but don't generate signatures) - active from = 0 + 1 year - inactive = 0 + 2 years - 1 month - delete = 0 + 2 years During the first year, all records will be signed with KSK 'A'. In time '0 + 1 year - 1 month' KSK 'A' will become inactive and KSK 'B' will become active. At the same time, new KSK 'C' will be generated with following timestamps: - created = published = 1 year - 1 month (publish key, but don't generate signatures) - active from = 0 + 2 year - 1 month - inactive = 0 + 3 years - 1 month - delete = 0 + 3 years All records will be re-signed using KSK 'B' during time <1 year - 1 month, 1 year>. In time '0 + 1 year' all signatures were regenerated with using KSK 'B' and KSK 'A' will be removed. Note that you may want to use 1 KSK with algorithm RSA and another KSK with DSA. I'm not really sure if it makes sense. Could something like this work? objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyGroup' DESC 'DNSSEC key group' SUP top STRUCTURAL MUST ( cn $ key type $ # (KSK or ZSK) algorithm $ # (RSA, DSA) key length $ # (2048) lifetime of the key $ # (1 year) roll over period $ # (1 month) number of active keys $ # (1) number of spare keys $ # (1) ) ) The key group could be stored as cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test Keys could be stored as individual objects under cn=id, cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test In usual cases it solves grouping of KSKs and ZSKs. Also, it enables us to define key group with RSA and another one with DSA algorithm or to migrate from a key group with shorter keys to a key group with longer keys. >> Again, we can postpone the key management for the first version. > > We can certainly postpone certain aspects of key management at least to > get development time down to a more quantifiable amount. But we'll not > be able to offer DNSSEC support in FreeIPA until there is management. > >> 4) For future versions - do we plan to add support for PKCS#11 HSMs? BIND 9 >> can use OpenSSL for this stuff (somehow), but I didn't look into details. > > I think this can be certainly postponed unless it may require changes in > the schema, in which case we may want to discuss if we need anything in > there so that the initial code can be future-proof. I have a crazy idea: Could OpenSSL PKCS#11 implementation help us to deal with the key management problems mentioned above - somehow? I know next to nothing about PKCS#11 and related areas, but problems we met (like safe key storage & transport) sounds like something common. Could we use PKCS#11 in some clever way, let OpenSSL to do the dirty work with key encryption/retrieval and solve HSM support and security at once? Would it be possible to write PKCS#11 module for OpenSSL and let it to store keys in IPA - in some generic way? So it will solve key storage for all OpenSSL/PKCS#11 enabled applications and not only for bind-dyndb-ldap? As I said, it is just crazy idea ... and I really know nothing about this area. >> [1] http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf >> section 9.3 Generation of Public Key-Private Key Pair (DNSSEC-OP1) page 9-5 -- Petr^2 Spacek -------------- next part -------------- ; This is a zone-signing key, keyid 50652, for dsa. ; Created: 20130716083717 (Tue Jul 16 10:37:17 2013) ; Publish: 20130716083717 (Tue Jul 16 10:37:17 2013) ; Activate: 20130716083717 (Tue Jul 16 10:37:17 2013) dsa. IN DNSKEY 256 3 3 CI/K88jBpTjtAnjNfOalooVPIjwPjtpxqkP7VpuAqZnmVvOjLxnZd4y6 KcFwGFQKzwhRt4nDP/9aCl30YJwdg6/GLB9YlsAekofBqr6H7Xf6NJTP QfAF56MAH5314Bw+jjsvWIAOEYpL9Ymqjcffi9ol5w2JZnHDz2NcpL09 Sg0Bmm4lyFZdHMb1ixaoyU4tkaPurANFLy58Lk9IE4/KyXR+VMl2cYyy dlvox+N7a8QBBDE5618hofd4CoJtHKJmDn/xlMDWs0sasK0bJ1sDdFpf 5EJh54MBVzZ9/YpYGoAvZtH4Awa2RXLHd5oRKf93miQbpNCUVgXeg2LZ dqkwNskpyJ51GEBT9wXO80i2AdSxAcbAbmXqi+zVCGk4BC+A4KfKxuUW o4MQY8AsRRLWgFiZlm1+y5xFnjnQUfcgRChsoyDsSRLbbC76GQ/1gugA B437MYShyRixzLg7o77DZtyvkldG1oei70yPDI1I1FXyomm6UrjjXi+m zjPUee95cuRXGhfPVkptQev3ofBsQ3Lagw79 -------------- next part -------------- Private-key-format: v1.3 Algorithm: 3 (DSA) Prime(p): jtpxqkP7VpuAqZnmVvOjLxnZd4y6KcFwGFQKzwhRt4nDP/9aCl30YJwdg6/GLB9YlsAekofBqr6H7Xf6NJTPQfAF56MAH5314Bw+jjsvWIAOEYpL9Ymqjcffi9ol5w2JZnHDz2NcpL09Sg0Bmm4lyFZdHMb1ixaoyU4tkaPurAM= Subprime(q): j8rzyMGlOO0CeM185qWihU8iPA8= Base(g): RS8ufC5PSBOPysl0flTJdnGMsnZb6Mfje2vEAQQxOetfIaH3eAqCbRyiZg5/8ZTA1rNLGrCtGydbA3RaX+RCYeeDAVc2ff2KWBqAL2bR+AMGtkVyx3eaESn/d5okG6TQlFYF3oNi2XapMDbJKciedRhAU/cFzvNItgHUsQHGwG4= Private_value(x): GQZLYTTYtbphXYctPb/RgiL9Vqs= Public_value(y): ZeqL7NUIaTgEL4Dgp8rG5RajgxBjwCxFEtaAWJmWbX7LnEWeOdBR9yBEKGyjIOxJEttsLvoZD/WC6AAHjfsxhKHJGLHMuDujvsNm3K+SV0bWh6LvTI8MjUjUVfKiabpSuONeL6bOM9R573ly5FcaF89WSm1B6/eh8GxDctqDDv0= Created: 20130716083717 Publish: 20130716083717 Activate: 20130716083717 -------------- next part -------------- ; This is a zone-signing key, keyid 45708, for rsasha1. ; Created: 20130716083609 (Tue Jul 16 10:36:09 2013) ; Publish: 20130716083609 (Tue Jul 16 10:36:09 2013) ; Activate: 20130716083609 (Tue Jul 16 10:36:09 2013) rsasha1. IN DNSKEY 256 3 5 AwEAAc4kyuvD/3YdFcBa7Q65dBeejSyBpnSnkQBvZxkQcFU8rggBwFWK 3Sjx8gGR1cpOtGf5Mj3FwdG4qKutc3iPhBRGefUj0erhIpxY4d0xQXgM BZDIwz90l3KQiuod2BoFgBLdhhG+CadxbHUkcpF4CvWjkhYusmaoxALl gqobOYp7 -------------- next part -------------- Private-key-format: v1.3 Algorithm: 5 (RSASHA1) Modulus: ziTK68P/dh0VwFrtDrl0F56NLIGmdKeRAG9nGRBwVTyuCAHAVYrdKPHyAZHVyk60Z/kyPcXB0bioq61zeI+EFEZ59SPR6uEinFjh3TFBeAwFkMjDP3SXcpCK6h3YGgWAEt2GEb4Jp3FsdSRykXgK9aOSFi6yZqjEAuWCqhs5ins= PublicExponent: AQAB PrivateExponent: JU+3gtDo7iH5i+VpPt8GSjgiaUnWLQsfTarcSEcXbfYbsctPWqxVt1GDchFJVuLD+IW8OD4RBLqdnOU6Hzoqt4WV9cC0Y0bi+0Oymj8D4LSvxHLkQRqwsn12IRNc/VkLuGuGDWqsRa3jvMJ3YdVWqLTI86/F6TvhJVlh7cz/AHE= Prime1: 6cDgV1VsC2subAkgDMOLwNp6VpxP7MTq0Sulxz4pvJTKafyg18qqhs/1yS6p+crqXvcrJf3B7S/+sagdX/q1/Q== Prime2: 4cM9JFHv5P2b9ypcgj1FU6lFm+Al+1/HBWmSQi8NNAxbgKXzlNjmVrRELPLAVCfUHhxwsb2kkIlUIQzaMGpv1w== Exponent1: jtkRwA0x0+CSI++HqIUvuJFLRfaMWVMVdPJJgvMYKmh7Mj3yRS1S/MPFnkZoFYDNrW867SKgCkTUTtk/6lGaOQ== Exponent2: CFG4fBEk5OxPhgEinY4Ccv3G2eKdo7C41cM5J4UyWFuoN4pl+nMvsbw80uczHSbGk0F7CaGyYb0dw4YEuEoDyw== Coefficient: wHuchg0IJF/beCPfgtFGkayrd0grKOZtWCSRhiFVS1KH+EJJP0WQQCMaFukK8cBNm6ZDcG7Q73G7RUS95JqTvQ== Created: 20130716083609 Publish: 20130716083609 Activate: 20130716083609 From jhrozek at redhat.com Tue Jul 16 15:15:01 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Jul 2013 17:15:01 +0200 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130716123349.GJ18587@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130716100830.GE9163@hendrix.brq.redhat.com> <20130716102341.GH18587@redhat.com> <20130716120954.GI9163@hendrix.brq.redhat.com> <20130716123349.GJ18587@redhat.com> Message-ID: <20130716151501.GA22079@hendrix.brq.redhat.com> On Tue, Jul 16, 2013 at 03:33:49PM +0300, Alexander Bokovoy wrote: > On Tue, 16 Jul 2013, Jakub Hrozek wrote: > >On Tue, Jul 16, 2013 at 01:23:41PM +0300, Alexander Bokovoy wrote: > >>Hi! > >> > >>On Tue, 16 Jul 2013, Jakub Hrozek wrote: > >>>>+AC_ARG_WITH(sss_nss_idmap, > >>>>+ AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), > >>>>+ use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) > >>>>+if pkg-config sss_nss_idmap 2> /dev/null ; then > >>>>+ if test x$use_sss_nss_idmap != xno ; then > >>>>+ AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) > >>>>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > >>>>+ else > >>>>+ SSS_NSS_IDMAP_CFLAGS= > >>>>+ SSS_NSS_IDMAP_LIBS= > >>>>+ fi > >>>>+else > >>>>+ if test $use_sss_idmap = yes ; then > >>>>+ PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > >>>>+ else > >>>>+ SSS_NSS_IDMAP_CFLAGS= > >>>>+ SSS_NSS_IDMAP_LIBS= > >>>>+ fi > >>>>+fi > >>>>+AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) > >>>>+AC_SUBST(SSS_NSS_IDMAP_CFLAGS) > >>>>+AC_SUBST(SSS_NSS_IDMAP_LIBS) > >>>>+ > >>>>+if x$SSS_NSS_IDMAP_LIBS != x ; then > >>> > >>>I think you should use test or square brackets here, otherwise I'm > >>>seeing: > >>> > >>>checking for SSS_NSS_IDMAP... yes > >>>./configure: line 12952: x-lsss_nss_idmap: command not found > >>Thanks, added 'test ...' > >> > >>> > >>>>+ AC_CHECK_HEADERS(pam.h) > >>> > >>>I don't see any pam.h in pam-devel RPM. In SSSD we look for > >>>security/pam_appl.h > >>Right. Fixed. > >> > >>>>--- a/src/Makefile.am > >>>>+++ b/src/Makefile.am > >>>>@@ -51,6 +51,7 @@ nisserver_plugin_la_LIBADD = $(LDAP_LIBS) $(RUNTIME_LIBS) $(TIRPC_LIBS) $(LIBWRA > >>>> > >>>> schemacompat_plugin_la_SOURCES = \ > >>>> back-sch.c \ > >>>>+ back-sch.h \ > >>> > >>>This file is only added in the second patch, so maybe the whole > >>>Makefile.am hunk should be moved there. > >>Yes, moved to the second patch. > >> > >>New patchset is attached. > >>-- > >>/ Alexander Bokovoy > > > >Thanks for the changes, one more comment about patch #1: > > > >>+if test x$SSS_NSS_IDMAP_LIBS != x ; then > >>+ AC_CHECK_HEADERS(security/pam_appl.h) > >>+ if test x$ac_cv_header_pam_h = xno ; then > > > >I think you need to check for ac_cv_header_security_pam_appl_h here. > >Also the condition seems reversed to me, it was complaining about > >missing PAM-devel even when I had one. > > > >After changing the test to use ac_cv_header_security_pam_appl_h the > >and reverting the condition configure seems to have worked correctly for me. > > > >Here is the git diff I made: > >diff --git a/configure.ac b/configure.ac > >index aac52e2..085f51d 100644 > >--- a/configure.ac > >+++ b/configure.ac > >@@ -334,7 +334,7 @@ AC_SUBST(SSS_NSS_IDMAP_LIBS) > > > >if test x$SSS_NSS_IDMAP_LIBS != x ; then > > AC_CHECK_HEADERS(security/pam_appl.h) > >- if test x$ac_cv_header_pam_h = xno ; then > >+ if test x$ac_cv_header_security_pam_appl_h = xyes ; then > > use_pam=yes > > else > > use_pam=no > Thanks! I was too fast :) > > New patchset is attached, resending all patches to make easier tracking. > > -- > / Alexander Bokovoy > >From 6909b33edbfb30292645f0998b60a4ffb38891dd Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Tue, 16 Jul 2013 13:17:03 +0300 > Subject: [PATCH 1/2] configure: add configure checks for sss_idmap and define > attribute to lookup sssd The first patch looks good to me now, so Ack. Although I suspect Nalin would like to check it out as well prior to commiting it. I haven't dug deep into patch #2 yet, but user and group lookups work fine with the patch applied atop slapi-nis git master. User authentication doesn't work fine due to an issue that is being discussed separately. From jhrozek at redhat.com Tue Jul 16 15:19:53 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Jul 2013 17:19:53 +0200 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users In-Reply-To: <20130716132201.GK18587@redhat.com> References: <20130715171452.GE18587@redhat.com> <20130716125447.GJ9163@hendrix.brq.redhat.com> <20130716132201.GK18587@redhat.com> Message-ID: <20130716151953.GB22079@hendrix.brq.redhat.com> On Tue, Jul 16, 2013 at 04:22:01PM +0300, Alexander Bokovoy wrote: > On Tue, 16 Jul 2013, Jakub Hrozek wrote: > >the patch looks mostly good to me. I only have some small nitpicks: > > > >>+++ b/install/tools/man/ipa-adtrust-install.1 > >>@@ -106,6 +106,24 @@ The password of the user with administrative privileges for this IPA server. Wil > >> .TP > >> The credentials of the admin user will be used to obtain Kerberos ticket before configuring cross-realm trusts support and afterwards, to ensure that the ticket contains MS-PAC information required to actually add a trust with Active Directory domain via 'ipa trust-add --type=ad' command. > >> .TP > >>+\fB\-\-enable\-compat\fR > >>+Enables support for trusted domains users for old clients through Schema Compatibility plugin. > >>+SSSD supports trusted domains natively starting with version 1.9 platform. For platforms that > > ^^^^^^^^ > > The word "platform" > > looks a little > > extra here to me. > Removed. I initially had statement there to talk about Linux and > non-Linux platforms, this word slipped when I edited platform talk out. > > >>+lack SSSD or run older SSSD version one needs to use this option. When enabled, slapi\-nis package > >>+needs to be installed and schema\-compat\-plugin will be configured to provide lookup of > >>+users and groups from trusted domains via SSSD on IPA server. These users and groups will be > >>+available under \fBcn=users,cn=compat,$SUFFIX\fR and \fBcn=groups,cn=compat,$SUFFIX\fR trees. > >>+SSSD will normalize names of users and groups to lower case. > >>+.IP > >>+In addition to providing these users and groups through the compat tree, this option enables > >>+authentication over LDAP for trusted domain users with DN under compat tree, i.e. using bind DN > >>+\fBuid=administrator at ad.domain,cn=users,cn=compat,$SUFFIX\fR. This authentication is related > >>+to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled HBAC rule 'allow_all', then > >>+make sure there is special service called '\fBsystem\-auth\fR' created and HBAC rule to allow > >>+access to anyone to this rule on IPA masters is added. Please note that system-auth PAM service > >>+is not used directly by any other application, therefore it is safe to create one specifically > >>+to support trusted domain users via compatibility path. > > > >The last sentence wasn't really clear to me, were you suggesting to > >create a special PAM service? > I refactored the statement. > > system-auth is a PAM service (/etc/pam.d/system-auth) provided by pam > RPM package. You don't need to create it as it is created and maintained > by the system (and authconfig). > > What this sentence talks about is that PAM authentication means also > verifying HBAC rules. If you have disable 'allow_all' HBAC rule, then > for all PAM services there should be HBAC rule that allows access to it > if that is required. As in case of trusted AD users they don't exist in > LDAP, we cannot really refer to them in HBAC rules so we only can have > an HBAC rule that allows 'all' to access 'system-auth' service on 'ipa > masters' host group. > > system-auth PAM service is not used by any other application directly. > Instead, their own PAM services include system-auth through PAM stack. > That's why I selected system-auth -- enabling HBAC rules to access it > does not compromise any other service because of the way how PAM > stacking works -- access to an app is granted through PAM service name > that application runs against. I.e. ssh runs against /etc/pam.d/ssh, so > HBAC rule would need to be created against 'ssh' service. /etc/pam.d/ssh > is including system-auth through PAM stack and system-auth is configured > to use pam_sss but 'system-auth' as service name is never seen or used > by anyone through PAM API. > I know how system-auth works and how PAM services work, but it wasn't clear to me what you were suggesting in the man page :) Now it's much clearer, thank you. > >>+ if self.enable_compat: > >>+ self.step("Enabling trusted domains support for older clients via Schema Compatibility plugin", > > > > ^^^^ > > Nitpick: all the other steps begin with lowercased > > letter. Only this one is uppercased, which makes the > > tool output looks inconsistent: > >[15/21]: adding special DNS service records > >[16/21]: Enabling trusted domains support for older clients via Schema Compatibility plugin > >[17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes into account > Thanks. Lowcased it. > > Updated patch is attached. Maybe it would be nice if some native English speaker read the man page change as well. To me it sounds like there are some articles missing. But the code works correctly and sets up the SSSD compat attributes during install when told to. Ack from me, however. From pviktori at redhat.com Tue Jul 16 15:25:50 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Jul 2013 17:25:50 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool Message-ID: <51E565FE.8060202@redhat.com> This exposes tasks such as installation, uninstallation, clean-up should be available as CLI commands so they're available for non-Python tests. https://fedorahosted.org/freeipa/ticket/3721 It also allows tests to install IPA in a specific topology by setting the `topology` attribute to 'star', 'line', 'tree', etc. (so far only 'star' or none was supported). The first patches contain some refactoring/enhancements needed to make this possible. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0245-Move-BeakerLibProcess-out-of-BeakerLibPlugin.patch Type: text/x-patch Size: 9471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0246-test_integration-Add-log-collection-to-Host.patch Type: text/x-patch Size: 6313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0247-test_integration-Set-up-CA-on-replicas-by-default.patch Type: text/x-patch Size: 2006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0248-Add-more-test-tasks.patch Type: text/x-patch Size: 4992 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0249-Add-install_topo-to-test-tasks.patch Type: text/x-patch Size: 10081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0250-Add-the-ipa-test-task-tool.patch Type: text/x-patch Size: 13779 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jul 16 16:46:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Jul 2013 18:46:29 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI Message-ID: <51E578E5.40806@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0045-Expose-ipaRangeType-in-Web-UI.patch Type: text/x-patch Size: 8278 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 17 10:22:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 12:22:00 +0200 Subject: [Freeipa-devel] [PATCH] 414 Require new selinux-policy replacing old server-selinux subpackage Message-ID: <51E67048.5050307@redhat.com> Features of the new policy: - labels /var/lib/ipa/pki-ca/publish as pki_tomcat_cert_t which is writeable by PKI and readable by HTTPD - contains Conflicts with old freeipa-server-selinux package to avoid SELinux upgrade issues https://fedorahosted.org/freeipa/ticket/3788 ---- SELinux policy build is currently in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=434328 bodhi update is planned to be done today as well. I tested both upgrade from stable F19 version and clean installs and both worked fine. I would like this patch to be included in upcoming FreeIPA 3.2.2 version. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-414-require-new-selinux-policy-replacing-old-server-seli.patch Type: text/x-patch Size: 1554 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 17 11:13:18 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Jul 2013 13:13:18 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51E53844.7030709@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C420AA.4080007@redhat.com> <51E53844.7030709@redhat.com> Message-ID: <29240168.Pi7Yq2W5A1@thinkpad7.brq.redhat.com> On Tuesday 16 of July 2013 14:10:44 Jan Cholasta wrote: > On 21.6.2013 11:45, Tomas Babej wrote: > > Newly added features: > > > > - options propagated to plugins > > - made plugin content creation more comfortable, now 3 classes of > > output are > > available (debug, comment, command) > > > > Now pretty much everything that comes into my mind is addressed, so > > please have a look > > at the current implementation. > > The patch needs a rebase. > > + class AdviceLogger(object): > > Please don't use nested classes. If you want AdviceLogger to be > private-ish, you can rename it to _AdviceLogger. > > Also I think AdviceLogger is a little bit misleading name, I would > prefer AdviceOutput or something like that. > Fixed. > Functionally the patch is OK, but I have some second thoughts about the > design. I'm not sure if using API plugins is truly the right thing to > do, as advises seem to be pretty much orthogonal to the rest of our API. > There are some negative side effects, such as initializing the API every > time ipa-advise is run, for each and every advice, which takes some > time, so there is a short but noticable delay. What do you mean by that API is initialized for each and every advice? AFAIK, the advice plugins are all imported at once, the the API is initialized. They are imported only in the API 'advise' context, so no performance decrease for the rest of the framework. > What are the benefits of > using API plugins for this, besides code reuse? (I'm not saying this > must be changed, just give it some thought, using something simpler > might be better.) Code reuse is one thing. Also, ability to call the IPA commands from within the plugins is the second factor. To allow that we would have to inicialize the API anyway. Also some important constants which can be leveraged by the plugins are contained in api.env namespace. Taking into consideration that running ipa-advise is more of a one-time thing, I am willing to sacrifice a bit of delay in favour of these advantages. Updated patch attached. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0072-6-Provide-ipa-advise-tool.patch Type: text/x-patch Size: 20580 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 17 11:48:44 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Jul 2013 13:48:44 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <29240168.Pi7Yq2W5A1@thinkpad7.brq.redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C420AA.4080007@redhat.com> <51E53844.7030709@redhat.com> <29240168.Pi7Yq2W5A1@thinkpad7.brq.redhat.com> Message-ID: <51E6849C.8020706@redhat.com> On 17.7.2013 13:13, Tomas Babej wrote: > > + class AdviceLogger(object): > > > > > > Please don't use nested classes. If you want AdviceLogger to be > > > private-ish, you can rename it to _AdviceLogger. > > > > > > Also I think AdviceLogger is a little bit misleading name, I would > > > prefer AdviceOutput or something like that. > > > > > Fixed. Thanks. > > > Functionally the patch is OK, but I have some second thoughts about the > > > design. I'm not sure if using API plugins is truly the right thing to > > > do, as advises seem to be pretty much orthogonal to the rest of our API. > > > There are some negative side effects, such as initializing the API every > > > time ipa-advise is run, for each and every advice, which takes some > > > time, so there is a short but noticable delay. > > What do you mean by that API is initialized for each and every advice? For example when you run "ipa-advise config-fedora-authconfig", all of the ipalib and advise plugins are initialized. Seems like an overkill just to print 6 lines of text. > > AFAIK, the advice plugins are all imported at once, the the API is > initialized. > > They are imported only in the API 'advise' context, so no performance > decrease > > for the rest of the framework. > > > What are the benefits of > > > using API plugins for this, besides code reuse? (I'm not saying this > > > must be changed, just give it some thought, using something simpler > > > might be better.) > > Code reuse is one thing. Also, ability to call the IPA commands from > > within the plugins is the second factor. To allow that we would have to > > inicialize the API anyway. ... which could be done on-demand when it is actually needed. > > Also some important constants which can be leveraged by the plugins are > > contained in api.env namespace. > > Taking into consideration that running ipa-advise is more of a > > one-time thing, I am willing to sacrifice a bit of delay in > > favour of these advantages. OK. I still think that it's rather strange to pretend that advices are part of our API when they don't actually contribute anything to the API, but that's more of a structural problem, not a problem with your patch. > > Updated patch attached. ACK. Honza -- Jan Cholasta From tbabej at redhat.com Wed Jul 17 11:47:45 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Jul 2013 13:47:45 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51E4F433.6030901@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> Message-ID: <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> > I will release version 3.5 before end of this week. I have some small fixes > ready so it is worth to release it now. > > To summarize the discussion - please remove following options from > configuration file and LDAP schema: > cache_ttl > psearch (attribute idnsPersistentSearch in idnsConfigObject) > zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) > > -- > Petr^2 Spacek I have a patch ready, but it can't be tested until 3.5 is out. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-4-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 38479 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 17 11:52:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 13:52:49 +0200 Subject: [Freeipa-devel] [PATCH 0072] Provide ipa-client-advise tool In-Reply-To: <51E6849C.8020706@redhat.com> References: <1290988309.4979837.1371653165405.JavaMail.root@redhat.com> <51C420AA.4080007@redhat.com> <51E53844.7030709@redhat.com> <29240168.Pi7Yq2W5A1@thinkpad7.brq.redhat.com> <51E6849C.8020706@redhat.com> Message-ID: <51E68591.7060707@redhat.com> On 07/17/2013 01:48 PM, Jan Cholasta wrote: > On 17.7.2013 13:13, Tomas Babej wrote: >> > + class AdviceLogger(object): >> >> > >> >> > Please don't use nested classes. If you want AdviceLogger to be >> >> > private-ish, you can rename it to _AdviceLogger. >> >> > >> >> > Also I think AdviceLogger is a little bit misleading name, I would >> >> > prefer AdviceOutput or something like that. >> >> > >> >> Fixed. > > Thanks. > >> >> > Functionally the patch is OK, but I have some second thoughts about the >> >> > design. I'm not sure if using API plugins is truly the right thing to >> >> > do, as advises seem to be pretty much orthogonal to the rest of our API. >> >> > There are some negative side effects, such as initializing the API every >> >> > time ipa-advise is run, for each and every advice, which takes some >> >> > time, so there is a short but noticable delay. >> >> What do you mean by that API is initialized for each and every advice? > > For example when you run "ipa-advise config-fedora-authconfig", all of the > ipalib and advise plugins are initialized. Seems like an overkill just to print > 6 lines of text. In this case, it at least uses options from IPA server configuration (api.env) - which I think will be the case for most avices of this kind. > >> >> AFAIK, the advice plugins are all imported at once, the the API is >> initialized. >> >> They are imported only in the API 'advise' context, so no performance >> decrease >> >> for the rest of the framework. >> >> > What are the benefits of >> >> > using API plugins for this, besides code reuse? (I'm not saying this >> >> > must be changed, just give it some thought, using something simpler >> >> > might be better.) >> >> Code reuse is one thing. Also, ability to call the IPA commands from >> >> within the plugins is the second factor. To allow that we would have to >> >> inicialize the API anyway. > > ... which could be done on-demand when it is actually needed. > >> >> Also some important constants which can be leveraged by the plugins are >> >> contained in api.env namespace. >> >> Taking into consideration that running ipa-advise is more of a >> >> one-time thing, I am willing to sacrifice a bit of delay in >> >> favour of these advantages. > > OK. > > I still think that it's rather strange to pretend that advices are part of our > API when they don't actually contribute anything to the API, but that's more of > a structural problem, not a problem with your patch. > >> >> Updated patch attached. > > ACK. > > Honza > Pushed to master. Martin From pvoborni at redhat.com Wed Jul 17 11:53:21 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 17 Jul 2013 13:53:21 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI In-Reply-To: <51E578E5.40806@redhat.com> References: <51E578E5.40806@redhat.com> Message-ID: <51E685B1.4080401@redhat.com> On 07/16/2013 06:46 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. > Hello, Thanks for the patch, some comments: 1) idrange.js:183 I would avoid modifying widget html output in form methods. In this case you can simply add `layout: 'vertical'` to 'iparangetype' field definition. 2) idrange.js:187 Can be replaced by adding `enabled: false` to 'ipanttrusteddomainsid' field definition 3) I would rather see the switching logic encapsulated in a policy object than in a dialog. The main reason is to avoid using init() call in the factory. Most code other than method definitions in factory methods create mess in inheritance chain. Long term plan is to remove most of these calls. In this case, you can define public init method in the policy which will be automatically called after dialog instantiation. 4) IIUIC 'ipabaserid' have to be set together with 'ipanttrusteddomainsid' -> 'ipabaserid' should be made required when is_ad_trust is true. 5) As I read plugins/idrange.py:487-530, the logic for enabling/making required 'ipabaserid' and 'ipasecondarybaserid' is quite more complex than implemented. IIUIC 'ipasecondarybaserid' should be required and enabled only when 'ipabaserid' is set. Additionally, both should be required and enabled if adtrust_is_enabled (in UI: `IPA.trust_enabled`). -- Petr Vobornik From jpazdziora at redhat.com Wed Jul 17 12:06:00 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 17 Jul 2013 14:06:00 +0200 Subject: [Freeipa-devel] Should ipa.service be a service? Message-ID: <20130717120600.GK1972@redhat.com> On Mon, Jul 08, 2013 at 09:09:24AM -0400, Simo Sorce wrote: > On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: > > -After=network.target > > +After=network.target dirsrv.target > > pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service > > httpd.service krb5kdc.service messagebus.service nslcd.service > > nscd.service ntpd.service portmap.service rpcbind.service > > kadmin.service sshd.service autofs.service rpcgssd.service > > rpcidmapd.service chronyd.service > > > Won't this cause ipa.service to try to restart things twice ? > Also this will unconditionally try to start the CA even if not > installed. > > NACK, please let ipa.service handle starting and stopping daemons. Hello, I'm coming late to this thread but: Should ipa really be a service under systemd? Wouldn't making it a target make things a bit more pure from systemd's point of view? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Wed Jul 17 12:21:21 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Jul 2013 08:21:21 -0400 Subject: [Freeipa-devel] Should ipa.service be a service? In-Reply-To: <20130717120600.GK1972@redhat.com> References: <20130717120600.GK1972@redhat.com> Message-ID: <1374063681.30537.426.camel@willson.li.ssimo.org> On Wed, 2013-07-17 at 14:06 +0200, Jan Pazdziora wrote: > On Mon, Jul 08, 2013 at 09:09:24AM -0400, Simo Sorce wrote: > > On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: > > > -After=network.target > > > +After=network.target dirsrv.target > > > pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service > > > httpd.service krb5kdc.service messagebus.service nslcd.service > > > nscd.service ntpd.service portmap.service rpcbind.service > > > kadmin.service sshd.service autofs.service rpcgssd.service > > > rpcidmapd.service chronyd.service > > > > > Won't this cause ipa.service to try to restart things twice ? > > Also this will unconditionally try to start the CA even if not > > installed. > > > > NACK, please let ipa.service handle starting and stopping daemons. > > Hello, I'm coming late to this thread but: Should ipa really be > a service under systemd? Wouldn't making it a target make things a bit > more pure from systemd's point of view? IPA is a multi-server system, we want to keep configuration in LDAP so that an admin can see and potentially control services for the whole domain at once from an admin workstation, w/o having to log on any specific server and change local files. That is why we read the startup list from LDAP in ipactl (called by ipa.service) and do not store it as targets in systemd. ipactl supports both systemd and sysv systems. Once we definitively abandon sysv we could kill ipactl and in it's stead dynamically change the list of targets in the ipa.service file directly. and enable/disable the scripts in the systemd units directory. However we would still need some sort of plugin/helper system that monitors the LDAP tree and applies the appropriate changes to the system when something is changed in LDAP. We have expressed the need for acting on the system upon changes in LDAP for other reasons too (rotating some keytabs, and manipulating other configuration files), I think we opened a ticket to handle monitoring the configuration subtree with the ability to cause changes in the local cn=config based on plugin configuration but I can't find the ticket right now. We could add the ability to launch a helper (via dbus or similar). Once we have that we could move to a native systemd configuration, until then ... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jul 17 12:21:21 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Jul 2013 08:21:21 -0400 Subject: [Freeipa-devel] Should ipa.service be a service? In-Reply-To: <20130717120600.GK1972@redhat.com> References: <20130717120600.GK1972@redhat.com> Message-ID: <1374063681.30537.426.camel@willson.li.ssimo.org> On Wed, 2013-07-17 at 14:06 +0200, Jan Pazdziora wrote: > On Mon, Jul 08, 2013 at 09:09:24AM -0400, Simo Sorce wrote: > > On Thu, 2013-06-20 at 17:13 +0200, Ana Krivokapic wrote: > > > -After=network.target > > > +After=network.target dirsrv.target > > > pki-tomcatd at pki-tomcat.service pki-cad.target certmonger.service > > > httpd.service krb5kdc.service messagebus.service nslcd.service > > > nscd.service ntpd.service portmap.service rpcbind.service > > > kadmin.service sshd.service autofs.service rpcgssd.service > > > rpcidmapd.service chronyd.service > > > > > Won't this cause ipa.service to try to restart things twice ? > > Also this will unconditionally try to start the CA even if not > > installed. > > > > NACK, please let ipa.service handle starting and stopping daemons. > > Hello, I'm coming late to this thread but: Should ipa really be > a service under systemd? Wouldn't making it a target make things a bit > more pure from systemd's point of view? IPA is a multi-server system, we want to keep configuration in LDAP so that an admin can see and potentially control services for the whole domain at once from an admin workstation, w/o having to log on any specific server and change local files. That is why we read the startup list from LDAP in ipactl (called by ipa.service) and do not store it as targets in systemd. ipactl supports both systemd and sysv systems. Once we definitively abandon sysv we could kill ipactl and in it's stead dynamically change the list of targets in the ipa.service file directly. and enable/disable the scripts in the systemd units directory. However we would still need some sort of plugin/helper system that monitors the LDAP tree and applies the appropriate changes to the system when something is changed in LDAP. We have expressed the need for acting on the system upon changes in LDAP for other reasons too (rotating some keytabs, and manipulating other configuration files), I think we opened a ticket to handle monitoring the configuration subtree with the ability to cause changes in the local cn=config based on plugin configuration but I can't find the ticket right now. We could add the ability to launch a helper (via dbus or similar). Once we have that we could move to a native systemd configuration, until then ... Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Jul 17 12:45:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Jul 2013 14:45:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51E565FE.8060202@redhat.com> References: <51E565FE.8060202@redhat.com> Message-ID: <51E691F0.5080001@redhat.com> On 07/16/2013 05:25 PM, Petr Viktorin wrote: > This exposes tasks such as installation, uninstallation, clean-up should > be available as CLI commands so they're available for non-Python tests. > > https://fedorahosted.org/freeipa/ticket/3721 > > It also allows tests to install IPA in a specific topology by setting > the `topology` attribute to 'star', 'line', 'tree', etc. (so far only > 'star' or none was supported). > > The first patches contain some refactoring/enhancements needed to make > this possible. > I found a bug in patch 0246 and a typo in 0249. This update fixes them. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0245.2-Move-BeakerLibProcess-out-of-BeakerLibPlugin.patch Type: text/x-patch Size: 9471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0246.2-test_integration-Add-log-collection-to-Host.patch Type: text/x-patch Size: 6328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0247.2-test_integration-Set-up-CA-on-replicas-by-default.patch Type: text/x-patch Size: 2006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0248.2-Add-more-test-tasks.patch Type: text/x-patch Size: 4992 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0249.2-Add-install_topo-to-test-tasks.patch Type: text/x-patch Size: 10081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0250.2-Add-the-ipa-test-task-tool.patch Type: text/x-patch Size: 13779 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 17 13:21:33 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Jul 2013 15:21:33 +0200 Subject: [Freeipa-devel] [PATCH] 159 Run gpg-agent explicitly when encrypting/decrypting files Message-ID: <51E69A5D.5080505@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-159-Run-gpg-agent-explicitly-when-encrypting-decrypting-.patch Type: text/x-patch Size: 3390 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Jul 17 13:29:46 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 17 Jul 2013 15:29:46 +0200 Subject: [Freeipa-devel] Should ipa.service be a service? In-Reply-To: <1374063681.30537.426.camel@willson.li.ssimo.org> References: <20130717120600.GK1972@redhat.com> <1374063681.30537.426.camel@willson.li.ssimo.org> Message-ID: <20130717132946.GQ1972@redhat.com> On Wed, Jul 17, 2013 at 08:21:21AM -0400, Simo Sorce wrote: > > That is why we read the startup list from LDAP in ipactl (called by > ipa.service) and do not store it as targets in systemd. Can't the list in systemd be static and each service would identify (based on its own LDAP lookup or a lookup done by the first "service" in the row) whether it is actually configured to be running or not? > Once we definitively abandon sysv we could kill ipactl and in it's stead > dynamically change the list of targets in the ipa.service file directly. > and enable/disable the scripts in the systemd units directory. However > we would still need some sort of plugin/helper system that monitors the > LDAP tree and applies the appropriate changes to the system when > something is changed in LDAP. Upon the system/services startup or even during its general lifetime? > We have expressed the need for acting on the system upon changes in LDAP > for other reasons too (rotating some keytabs, and manipulating other > configuration files), I think we opened a ticket to handle monitoring > the configuration subtree with the ability to cause changes in the local > cn=config based on plugin configuration but I can't find the ticket > right now. > We could add the ability to launch a helper (via dbus or similar). > > Once we have that we could move to a native systemd configuration, until > then ... :-) -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Wed Jul 17 14:04:14 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Jul 2013 17:04:14 +0300 Subject: [Freeipa-devel] [PATCH] 414 Require new selinux-policy replacing old server-selinux subpackage In-Reply-To: <51E67048.5050307@redhat.com> References: <51E67048.5050307@redhat.com> Message-ID: <20130717140414.GN18587@redhat.com> On Wed, 17 Jul 2013, Martin Kosek wrote: >Features of the new policy: >- labels /var/lib/ipa/pki-ca/publish as pki_tomcat_cert_t which is > writeable by PKI and readable by HTTPD >- contains Conflicts with old freeipa-server-selinux package to avoid > SELinux upgrade issues > >https://fedorahosted.org/freeipa/ticket/3788 > >---- > >SELinux policy build is currently in koji: >http://koji.fedoraproject.org/koji/buildinfo?buildID=434328 > >bodhi update is planned to be done today as well. I tested both upgrade from >stable F19 version and clean installs and both worked fine. > >I would like this patch to be included in upcoming FreeIPA 3.2.2 version. > >Martin >From e0ad6af118eacf06c32f870106dc3d6159adcc66 Mon Sep 17 00:00:00 2001 >From: Martin Kosek >Date: Wed, 17 Jul 2013 12:13:50 +0200 >Subject: [PATCH] Require new selinux-policy replacing old server-selinux > subpackage > >Features of the new policy: >- labels /var/lib/ipa/pki-ca/publish as pki_tomcat_cert_t which is > writeable by PKI and readable by HTTPD >- contains Conflicts with old freeipa-server-selinux package to avoid > SELinux upgrade issues > >https://fedorahosted.org/freeipa/ticket/3788 >--- > freeipa.spec.in | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index f0f1fc6a266847e1d99a895605ed6084f080b7d4..b45525996e8b0e00397e975dc93a46bd4928bdbc 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -129,7 +129,7 @@ Requires: python-memcached > Requires: systemd-units >= 38 > Requires(pre): systemd-units > Requires(post): systemd-units >-Requires: selinux-policy >= 3.11.1-86 >+Requires: selinux-policy >= 3.12.1-65 > Requires(post): selinux-policy-base > Requires: slapi-nis >= 0.44 > Requires: pki-ca >= 10.0.2 >@@ -776,6 +776,10 @@ fi > %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt > > %changelog >+* Wed Jul 17 2013 Martin Kosek - 3.2.1-4 >+- Require selinux-policy 3.12.1-65 containing missing policy after removal of >+ freeipa-server-selinux subpackage >+ > * Tue Jul 16 2013 Martin Kosek - 3.2.1-3 > - Drop freeipa-server-selinux subpackage > - Drop redundant directory /var/cache/ipa/sessions ACK -- / Alexander Bokovoy From mkosek at redhat.com Wed Jul 17 14:06:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 16:06:57 +0200 Subject: [Freeipa-devel] [PATCH] 159 Run gpg-agent explicitly when encrypting/decrypting files In-Reply-To: <51E69A5D.5080505@redhat.com> References: <51E69A5D.5080505@redhat.com> Message-ID: <51E6A501.7050900@redhat.com> On 07/17/2013 03:21 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > There is a pylint problem: ipapython/ipautil.py:315: [E1103, run] Instance of 'int' has no 'close' member (but some types could not be inferred) Besides that, it seems to work just fine. Martin From jcholast at redhat.com Wed Jul 17 14:14:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Jul 2013 16:14:12 +0200 Subject: [Freeipa-devel] [PATCH] 159 Run gpg-agent explicitly when encrypting/decrypting files In-Reply-To: <51E6A501.7050900@redhat.com> References: <51E69A5D.5080505@redhat.com> <51E6A501.7050900@redhat.com> Message-ID: <51E6A6B4.9050500@redhat.com> On 17.7.2013 16:06, Martin Kosek wrote: > On 07/17/2013 03:21 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > There is a pylint problem: > > ipapython/ipautil.py:315: [E1103, run] Instance of 'int' has no 'close' member > (but some types could not be inferred) Fixed. > > Besides that, it seems to work just fine. > > Martin > Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-159.1-Run-gpg-agent-explicitly-when-encrypting-decrypting-.patch Type: text/x-patch Size: 3416 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 17 14:21:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 16:21:53 +0200 Subject: [Freeipa-devel] [PATCH] 159 Run gpg-agent explicitly when encrypting/decrypting files In-Reply-To: <51E6A6B4.9050500@redhat.com> References: <51E69A5D.5080505@redhat.com> <51E6A501.7050900@redhat.com> <51E6A6B4.9050500@redhat.com> Message-ID: <51E6A881.2080506@redhat.com> On 07/17/2013 04:14 PM, Jan Cholasta wrote: > On 17.7.2013 16:06, Martin Kosek wrote: >> On 07/17/2013 03:21 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >> >> There is a pylint problem: >> >> ipapython/ipautil.py:315: [E1103, run] Instance of 'int' has no 'close' member >> (but some types could not be inferred) > > Fixed. > >> >> Besides that, it seems to work just fine. >> >> Martin >> > > Updated patch attached. > > Honza > ACK. Pushed to master, ipa-3-2. Martin From mkosek at redhat.com Wed Jul 17 14:28:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 16:28:16 +0200 Subject: [Freeipa-devel] [PATCH] 414 Require new selinux-policy replacing old server-selinux subpackage In-Reply-To: <20130717140414.GN18587@redhat.com> References: <51E67048.5050307@redhat.com> <20130717140414.GN18587@redhat.com> Message-ID: <51E6AA00.2010801@redhat.com> On 07/17/2013 04:04 PM, Alexander Bokovoy wrote: > On Wed, 17 Jul 2013, Martin Kosek wrote: >> Features of the new policy: >> - labels /var/lib/ipa/pki-ca/publish as pki_tomcat_cert_t which is >> writeable by PKI and readable by HTTPD >> - contains Conflicts with old freeipa-server-selinux package to avoid >> SELinux upgrade issues >> >> https://fedorahosted.org/freeipa/ticket/3788 >> >> ---- >> >> SELinux policy build is currently in koji: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=434328 >> >> bodhi update is planned to be done today as well. I tested both upgrade from >> stable F19 version and clean installs and both worked fine. >> >> I would like this patch to be included in upcoming FreeIPA 3.2.2 version. >> >> Martin > >> From e0ad6af118eacf06c32f870106dc3d6159adcc66 Mon Sep 17 00:00:00 2001 >> From: Martin Kosek >> Date: Wed, 17 Jul 2013 12:13:50 +0200 >> Subject: [PATCH] Require new selinux-policy replacing old server-selinux >> subpackage >> >> Features of the new policy: >> - labels /var/lib/ipa/pki-ca/publish as pki_tomcat_cert_t which is >> writeable by PKI and readable by HTTPD >> - contains Conflicts with old freeipa-server-selinux package to avoid >> SELinux upgrade issues >> >> https://fedorahosted.org/freeipa/ticket/3788 >> --- >> freeipa.spec.in | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index >> f0f1fc6a266847e1d99a895605ed6084f080b7d4..b45525996e8b0e00397e975dc93a46bd4928bdbc >> 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -129,7 +129,7 @@ Requires: python-memcached >> Requires: systemd-units >= 38 >> Requires(pre): systemd-units >> Requires(post): systemd-units >> -Requires: selinux-policy >= 3.11.1-86 >> +Requires: selinux-policy >= 3.12.1-65 >> Requires(post): selinux-policy-base >> Requires: slapi-nis >= 0.44 >> Requires: pki-ca >= 10.0.2 >> @@ -776,6 +776,10 @@ fi >> %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt >> >> %changelog >> +* Wed Jul 17 2013 Martin Kosek - 3.2.1-4 >> +- Require selinux-policy 3.12.1-65 containing missing policy after removal of >> + freeipa-server-selinux subpackage >> + >> * Tue Jul 16 2013 Martin Kosek - 3.2.1-3 >> - Drop freeipa-server-selinux subpackage >> - Drop redundant directory /var/cache/ipa/sessions > > ACK > Pushed to master (rebased), ipa-3-2. Martin From akrivoka at redhat.com Wed Jul 17 14:38:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 17 Jul 2013 16:38:29 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file Message-ID: <51E6AC65.1030601@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0046-Properly-handle-non-existent-CA-file.patch Type: text/x-patch Size: 968 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 17 14:57:28 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Jul 2013 16:57:28 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E6AC65.1030601@redhat.com> References: <51E6AC65.1030601@redhat.com> Message-ID: <51E6B0D8.1000502@redhat.com> Hi, On 17.7.2013 16:38, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. > NACK, this results in an unnecessarily ugly error message "[Errno 2] No such file or directory: 'file'". I would suggest something like this instead: except IOError as e: raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) Can you please also check what happens if you pass non-existent filename to --dirsrv_pkcs12 and --http_pkcs12? Honza -- Jan Cholasta From akrivoka at redhat.com Wed Jul 17 15:39:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 17 Jul 2013 17:39:58 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E6B0D8.1000502@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> Message-ID: <51E6BACE.6030304@redhat.com> On 07/17/2013 04:57 PM, Jan Cholasta wrote: > Hi, > > On 17.7.2013 16:38, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >> > > NACK, this results in an unnecessarily ugly error message "[Errno 2] No such > file or directory: 'file'". > > I would suggest something like this instead: > > except IOError as e: > raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) Fixed. > > Can you please also check what happens if you pass non-existent filename to > --dirsrv_pkcs12 and --http_pkcs12? > > Honza > I added a more specific error message to cover these cases. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0046-02-Properly-handle-non-existent-cert-files.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 17 16:04:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Jul 2013 18:04:13 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E6BACE.6030304@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> Message-ID: <51E6C07D.3080007@redhat.com> On 17.7.2013 17:39, Ana Krivokapic wrote: > On 07/17/2013 04:57 PM, Jan Cholasta wrote: >> Hi, >> >> On 17.7.2013 16:38, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>> >> >> NACK, this results in an unnecessarily ugly error message "[Errno 2] No such >> file or directory: 'file'". >> >> I would suggest something like this instead: >> >> except IOError as e: >> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) > > Fixed. Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, I think it would make sense to catch the IOError right in import_pem_cert and re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 (sorry for misleading you into doing something else in my previous mail). >> >> Can you please also check what happens if you pass non-existent filename to >> --dirsrv_pkcs12 and --http_pkcs12? >> >> Honza >> > > I added a more specific error message to cover these cases. Can you please also add it to find_root_cert_from_pkcs12? > > Updated patch attached. > Honza -- Jan Cholasta From simo at redhat.com Wed Jul 17 16:25:20 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Jul 2013 12:25:20 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <51E56376.6000606@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> Message-ID: <1374078320.32040.96.camel@willson.li.ssimo.org> On Tue, 2013-07-16 at 17:15 +0200, Petr Spacek wrote: > On 15.7.2013 21:07, Simo Sorce wrote: > > Is there any place I can read about the format and requirements of these > > files ? > There is no single format, because it is algorithm-dependent. See below. AFAIK > it is nothing supported by OpenSSL, but I can be wrong. Thanks for attaching examples, it helps. > >> KSK has to be rolled over manually because it requires changes in parent zone. > >> (It could be automated for sub-zones if their parent zone is also managed by > >> the same IPA server.) > > > > Is there any provision for using DNSSEC with private DNS deployments ? > Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS resolvers > can be configured with 'trust anchors' explicitly. E.g. 'trust domain > example.com only if it is signed by /this/ key, use root key for rest of the > Internet' etc. > > [Terminology] http://tools.ietf.org/html/rfc4033#section-2 This means clients would have to be configured to explicitly trust a specific key for a zone right ? How hard would it be for us to configure IPA clients this way assuming by then we have a DNSSEC aware resolver we can configure on them ? > > Or is this going to make sense only for IPA deployments that have valid > > delegation from the public DNS system ? > > > > Hmmm I guess that as long as the KSK in the 'parent' zone is imported > > properly a private deployment of corp.myzone.com using the KSK of > > myzone.com will work just fine even if corp.myzone.com is not actually > > delegated but is a private DNS tree ? > > Or is that incorrect ? > > AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from > the parent, but IMHO it could work if only the public key for internal zones > is published (without any delegation to internal name servers etc.). I didn't > try it, so 'here be dragons'. Are there test/zones keys that can be used to experiment ? [..] > >> Initial key generation is closely related to the question how should we handle > >> (periodic) key regeneration? (e.g. "Generate new ZSK each month.") > > > > We only really need to generate (or import) the KSK of the parent zone, > It seems that there is slight misunderstanding. KSK is the 'master key' for > particular zone. This master key (KSK) signs other keys (ZSKs) and data are > signed by ZSKs. Sorry I expressed myself badly, I mean we only need to generate one KSK at install time and make it available to the admin to be signed by the upper zone admins. But then all other keys including the ZSKs can be completely managed within IPA w/o explicit admin work if we have the right tooling. [..] > > No, the problem is that we need to define 'who' generates the keys. > > Remember FreeIPA is a multimaster system, we cannot have potentially > > conflicting cron jobs running on multiple servers. > Right. It sounds like the CRL generation problem. Should we do the same for > DNSSEC key regeneration? I.e. select one super-master and let it to handle key > regeneration? Or should we find some more robust solution? I'm not against any > of these possibilities :-) Falling back to SPOF should be the last resort or a temporary step during development. I would like to avoid SPOF architectures if at all possible. We could devise a way to automatically 'elect' a master, but have all other DNS servers also monitor that keys are regenerated an made available in the expected time frame and if not have one of the other DNS servers try to assume the leader role. I have some ideas hear using priorities etc, but I need to let them brew in my mind a little bit more :) [..] > >> For these reasons I think that we can define new public key attribute in the > >> same way as private key attribute: > >> attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX > >> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) > >> > >> The resulting object class could be: > >> objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP > >> top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) > > > > Will bind read these attributes ? > > Or will we have to dump these values into files via bind-dyndb-ldap for > > bind9 to read them back ? > AFAIK it has to be in files: Private key in one file and public key in the > other file. I can't find any support for reading private keys from buffers. Ok so to summarize we basically are going to load the private key file in idnsSecPrivateKey and the public key file in idnsSecPublicKey as blobs and the have bind-dyndb-ldap fetch them and save them into files that bind can access. This means bind-dyndb-ldap will need to grow the ability to also clean p and synchronize the files over time. So there will need to be hooks to regularly check all needed files are in place and obsolete ones are deleted. Maybe we can grow a companion python helper to do this, as it is a relatively simple task, that is not performance critical and will be much easier to write in a scripting language than in C. But I am not opposed to an in-daemon solution either. [..] > > ack, should we have an explicit attribute that tells us what type it > > is ? > May be, we will see. It is possible that we will need to store key algorithm > and key ID explicitly for some reason. > > I'm still not sure that I understand to all aspects of key management in BIND. Ok, so I guess we need some reasearch in here before committing 100% to a plan, but so far it looks like the general plan is clear enough. > > One weak reason to allow read by admins would be to allow them to > > migrate away, but I do not like to put these keys completely unprotected > > in LDAP. Given bind has a keytab I was thinking we may want to encrypt > > these keys with the DNS long term key, however this complicates the code > > slightly in 2 ways: > > 1. we can have multiple DNS Servers (ie multiple keys) > > 2. we need to allow for roll-over > > I see two more problems: > 3. it would make Kerberos required (now the plugin doesn't require Kerberos) It could be optional, if the option is not enabled no master-key encryption scheme is used. > 4. we use SASL but I think that your approach would require direct > manipulation with keytab Yes we'd need to read the keytab to get the long term key, but we could defer this to a companion tool in python as I mentioned before and let bind-dyndb-ldap ignorant of the keytab. Actually this is a quite compelling argument, as this means we could use gssproxy to not give access to the keytab at all to the bind process, thus adding extra privilege seapration and protection, The python companion would instea dneed access so communication between bind-dyndb-ldap and the companion daemon would need to happen cross trust boundary, ie a socket and/or systemd/dbus activation or similar. > > To simplify the matter we would have to use a 'master key' that encrypts > > all signing keys and is made available to DNS servers encrypted with > > their keys. > > > > Master key needs to allow for roll over in case it is compromised. But > > we could deal with it by simply rolling also all DNS keys and encrypting > > the new ones with the new key. After all if the key was compromised we > > must assume all DNs signing keys may have been compromised so a full > > roll-over is necessary. This simplifies the problem because it means we > > will never need to store the same DNS signing key encrypted with > > multiple 'master keys'. > > > > A master key also allows for easy addition/removal of DNS servers as it > > needs to be re-encrypted only once when a new DNS is added (or removed > > and readded), and a server removal is just a delete operation. > > Oooo, lots of fun. Are you aware of any abstraction layer which could all the > magic for us? Something from OpenSSL/SASL/GSSAPI? I didn't mention Dogtag > because dependency on Dogtag might become my nightmare... :-) Not really, I think we may have to do our own, but we'll reuse what NSS/OpenSSL or krb libraries make available to do wrapping on this stuff so that we do not create some horrible easy to break scheme. [..] > > Should we add these attributes explicitly in the 'idnsSecKeyPair' > > objetclass instead and reconstruct the private key file from there ? > > Or would that risk being incompatibile with a future new key type ? > That is exactly why I proposed the 'blob' approach. Each algorithm needs > different values, so RSA and DSA key formats differ. See attachments - these > files were written by dnssec-keygen for RSASHA1 and DSA. > > Formats are *similar* at the moment, but the problem is that parsers for each > algorithm can diverge in the future. And blob it is ... sold! :) > > If so should we really split key material in 2 attributes? Or should we > > rather just load the full file content in a single attribute as an > > opaque blob ? > BIND 9 stores public and private keys separately in two files, so I would > imitate it's approach - with two separate attributes. ok > >> 3) How will the configuration be stored? > >> Parameters are: > >> - DNSSEC enabled/disabled for one zone or globally - proposal: add a new > >> boolean attribute idnsSecInlineSigning to zone and global config object > > > > why not simply iDNSSECenabled: TRUE/FALSE ? > I would like to imitate BIND's config - we plan to do the same thing as BIND's > option 'inline-signing'. ok > BIND will do signing for us, but at some point in the future we could decide > to do signing ourselves etc. More specific name prevents confusion when we > need to change behaviour. makes sense > >> - NSEC3 parameters - proposal: use standard NSEC3PARAM record in the zone > > > > What are these ? > Short answer: > http://www.simpledns.com/help/v52/rec_nsec3param.htm > > Long answer: > DNS Security (DNSSEC) Hashed Authenticated Denial of Existence > http://tools.ietf.org/html/rfc5155#section-4 Interesting. > >> The rest of the configuration options are related to the key management > >> problem. We need to know: > >> - how many key pairs (e.g. 2 KSKs, 2 ZSKs) > > > > Shouldn't we allow an arbitrary number ? Does bind have strict limits ? > Yes, arbitrary number sounds fine. 2 + 2 was just an example. > > >> - when (e.g. generate new key pair 30 days before active key expires) > > > > probably needs to be tunable. new attribute ? > > > >> - of which key types (KSK or ZSK) > >> - with which algorithms > >> - with which key lengths > >> should be generated. Note that we need to store configuration about X KSKs and > >> Y ZSKs. > > > > seem all of these needs to be tunables and require their own > > attributes ? > I agree. The question is how to group the attributes to make it useful. ok > IMHO it should express something like this: > - I want to use 1 KSK with algorithm RSASHA1, key length 2048 bits, the key > should be used for 1 year. > - I want to have 1 other KSK (with same parameters) ready for roll over at any > time. > - Roll over period is 1 month. (The time required for incremental resigning > with the new key, i.e. the time period when old and new signatures will co-exist.) > > The result should be: > > In time 0 (zone creation), generate 2 KSKs: > The KSK 'A' would have these timestamps: > - created = published = active from = 0 (generate signatures immediately) > - inactive = 0 + 1 year - 1 month (stop generating signatures after 11 months) > - delete = 0 + 1 year (one month was transitional period for incremental > resigning with the new key, then delete the key 'A') > > The KSK 'B' would be generated at the same time as 'A': > - created = published = 0 (publish key, but don't generate signatures) > - active from = 0 + 1 year > - inactive = 0 + 2 years - 1 month > - delete = 0 + 2 years > > During the first year, all records will be signed with KSK 'A'. In time '0 + 1 > year - 1 month' KSK 'A' will become inactive and KSK 'B' will become active. > At the same time, new KSK 'C' will be generated with following timestamps: > - created = published = 1 year - 1 month (publish key, but don't generate > signatures) > - active from = 0 + 2 year - 1 month > - inactive = 0 + 3 years - 1 month > - delete = 0 + 3 years > > All records will be re-signed using KSK 'B' during time <1 year - 1 month, 1 > year>. > > In time '0 + 1 year' all signatures were regenerated with using KSK 'B' and > KSK 'A' will be removed. shouldn't we regenerate all signatures with KSK B at '0 + 11mo', ie 1 month before KSK A is finally deleted ? > Note that you may want to use 1 KSK with algorithm RSA and another KSK with DSA. Ok > I'm not really sure if it makes sense. Could something like this work? > > objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyGroup' DESC 'DNSSEC key group' SUP > top STRUCTURAL MUST > ( cn $ > key type $ # (KSK or ZSK) > algorithm $ # (RSA, DSA) > key length $ # (2048) > lifetime of the key $ # (1 year) > roll over period $ # (1 month) > number of active keys $ # (1) > number of spare keys $ # (1) > ) ) To summarize it seem you have 2 distinctive objects you really need. 1. additional parameters to the key (active time and delete time, and although those times are also embedded in the blob they should probably be replicated also in idnsSecKeyPair objectclass so that this info can be easily queried w/o needing access to the key material itself. 2. a policy about how often you want to rotate and use keys, and what parameters to use by default when creating new keys automatically at rotation time. And that policy may need to be per zone. so I would rename 'idnsSecKeyGroup' to 'idnsSecKeyPolicy', make it auxiliary and add it to the zone object when DNSSEc is in use. The attributes you mention seem all is needed. > The key group could be stored as > cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test > Keys could be stored as individual objects under > cn=id, cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test This is also an option, but why an aditional object when we can simply ad the attributes to the zone file ? Is there any instance where you might want multiple policies for zones? (I do not see how that would work) > In usual cases it solves grouping of KSKs and ZSKs. Why do you need to further 'group' them ? > Also, it enables us to > define key group with RSA and another one with DSA algorithm or to migrate > from a key group with shorter keys to a key group with longer keys. I am not sure how this would help, isn't is sufficient to add the 'type' to 'idnsSecKeyPair', so you know what type it is regardless ? Although I am not even sure why we would care, bind is the one doing the signing and the type is already known to bind as it reads it from the private file, right ? I may be missing some detail here ... [..] > I have a crazy idea: Could OpenSSL PKCS#11 implementation help us to deal with > the key management problems mentioned above - somehow? > > I know next to nothing about PKCS#11 and related areas, but problems we met > (like safe key storage & transport) sounds like something common. > > Could we use PKCS#11 in some clever way, let OpenSSL to do the dirty work with > key encryption/retrieval and solve HSM support and security at once? Yes we will certainly reuse crypto primitives from NSS or OpenSSL, but that doesn't help with 'key management' itself, that's on us :) > Would it be possible to write PKCS#11 module for OpenSSL and let it to store > keys in IPA - in some generic way? So it will solve key storage for all > OpenSSL/PKCS#11 enabled applications and not only for bind-dyndb-ldap? Dogtag has a generic store, but a generic store is not really our problem here. and I am not sure we want to tie this to dogtag, we might. > As I said, it is just crazy idea ... and I really know nothing about this area. Let's explore and see pros/cons. , the main con I see to involving dogtag is that it would force us to install dogtag on each DNS server (or risk having keys in a remote server so net communicationa nd additional issues of reachability). I think we want to be able to keep installing FreeIPA+DNS and FreeIPA+CA and not force FreeIPa+DNS+CA for all DNS servers, as we might want a 'lightweight' FreeIPA+DNS replica or even in future just a LDAP+DNS 'replica' only for load balancing of DNSes, so forcing the full CA dependency would be undesirable. Extreme case, given syncrepl will keep everything synced locally we may even go with bind+bind-dyndb-ldap *only* and rely on remote LDAP server to bind to ... Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Jul 17 16:47:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Jul 2013 18:47:59 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.2.2 Message-ID: <51E6CABF.5080202@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.2.2. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 and is on its way to updates-testing. == Highlights in 3.2.2 == === New features for 3.2.2 === * Significant improvement of performance with large number of users or groups. Several LDAP server indexes were added for this purpose. * freeipa-server-selinux package with custom FreeIPA SELinux policy is dropped, all policy is now contained in system policy package === Bug fixes === * Removes systemd-related deadlock when a server with running FreeIPA services is restarted * Fixes ownership issues in CRL publishing directory (/var/lib/ipa/pki-ca/publish/) * ipa-replica-prepare and ipa-replica-install now do not crash on system with gnupg2 package only (without older gnupg package) * CRL file can now be retrieved via plain http protocol without redirection to https, as defined in certificates published by FreeIPA * Entitlement plugin is removed from FreeIPA codebase as it was neither supported nor tested * Many bugfixes related to CA-less installation * ... and many others stabilization fixes, see Detailed changelog for full details == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the performance improvements requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.2.1 == === Ana Krivokapic (8): === * Fix displaying of success message * Improve handling of options in ipa-client-install * Do not display traceback to user * Fix bug in adtrustinstance * Use correct DS instance in ipactl status * Avoid systemd service deadlock during shutdown * Make sure replication works after DM password is changed * Use --ignore-dependencies only when necessary === Jan Cholasta (16): === * Use the correct PKCS#12 file for HTTP server. * Remove stray error condition in ipa-server-install. * Handle exceptions gracefully when verifying PKCS#12 files. * Skip empty lines when parsing pk12util output. * Do not allow installing CA replicas in CA-less setup. * Do not track DS certificate in CA-less setup. * Fix CA-less check in ipa-replica-install and ipa-ca-install. * Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns. * Skip cert issuer validation in service and host commands in CA-less install. * Check trust chain length in CA-less install. * Use LDAP search instead of *group_show to check if a group exists. * Use LDAP search instead of *group_show to check for a group objectclass. * Use LDAP modify operation directly to add/remove group members. * Add missing substring indices for attributes managed by the referint plugin. * Add missing equality index for ipaUniqueId. * Run gpg-agent explicitly when encrypting/decrypting files. === Lukas Slebodnik (1): === * Use pkg-config to detect cmocka === Martin Kosek (7): === * Remove entitlement support * Enable SASL mapping fallback. * Drop SELinux subpackage * Drop redundant directory /var/cache/ipa/sessions * Run server upgrade and restart in posttrans * Require new selinux-policy replacing old server-selinux subpackage * Become 3.2.2 === Nathaniel McCallum (3): === * Fix client install exception if /etc/ssh is missing * Permit reads to ipatokenRadiusProxyUser objects * Fix for small syntax error in OTP schema === Petr Vobornik (5): === * Regression fix: rule table with ext. member support doesn't offer any items * Fix default value selection in radio widget * Do not redirect to https in /ipa/ui on non-HTML files * Create Firefox configuration extension on CA-less install * Disable checkboxes and radios for readonly attributes === Rob Crittenden (1): === * Return the correct Content-type on negotiated XML-RPC requests. === Sumit Bose (1): === * Fix type of printf argument === Tomas Babej (2): === * Do not redirect ipa/crl to HTTPS * Change group ownership of CRL publish directory From npmccallum at redhat.com Wed Jul 17 17:13:27 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 17 Jul 2013 13:13:27 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] Use libunistring ulc_casecmp() on unicode strings In-Reply-To: <874767960.2148021.1374081180375.JavaMail.root@redhat.com> Message-ID: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0012-Use-libunistring-ulc_casecmp-on-unicode-strings.patch Type: text/x-patch Size: 6145 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jul 17 17:43:09 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 17 Jul 2013 19:43:09 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E6C07D.3080007@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> <51E6C07D.3080007@redhat.com> Message-ID: <51E6D7AD.3090906@redhat.com> On 07/17/2013 06:04 PM, Jan Cholasta wrote: > On 17.7.2013 17:39, Ana Krivokapic wrote: >> On 07/17/2013 04:57 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 17.7.2013 16:38, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>>> >>> >>> NACK, this results in an unnecessarily ugly error message "[Errno 2] No such >>> file or directory: 'file'". >>> >>> I would suggest something like this instead: >>> >>> except IOError as e: >>> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) >> >> Fixed. > > Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, > I think it would make sense to catch the IOError right in import_pem_cert and > re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 > (sorry for misleading you into doing something else in my previous mail). I don't see much value in doing that - it just adds complexity. I would rather leave it as it is. > >>> >>> Can you please also check what happens if you pass non-existent filename to >>> --dirsrv_pkcs12 and --http_pkcs12? >>> >>> Honza >>> >> >> I added a more specific error message to cover these cases. > > Can you please also add it to find_root_cert_from_pkcs12? Done, thanks for catching that. > >> >> Updated patch attached. >> > > Honza > Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0046-03-Properly-handle-non-existent-cert-files.patch Type: text/x-patch Size: 2368 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jul 17 19:18:21 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 17 Jul 2013 21:18:21 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets Message-ID: <51E6EDFD.8060103@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0047-Honor-enabled-option-for-widgets.patch Type: text/x-patch Size: 963 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 18 07:25:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 09:25:10 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E6D7AD.3090906@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> <51E6C07D.3080007@redhat.com> <51E6D7AD.3090906@redhat.com> Message-ID: <51E79856.1050702@redhat.com> On 17.7.2013 19:43, Ana Krivokapic wrote: > On 07/17/2013 06:04 PM, Jan Cholasta wrote: >> On 17.7.2013 17:39, Ana Krivokapic wrote: >>> On 07/17/2013 04:57 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 17.7.2013 16:38, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>>>> >>>> >>>> NACK, this results in an unnecessarily ugly error message "[Errno 2] No such >>>> file or directory: 'file'". >>>> >>>> I would suggest something like this instead: >>>> >>>> except IOError as e: >>>> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) >>> >>> Fixed. >> >> Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, >> I think it would make sense to catch the IOError right in import_pem_cert and >> re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 >> (sorry for misleading you into doing something else in my previous mail). > > I don't see much value in doing that - it just adds complexity. I would rather > leave it as it is. All the other NSSDatabase methods raise RuntimeErrors when something goes wrong, including I/O errors. IMO having consistent API is preferable to saving 2 lines of code. >> >>>> >>>> Can you please also check what happens if you pass non-existent filename to >>>> --dirsrv_pkcs12 and --http_pkcs12? >>>> >>>> Honza >>>> >>> >>> I added a more specific error message to cover these cases. >> >> Can you please also add it to find_root_cert_from_pkcs12? > > Done, thanks for catching that. >> >>> >>> Updated patch attached. >>> >> >> Honza >> > > Updated patch is attached. > Honza -- Jan Cholasta From pvoborni at redhat.com Thu Jul 18 07:47:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 09:47:16 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51E6EDFD.8060103@redhat.com> References: <51E6EDFD.8060103@redhat.com> Message-ID: <51E79D84.7010304@redhat.com> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. > Hello, 1) IMO we should not create attribute which is just a negation of another. 2) We should add set_enabled method to base widget. Existing set_enabled methods should use it and maintain widget output consistent with the attribute (ie. one should not directly set the attr and should use set_enabled instead). The method should be also callable when content is not yet created. get_enabled methods might become unnecessary - one can get the state form 'enabled' attribute. -- Petr Vobornik From abokovoy at redhat.com Thu Jul 18 07:51:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 10:51:16 +0300 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers In-Reply-To: <51E0219F.8030604@redhat.com> References: <51E01637.9040102@redhat.com> <51E0219F.8030604@redhat.com> Message-ID: <20130718075116.GP18587@redhat.com> On Fri, 12 Jul 2013, Rob Crittenden wrote: > Rob Crittenden wrote: >> Add the Camellia ciphers to the supported list in the KDC. >> >> Also exclude some attributes from being displayed in LDAP updater logs. >> >> rob > > I've split the Camellia patch out from the updater patch to clarify things. Thanks, pushed to master. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 18 07:57:47 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 10:57:47 +0300 Subject: [Freeipa-devel] [PATCH] 0044 Add 'ipa_server_mode' option to SSSD configuration In-Reply-To: <51E3F3FB.5060600@redhat.com> References: <51E3F3FB.5060600@redhat.com> Message-ID: <20130718075747.GQ18587@redhat.com> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >Hello, > >This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. Could you please rebase it on top of git master? -- / Alexander Bokovoy From tbabej at redhat.com Thu Jul 18 08:01:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 18 Jul 2013 10:01:59 +0200 Subject: [Freeipa-devel] Unused trusted range cannot be deleted Message-ID: <14469431.e3VoEnUbR0@thinkpad7.brq.redhat.com> Hi, please have a look at the following ticket: https://fedorahosted.org/freeipa/ticket/3787 Basically the problem here is that we do not allow the deletion of a range that belongs to an active trust. This functionality was added in scope of 3.3 AFAIK. However, the admin is not allowed to delete the range even if it is empty (i.e. if he added a range of a wrong type by mistake, and wants to delete it). So, the rational conclusion here is that we should check if there are any objects in the range. However, such check can be expensive for deployments with a large number of users and groups. >From the discussion with Alexander: (02:20:07 PM) ab: 1. search for existence of ID could be expensive for many users/groups (02:20:43 PM) ab: 2. the fact that range is there and seemingly unused in LDAP does not mean there are no users of those IDs at file system (02:20:51 PM) ab: and you cannot check (2) at all (02:22:39 PM) ab: tbabej: if we ever adding something like that, it needs to come with LARGE banner (02:22:55 PM) ab: because it is a tool to break the system Still, running the ipa idrange-del command should not happen often (unlike, say, user-add) so performance should not be such an issue. To address (2), maybe we should add an --force (or some other appropriately named) option, that would allow deletion of an range of an active trust, if we find it to be empty (according to the LDAP). As for the Web UI, this could be implemented via a checkbox option (we already have this functionality in some other dialogues). Opinions? Tomas From thozza at redhat.com Thu Jul 18 08:06:50 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 18 Jul 2013 10:06:50 +0200 Subject: [Freeipa-devel] [PATCH 0174] Fix crash during zone_refresh triggered by connection failure In-Reply-To: <51E3F579.2010908@redhat.com> References: <51E3F579.2010908@redhat.com> Message-ID: <51E7A21A.6060902@redhat.com> On 07/15/2013 03:13 PM, Petr Spacek wrote: > Hello, > > Fix crash during zone_refresh triggered by connection failure. > > Variable 'iter' was initialized too late. Code in cleanup section of > refresh_zones_from_ldap() dereferenced the uninitialized variable. > ACK. The crash is fixed. Regards, Tomas Hozza From thozza at redhat.com Thu Jul 18 08:08:22 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 18 Jul 2013 10:08:22 +0200 Subject: [Freeipa-devel] [PATCH 0175-0177] Prepare transition from persistent search to RFC 4533 In-Reply-To: <51E4FE76.4070408@redhat.com> References: <51E4FE76.4070408@redhat.com> Message-ID: <51E7A276.1030807@redhat.com> On 07/16/2013 10:04 AM, Petr Spacek wrote: > Hello, > > this patch set changes default configuration to 'psearch yes' and > changes README and informational messages accordingly. > ACK. Regards, Tomas Hozza From thozza at redhat.com Thu Jul 18 08:09:25 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 18 Jul 2013 10:09:25 +0200 Subject: [Freeipa-devel] [PATCH 0178-0179] Preparation for 3.5 release In-Reply-To: <51E500C7.6090802@redhat.com> References: <51E500C7.6090802@redhat.com> Message-ID: <51E7A2B5.5060201@redhat.com> On 07/16/2013 10:13 AM, Petr Spacek wrote: > Hello, > > I plan to release 3.5 as soon as all previous patches are ACKed. > ACK. Regards, Tomas Hozza From abokovoy at redhat.com Thu Jul 18 08:10:45 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 11:10:45 +0300 Subject: [Freeipa-devel] Proposal to have spec changes as a separate patch In-Reply-To: <20130718075747.GQ18587@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> Message-ID: <20130718081045.GR18587@redhat.com> On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>Hello, >> >>This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. >Could you please rebase it on top of git master? BTW, I was thinking on it and given that majority of rebases like this one come due to spec changes, may be we could establishe a practice to send spec-related changes as a separate patch in a patchset? This would allow easily testing the actual code changes since you don't really need spec changes at that point or could handle it clearer with pre-installed build dependencies. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jul 18 08:58:34 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 10:58:34 +0200 Subject: [Freeipa-devel] [PATCH 0171-0172] Fix potential problems found by Clang static analyzer In-Reply-To: <51DD7398.9090807@redhat.com> References: <51DA7D9D.3060201@redhat.com> <51DD7398.9090807@redhat.com> Message-ID: <51E7AE3A.7010808@redhat.com> On 10.7.2013 16:45, Tomas Hozza wrote: > On 07/08/2013 10:51 AM, Petr Spacek wrote: >> >Hello, >> > >> >several warnings from Clang static analyzer popped up after upgrade to >> >Fedora 19. Attached patches should fix all problems found by >> >clang-analyzer-3.3-0.6.rc3.fc19.x86_64. >> > > ACK Pushed to v3: 2933ca2e6563c05d1e620542a8b8d024053d2088 f467aab9f6b435d7bf1bf101657ca05195aeefb7 -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 18 08:58:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 10:58:03 +0200 Subject: [Freeipa-devel] [PATCH 0169-0170] Modernize autotools configuration In-Reply-To: <51DD6294.9050000@redhat.com> References: <51D57744.5080807@redhat.com> <20130710082934.GA7205@mail.corp.redhat.com> <51DD36FC.3070201@redhat.com> <51DD6294.9050000@redhat.com> Message-ID: <51E7AE1B.8040208@redhat.com> On 10.7.2013 15:33, Tomas Hozza wrote: > On 07/10/2013 12:27 PM, Petr Spacek wrote: >> On 10.7.2013 10:29, Lukas Slebodnik wrote: >>> On (04/07/13 15:23), Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> several warnings from autotools popped up after upgrade to Fedora 19. >>>>> Attached patches should make autotools configuration more modern. >>>>> >>>>> -- >>>>> Petr^2 Spacek >>>> From 07caec808e394bfcbd898905e917731cb3778e68 Mon Sep 17 00:00:00 2001 >>>>> From: Petr Spacek >>>>> Date: Thu, 4 Jul 2013 14:04:57 +0200 >>>>> Subject: [PATCH] Add missing ar check to configure.ac. >>>>> >>>>> Signed-off-by: Petr Spacek >>>>> --- >>>>> configure.ac | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/configure.ac b/configure.ac >>>>> index >>>> 222e520e0aa61bca58cff81bea672fcab04355b3..b6d66de1b862a6860226a5f9ae4a3f33842e6100 >>>> 100644 >>>>> --- a/configure.ac >>>>> +++ b/configure.ac >>>>> @@ -10,6 +10,7 @@ AC_CONFIG_HEADERS([config.h]) >>>>> AC_DISABLE_STATIC >>>>> >>>>> # Checks for programs. >>>>> +AM_PROG_AR >>>>> AC_PROG_CC >>>>> AC_PROG_LIBTOOL >>>>> >>>>> -- >>>>> 1.8.3.1 >>>>> >>> This solution is not very portable. Automake <= 1.11 does not contain >>> this >>> macro. >>> >>> configure.ac:14: warning: macro `AM_PROG_AR' not found in library >>> configure.ac:14: error: possibly undefined macro: AM_PROG_AR >>> If this token and others are legitimate, please use >>> m4_pattern_allow. >>> See the Autoconf documentation. >>> autoreconf: /usr/bin/autoconf failed with exit status: 1 >>> >>> Better solution will be: >>> m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >>> >>> You can find more information about this in mail thread >>> http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html >> >> Thank you for catching this. Fixed patch is attached. >> > > ACK Pushed to v3: 3bec5eda866bd9b518c2b11db3abc0cc9dcdfa1a 3b8a70f610b2365bbb967fb013e1764c65e188b5 -- Petr^2 Spacek From abokovoy at redhat.com Thu Jul 18 09:10:07 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 12:10:07 +0300 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers In-Reply-To: <20130718075116.GP18587@redhat.com> References: <51E01637.9040102@redhat.com> <51E0219F.8030604@redhat.com> <20130718075116.GP18587@redhat.com> Message-ID: <20130718091007.GS18587@redhat.com> On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >On Fri, 12 Jul 2013, Rob Crittenden wrote: >>Rob Crittenden wrote: >>>Add the Camellia ciphers to the supported list in the KDC. >>> >>>Also exclude some attributes from being displayed in LDAP updater logs. >>> >>>rob >> >>I've split the Camellia patch out from the updater patch to clarify things. >Thanks, pushed to master. .. and to ipa-3-2. I realized this should have been done before 3.2.2 release but anyway, we'll add these two patches to the next Fedora build. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jul 18 08:58:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 10:58:57 +0200 Subject: [Freeipa-devel] [PATCH 0173] Improve logging for cases where SOA serial autoincrementation failed In-Reply-To: <51DFBBCB.7050808@redhat.com> References: <51DE87FB.50308@redhat.com> <51DFBBCB.7050808@redhat.com> Message-ID: <51E7AE51.7020102@redhat.com> On 12.7.2013 10:18, Tomas Hozza wrote: > On 07/11/2013 12:24 PM, Petr Spacek wrote: >> >Hello, >> > >> >Improve logging for cases where SOA serial autoincrementation failed. >> > > ACK Pushed to v3: 9ef4eee3c484557efd7c777458c6800f7c61bdaf -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 18 08:59:43 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 10:59:43 +0200 Subject: [Freeipa-devel] [PATCH 0175-0177] Prepare transition from persistent search to RFC 4533 In-Reply-To: <51E7A276.1030807@redhat.com> References: <51E4FE76.4070408@redhat.com> <51E7A276.1030807@redhat.com> Message-ID: <51E7AE7F.9020100@redhat.com> On 18.7.2013 10:08, Tomas Hozza wrote: > On 07/16/2013 10:04 AM, Petr Spacek wrote: >> >Hello, >> > >> >this patch set changes default configuration to 'psearch yes' and >> >changes README and informational messages accordingly. >> > > ACK. Pushed to v3: b6eb73072b501a646c90e591c3fb7421ab011bd3 103d7a0502fcfd1ef6875c4771d87863471a7313 fd484a2683c1833cb779c9ea0d7382db439c9582 -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 18 08:59:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 10:59:16 +0200 Subject: [Freeipa-devel] [PATCH 0174] Fix crash during zone_refresh triggered by connection failure In-Reply-To: <51E7A21A.6060902@redhat.com> References: <51E3F579.2010908@redhat.com> <51E7A21A.6060902@redhat.com> Message-ID: <51E7AE64.9020208@redhat.com> On 18.7.2013 10:06, Tomas Hozza wrote: > On 07/15/2013 03:13 PM, Petr Spacek wrote: >> >Hello, >> > >> >Fix crash during zone_refresh triggered by connection failure. >> > >> >Variable 'iter' was initialized too late. Code in cleanup section of >> >refresh_zones_from_ldap() dereferenced the uninitialized variable. >> > > ACK. > > The crash is fixed. Pushed to v3: 3affa9c2431928a5b5708875ab937d598059561e -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 18 09:45:08 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 11:45:08 +0200 Subject: [Freeipa-devel] [PATCH 0178-0179] Preparation for 3.5 release In-Reply-To: <51E7A2B5.5060201@redhat.com> References: <51E500C7.6090802@redhat.com> <51E7A2B5.5060201@redhat.com> Message-ID: <51E7B924.30405@redhat.com> On 18.7.2013 10:09, Tomas Hozza wrote: > On 07/16/2013 10:13 AM, Petr Spacek wrote: >> >Hello, >> > >> >I plan to release 3.5 as soon as all previous patches are ACKed. >> > > ACK. Pushed to v3: 1c73120c82ddf52c70b16aabde4cf249ed2ec148 190d13ef0188304c0dc23fc0f182482718ecb580 V3 is stable branch, master branch will diverge from this point. -- Petr^2 Spacek From mkosek at redhat.com Thu Jul 18 09:49:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 11:49:55 +0200 Subject: [Freeipa-devel] [PATCH] 1103 Add Camellia ciphers In-Reply-To: <20130718091007.GS18587@redhat.com> References: <51E01637.9040102@redhat.com> <51E0219F.8030604@redhat.com> <20130718075116.GP18587@redhat.com> <20130718091007.GS18587@redhat.com> Message-ID: <51E7BA43.4040507@redhat.com> On 07/18/2013 11:10 AM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >> On Fri, 12 Jul 2013, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Add the Camellia ciphers to the supported list in the KDC. >>>> >>>> Also exclude some attributes from being displayed in LDAP updater logs. >>>> >>>> rob >>> >>> I've split the Camellia patch out from the updater patch to clarify things. >> Thanks, pushed to master. > .. and to ipa-3-2. I realized this should have been done before 3.2.2 > release but anyway, we'll add these two patches to the next Fedora > build. Yup, let it be in 3.2.3. This is not blocking. Martin From pviktori at redhat.com Thu Jul 18 10:08:20 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 18 Jul 2013 12:08:20 +0200 Subject: [Freeipa-devel] Proposal to have spec changes as a separate patch In-Reply-To: <20130718081045.GR18587@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <20130718081045.GR18587@redhat.com> Message-ID: <51E7BE94.6020902@redhat.com> On 07/18/2013 10:10 AM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket >>> https://fedorahosted.org/freeipa/ticket/3652. >> Could you please rebase it on top of git master? > BTW, I was thinking on it and given that majority of rebases like this > one come due to spec changes, may be we could establishe a practice to > send spec-related changes as a separate patch in a patchset? > > This would allow easily testing the actual code changes since you don't > really need spec changes at that point or could handle it clearer with > pre-installed build dependencies. > > Or you could just set the union merge strategy on the spec file. This is potentially dangerous so only do it if for pushing to master you apply patches in a separate "clean" repository without this setting. Add the following line to .git/info/gitattributes: freeipa.spec.in merge=union Docs & caveats: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers -- Petr? From mkosek at redhat.com Thu Jul 18 10:11:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 12:11:33 +0200 Subject: [Freeipa-devel] [PATCH] Use libunistring ulc_casecmp() on unicode strings In-Reply-To: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> References: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> Message-ID: <51E7BF55.70904@redhat.com> On 07/17/2013 07:13 PM, Nathaniel McCallum wrote: > attached > I did not review/test the actual code, but shouldn't we also add libunistring as BuildRequires in spec file so that it is automatically installed before the build? Martin From pvoborni at redhat.com Thu Jul 18 10:11:35 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 12:11:35 +0200 Subject: [Freeipa-devel] [PATCH] 428 Hide delete button in multivalued widget if attr is not writable Message-ID: <51E7BF57.6060802@redhat.com> Hide delete button in multivalued widget if attr is not writable https://fedorahosted.org/freeipa/ticket/3799 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0428-Hide-delete-button-in-multivalued-widget-if-attr-is-.patch Type: text/x-patch Size: 3510 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 18 10:12:59 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 12:12:59 +0200 Subject: [Freeipa-devel] [PATCH] 429 Make ssh_widget not-editable if attr is readonly Message-ID: <51E7BFAB.2000809@redhat.com> Make ssh_widget not-editable if attr is readonly Depends on patch pvoborni-428. https://fedorahosted.org/freeipa/ticket/3800 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0429-Make-ssh_widget-not-editable-if-attr-is-readonly.patch Type: text/x-patch Size: 2420 bytes Desc: not available URL: From pviktori at redhat.com Thu Jul 18 10:17:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 18 Jul 2013 12:17:07 +0200 Subject: [Freeipa-devel] [PATCHES] 0251-0252 Wait for replication to finish in test_simple_replication Message-ID: <51E7C0A3.4020808@redhat.com> Please apply on top of my patches 0245-0250 (or I can rebase if necessary). These patches are continuing with https://fedorahosted.org/freeipa/ticket/3621, Automated integration testing Before checking if an entry is replicated, we need to wait until replication is complete. One way to do this is polling replication agreements until all updates are complete (or an error occurs). I checked with Rich Megginson that this strategy should work. Patch 0252 implements this. Patch 0251 is a one-liner fixing a default argument of LDAPClient.get_entries. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0251-Correct-default-value-of-LDAPClient.get_entries-scop.patch Type: text/x-patch Size: 956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0252-test_simple_replication-Wait-for-replication-to-fini.patch Type: text/x-patch Size: 6971 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 18 10:27:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 12:27:16 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 3.5 Message-ID: <51E7C304.3020407@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 3.5. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 19 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-3.5-1.fc19 This release *enables persistent search by default*. Other changes include minor fixes and changes in documentation. == Changes in 3.5 == [1] Crash triggered by zone_refresh with broken connection to LDAP was fixed. [2] Code was changed to not trigger false positives in Clang static analyzer. [3] Persistent search is enabled by default. [4] Options cache_ttl, psearch and zone_refresh were formally deprecated. [5] Autotools should work on aarch64 (ARM64). == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 2.x version is supported under following conditions: - new object class idnsForwardZone is not utilized - record types not supported by 2.x versions are not utilized - configured connection count is >= 3 (to prevent deadlocks in 2.x releases) == Important change planned for 4.0 release == Configurations with and without persistent search are now deprecated. Support for 'zone_refresh' and 'psearch' options will be removed in 4.0 release. Bind-dyndb-ldap 4.0 will require LDAP server with support for RFC 4533. 389 DS team is actively working on this feature: https://fedorahosted.org/389/ticket/47388 == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From akrivoka at redhat.com Thu Jul 18 10:28:42 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 18 Jul 2013 12:28:42 +0200 Subject: [Freeipa-devel] [PATCH] 0044 Add 'ipa_server_mode' option to SSSD configuration In-Reply-To: <20130718075747.GQ18587@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> Message-ID: <51E7C35A.4060203@redhat.com> On 07/18/2013 09:57 AM, Alexander Bokovoy wrote: > On Mon, 15 Jul 2013, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. > Could you please rebase it on top of git master? > > Sure, patches are attached. Spec changes have been split to a separate patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0044-02-Add-ipa_server_mode-option-to-SSSD-configuration.patch Type: text/x-patch Size: 2890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0048-Bump-version-of-sssd-in-spec-file.patch Type: text/x-patch Size: 1160 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 18 10:52:55 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Jul 2013 12:52:55 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> Message-ID: <51E7C907.7050604@redhat.com> On 17.7.2013 13:47, Tomas Babej wrote: >> I will release version 3.5 before end of this week. I have some small fixes >> >ready so it is worth to release it now. >> > >> >To summarize the discussion - please remove following options from >> >configuration file and LDAP schema: >> >cache_ttl >> >psearch (attribute idnsPersistentSearch in idnsConfigObject) >> >zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >> > >> >-- >> >Petr^2 Spacek > I have a patch ready, but it can't be tested until 3.5 is out. Bind-dyndb-ldap 3.5 was released. The package is on the way to updates-testing in Fedora 19. -- Petr^2 Spacek From pvoborni at redhat.com Thu Jul 18 10:58:18 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 12:58:18 +0200 Subject: [Freeipa-devel] [PATCH] 430 Break long words in notification area Message-ID: <51E7CA4A.7000408@redhat.com> Long words (ie. service principal) breaks out of notification area. It doesn't look good. Patch adds word-wrap to break them to multiple pieces. Reproduction: modify a service in Web UI -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0430-Break-long-words-in-notification-area.patch Type: text/x-patch Size: 766 bytes Desc: not available URL: From akrivoka at redhat.com Thu Jul 18 11:02:14 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 18 Jul 2013 13:02:14 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E79856.1050702@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> <51E6C07D.3080007@redhat.com> <51E6D7AD.3090906@redhat.com> <51E79856.1050702@redhat.com> Message-ID: <51E7CB36.8050303@redhat.com> On 07/18/2013 09:25 AM, Jan Cholasta wrote: > On 17.7.2013 19:43, Ana Krivokapic wrote: >> On 07/17/2013 06:04 PM, Jan Cholasta wrote: >>> On 17.7.2013 17:39, Ana Krivokapic wrote: >>>> On 07/17/2013 04:57 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 17.7.2013 16:38, Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>>>>> >>>>> >>>>> NACK, this results in an unnecessarily ugly error message "[Errno 2] No such >>>>> file or directory: 'file'". >>>>> >>>>> I would suggest something like this instead: >>>>> >>>>> except IOError as e: >>>>> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) >>>> >>>> Fixed. >>> >>> Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, >>> I think it would make sense to catch the IOError right in import_pem_cert and >>> re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 >>> (sorry for misleading you into doing something else in my previous mail). >> >> I don't see much value in doing that - it just adds complexity. I would rather >> leave it as it is. > > All the other NSSDatabase methods raise RuntimeErrors when something goes > wrong, including I/O errors. IMO having consistent API is preferable to saving > 2 lines of code. > >>> >>>>> >>>>> Can you please also check what happens if you pass non-existent filename to >>>>> --dirsrv_pkcs12 and --http_pkcs12? >>>>> >>>>> Honza >>>>> >>>> >>>> I added a more specific error message to cover these cases. >>> >>> Can you please also add it to find_root_cert_from_pkcs12? >> >> Done, thanks for catching that. >>> >>>> >>>> Updated patch attached. >>>> >>> >>> Honza >>> >> >> Updated patch is attached. >> > > Honza > Ok, fixed. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0046-04-Properly-handle-non-existent-cert-files.patch Type: text/x-patch Size: 2752 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 18 11:25:17 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 13:25:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0251-0252 Wait for replication to finish in test_simple_replication In-Reply-To: <51E7C0A3.4020808@redhat.com> References: <51E7C0A3.4020808@redhat.com> Message-ID: <51E7D09D.6020109@redhat.com> On 18.7.2013 12:17, Petr Viktorin wrote: > Please apply on top of my patches 0245-0250 (or I can rebase if necessary). > > These patches are continuing with > https://fedorahosted.org/freeipa/ticket/3621, Automated integration testing > > Before checking if an entry is replicated, we need to wait until > replication is complete. > One way to do this is polling replication agreements until all updates > are complete (or an error occurs). I checked with Rich Megginson that > this strategy should work. > > Patch 0252 implements this. This fixes test_integration.py for me, ACK. > > Patch 0251 is a one-liner fixing a default argument of > LDAPClient.get_entries. ACK. Honza -- Jan Cholasta From jcholast at redhat.com Thu Jul 18 11:28:19 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 13:28:19 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E7CB36.8050303@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> <51E6C07D.3080007@redhat.com> <51E6D7AD.3090906@redhat.com> <51E79856.1050702@redhat.com> <51E7CB36.8050303@redhat.com> Message-ID: <51E7D153.7000805@redhat.com> On 18.7.2013 13:02, Ana Krivokapic wrote: > On 07/18/2013 09:25 AM, Jan Cholasta wrote: >> On 17.7.2013 19:43, Ana Krivokapic wrote: >>> On 07/17/2013 06:04 PM, Jan Cholasta wrote: >>>> On 17.7.2013 17:39, Ana Krivokapic wrote: >>>>> On 07/17/2013 04:57 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 17.7.2013 16:38, Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>>>>>> >>>>>> >>>>>> NACK, this results in an unnecessarily ugly error message "[Errno 2] No such >>>>>> file or directory: 'file'". >>>>>> >>>>>> I would suggest something like this instead: >>>>>> >>>>>> except IOError as e: >>>>>> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, e.strerror)) >>>>> >>>>> Fixed. >>>> >>>> Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, >>>> I think it would make sense to catch the IOError right in import_pem_cert and >>>> re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 >>>> (sorry for misleading you into doing something else in my previous mail). >>> >>> I don't see much value in doing that - it just adds complexity. I would rather >>> leave it as it is. >> >> All the other NSSDatabase methods raise RuntimeErrors when something goes >> wrong, including I/O errors. IMO having consistent API is preferable to saving >> 2 lines of code. >> >>>> >>>>>> >>>>>> Can you please also check what happens if you pass non-existent filename to >>>>>> --dirsrv_pkcs12 and --http_pkcs12? >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> I added a more specific error message to cover these cases. >>>> >>>> Can you please also add it to find_root_cert_from_pkcs12? >>> >>> Done, thanks for catching that. >>>> >>>>> >>>>> Updated patch attached. >>>>> >>>> >>>> Honza >>>> >>> >>> Updated patch is attached. >>> >> >> Honza >> > > Ok, fixed. > Thanks! ACK. Honza -- Jan Cholasta From pvoborni at redhat.com Thu Jul 18 11:34:05 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 13:34:05 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation Message-ID: <51E7D2AD.7020600@redhat.com> [PATCH] 431 Web UI integration tests: Add trust tests [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions [PATCH] 433 Web UI integration tests: Verify data after add and mod [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps Heavily inspired by code from xmlrpc tests. To obtain ranges, this patch also adds method to execute FreeIPA command through Web UI. It uses Web UI instead of ipalib so it doesn't need to care about authentication on a test-runner machine. All: https://fedorahosted.org/freeipa/ticket/3744 -- Petr Vobornik From pvoborni at redhat.com Thu Jul 18 11:35:10 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Jul 2013 13:35:10 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51E7D2AD.7020600@redhat.com> References: <51E7D2AD.7020600@redhat.com> Message-ID: <51E7D2EE.4050501@redhat.com> On 07/18/2013 01:34 PM, Petr Vobornik wrote: > [PATCH] 431 Web UI integration tests: Add trust tests > > [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions > > [PATCH] 433 Web UI integration tests: Verify data after add and mod > > [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps > > Heavily inspired by code from xmlrpc tests. > > To obtain ranges, this patch also adds method to execute FreeIPA command > through Web UI. > It uses Web UI instead of ipalib so it doesn't need to care about > authentication on a test-runner machine. > > All: https://fedorahosted.org/freeipa/ticket/3744 And now the patches... -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0431-Web-UI-integration-tests-Add-trust-tests.patch Type: text/x-patch Size: 7886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0432-Web-UI-integration-tests-Add-ui_driver-method-descri.patch Type: text/x-patch Size: 10509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0433-Web-UI-integration-tests-Verify-data-after-add-and-m.patch Type: text/x-patch Size: 7233 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0434-Web-UI-integration-tests-Compute-range-sizes-to-avoi.patch Type: text/x-patch Size: 4690 bytes Desc: not available URL: From mkosek at redhat.com Thu Jul 18 11:38:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 13:38:08 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Properly handle non-existent CA file In-Reply-To: <51E7D153.7000805@redhat.com> References: <51E6AC65.1030601@redhat.com> <51E6B0D8.1000502@redhat.com> <51E6BACE.6030304@redhat.com> <51E6C07D.3080007@redhat.com> <51E6D7AD.3090906@redhat.com> <51E79856.1050702@redhat.com> <51E7CB36.8050303@redhat.com> <51E7D153.7000805@redhat.com> Message-ID: <51E7D3A0.2070509@redhat.com> On 07/18/2013 01:28 PM, Jan Cholasta wrote: > On 18.7.2013 13:02, Ana Krivokapic wrote: >> On 07/18/2013 09:25 AM, Jan Cholasta wrote: >>> On 17.7.2013 19:43, Ana Krivokapic wrote: >>>> On 07/17/2013 06:04 PM, Jan Cholasta wrote: >>>>> On 17.7.2013 17:39, Ana Krivokapic wrote: >>>>>> On 07/17/2013 04:57 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 17.7.2013 16:38, Ana Krivokapic wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3785. >>>>>>>> >>>>>>> >>>>>>> NACK, this results in an unnecessarily ugly error message "[Errno 2] No >>>>>>> such >>>>>>> file or directory: 'file'". >>>>>>> >>>>>>> I would suggest something like this instead: >>>>>>> >>>>>>> except IOError as e: >>>>>>> raise ScriptError("Failed to open %s: %s" % (ca_cert_name, >>>>>>> e.strerror)) >>>>>> >>>>>> Fixed. >>>>> >>>>> Hmm, seeing how RuntimeError is used for this kind of thing in import_pkcs12, >>>>> I think it would make sense to catch the IOError right in import_pem_cert and >>>>> re-raise it as RuntimeError and then handle that RuntimeError in check_pkcs12 >>>>> (sorry for misleading you into doing something else in my previous mail). >>>> >>>> I don't see much value in doing that - it just adds complexity. I would rather >>>> leave it as it is. >>> >>> All the other NSSDatabase methods raise RuntimeErrors when something goes >>> wrong, including I/O errors. IMO having consistent API is preferable to saving >>> 2 lines of code. >>> >>>>> >>>>>>> >>>>>>> Can you please also check what happens if you pass non-existent filename to >>>>>>> --dirsrv_pkcs12 and --http_pkcs12? >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> I added a more specific error message to cover these cases. >>>>> >>>>> Can you please also add it to find_root_cert_from_pkcs12? >>>> >>>> Done, thanks for catching that. >>>>> >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> Updated patch is attached. >>>> >>> >>> Honza >>> >> >> Ok, fixed. >> > > Thanks! ACK. > > Honza > Pushed to mater, ipa-3-2. Martin From abokovoy at redhat.com Thu Jul 18 12:01:11 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 15:01:11 +0300 Subject: [Freeipa-devel] Proposal to have spec changes as a separate patch In-Reply-To: <51E7BE94.6020902@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <20130718081045.GR18587@redhat.com> <51E7BE94.6020902@redhat.com> Message-ID: <20130718120111.GT18587@redhat.com> On Thu, 18 Jul 2013, Petr Viktorin wrote: >On 07/18/2013 10:10 AM, Alexander Bokovoy wrote: >>On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >>>On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>>>Hello, >>>> >>>>This patch addresses ticket >>>>https://fedorahosted.org/freeipa/ticket/3652. >>>Could you please rebase it on top of git master? >>BTW, I was thinking on it and given that majority of rebases like this >>one come due to spec changes, may be we could establishe a practice to >>send spec-related changes as a separate patch in a patchset? >> >>This would allow easily testing the actual code changes since you don't >>really need spec changes at that point or could handle it clearer with >>pre-installed build dependencies. >> >> > >Or you could just set the union merge strategy on the spec file. >This is potentially dangerous so only do it if for pushing to master >you apply patches in a separate "clean" repository without this >setting. > >Add the following line to .git/info/gitattributes: >freeipa.spec.in merge=union > >Docs & caveats: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers I would still prefer to have the changes in separate patches in a patchset simply because it makes clearer and easier to handle in active development. When we push commits to the main git tree, we anyway push whole patchset as one push operation. As result, anyone who pulls that tree, will get consistent patchset -- be it another developer or continuous integration machinery. For developers who touch spec files reduced context of the changes in a pulled tree will also be helpful. Besides that, you anyway will need to do manual adoption after merge=union in order to get changelog entries in proper chronological order and release numbering. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jul 18 12:24:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 14:24:45 +0200 Subject: [Freeipa-devel] Proposal to have spec changes as a separate patch In-Reply-To: <20130718120111.GT18587@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <20130718081045.GR18587@redhat.com> <51E7BE94.6020902@redhat.com> <20130718120111.GT18587@redhat.com> Message-ID: <51E7DE8D.2020402@redhat.com> On 07/18/2013 02:01 PM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Petr Viktorin wrote: >> On 07/18/2013 10:10 AM, Alexander Bokovoy wrote: >>> On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >>>> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket >>>>> https://fedorahosted.org/freeipa/ticket/3652. >>>> Could you please rebase it on top of git master? >>> BTW, I was thinking on it and given that majority of rebases like this >>> one come due to spec changes, may be we could establishe a practice to >>> send spec-related changes as a separate patch in a patchset? >>> >>> This would allow easily testing the actual code changes since you don't >>> really need spec changes at that point or could handle it clearer with >>> pre-installed build dependencies. >>> >>> >> >> Or you could just set the union merge strategy on the spec file. >> This is potentially dangerous so only do it if for pushing to master you >> apply patches in a separate "clean" repository without this setting. >> >> Add the following line to .git/info/gitattributes: >> freeipa.spec.in merge=union >> >> Docs & caveats: >> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers >> > I would still prefer to have the changes in separate patches in a > patchset simply because it makes clearer and easier to handle in active > development. Hmm, I am personally not convinced - when I just update one Requires, splitting it to 2 patches seems as an overkill to me... > > When we push commits to the main git tree, we anyway push whole patchset > as one push operation. As result, anyone who pulls that tree, will get > consistent patchset -- be it another developer or continuous integration > machinery. For developers who touch spec files reduced context of the > changes in a pulled tree will also be helpful. > > Besides that, you anyway will need to do manual adoption after > merge=union in order to get changelog entries in proper chronological > order and release numbering. I am still not sure about the gain of this - unless people provide special patch with comment for all affected branches, I will have to merge the doc change manually (+ give higher maintenance effort by splitting the patches again). To sum it up, I would not personally make this a strict rule unless we find that current patches with spec comment included are unbearable (so far, they were not unbearable for me...). Martin From npmccallum at redhat.com Thu Jul 18 14:22:50 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Jul 2013 10:22:50 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] Use libunistring ulc_casecmp() on unicode strings In-Reply-To: <51E7BF55.70904@redhat.com> References: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> <51E7BF55.70904@redhat.com> Message-ID: <1233670647.2645096.1374157370088.JavaMail.root@redhat.com> ----- Original Message ----- > I did not review/test the actual code, but shouldn't we also add libunistring > as BuildRequires in spec file so that it is automatically installed before > the build? Good catch. Fixed version attached. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0012-2-Use-libunistring-ulc_casecmp-on-unicode-strings.patch Type: text/x-patch Size: 6690 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 18 14:53:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 16:53:42 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E4138A.5060508@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> Message-ID: <51E80176.9050804@redhat.com> On 15.7.2013 17:21, Martin Kosek wrote: > On 07/15/2013 03:43 PM, Jan Cholasta wrote: >> On 15.7.2013 15:16, Martin Kosek wrote: >>> On 07/11/2013 12:15 PM, Alexander Bokovoy wrote: >>>> On Thu, 11 Jul 2013, Jan Cholasta wrote: >>>>> We can add WebUI improvements later. I have some WIP, but I need to discuss >>>>> it with Petr first (he's away this week). >>>> Ok. >>>> >>>> The patchset is in ipa-3-2 as well now. >>> >>> Just checking: >>> >>> 1) Jan, did you check size of these new indexes on IPA master with such a high >>> number of users? How big are they? I want to make sure that this won't create >>> an issue on upgrades to new 3.2.x. >> >> With 10k users, the indices ate roughly 250 MB of disk space. Scratch that, my measurement method was stupid. It is just 2 MB of extra space. >> >>> >>> 2) Does the patch set also fix the problem for Web UI? Currently, I think it >>> will still grab and process all member attributes even though it does not need >>> it. If the Web UI performance is still not sharp, I would rather leave this >>> ticket opened and let Jan&Petr cooperate on the Web UI part. >> >> I agree on keeping the ticket open. >> >> Honza >> > > Ok, I reopened the ticket. Petr and Jan, please cooperate on this one. > > Martin > Added patch which adds new hidden option no_members to suppress membership processing for commands of all objects that have member attributes. This can be used by the WebUI to prevent member lookups where they are not necessary (as we discussed off-line with Martin and Petr). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-160-Add-new-hidden-command-option-to-suppress-processing.patch Type: text/x-patch Size: 116801 bytes Desc: not available URL: From mkosek at redhat.com Thu Jul 18 15:07:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 17:07:45 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E80176.9050804@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> Message-ID: <51E804C1.2090804@redhat.com> On 07/18/2013 04:53 PM, Jan Cholasta wrote: > On 15.7.2013 17:21, Martin Kosek wrote: >> On 07/15/2013 03:43 PM, Jan Cholasta wrote: >>> On 15.7.2013 15:16, Martin Kosek wrote: >>>> On 07/11/2013 12:15 PM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Jul 2013, Jan Cholasta wrote: >>>>>> We can add WebUI improvements later. I have some WIP, but I need to discuss >>>>>> it with Petr first (he's away this week). >>>>> Ok. >>>>> >>>>> The patchset is in ipa-3-2 as well now. >>>> >>>> Just checking: >>>> >>>> 1) Jan, did you check size of these new indexes on IPA master with such a high >>>> number of users? How big are they? I want to make sure that this won't create >>>> an issue on upgrades to new 3.2.x. >>> >>> With 10k users, the indices ate roughly 250 MB of disk space. > > Scratch that, my measurement method was stupid. It is just 2 MB of extra space. > >>> >>>> >>>> 2) Does the patch set also fix the problem for Web UI? Currently, I think it >>>> will still grab and process all member attributes even though it does not need >>>> it. If the Web UI performance is still not sharp, I would rather leave this >>>> ticket opened and let Jan&Petr cooperate on the Web UI part. >>> >>> I agree on keeping the ticket open. >>> >>> Honza >>> >> >> Ok, I reopened the ticket. Petr and Jan, please cooperate on this one. >> >> Martin >> > > Added patch which adds new hidden option no_members to suppress membership > processing for commands of all objects that have member attributes. This can be > used by the WebUI to prevent member lookups where they are not necessary (as we > discussed off-line with Martin and Petr). > > Honza > 1) Should the new option really have "exclude='webui'? I thought that Web UI is the main and only consumer of this option. 2) I would clearly state this is an internal option only, e.g. + doc=_('INTERNAL: suppress processing of membership attributes.'), 3) It would be nice to state that this option is mutually exclusive with --all, but given it is internal anyway and there is no central place to define it, we do not need to do that. Martin From jcholast at redhat.com Thu Jul 18 15:22:11 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 17:22:11 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E804C1.2090804@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> Message-ID: <51E80823.6020605@redhat.com> On 18.7.2013 17:07, Martin Kosek wrote: > On 07/18/2013 04:53 PM, Jan Cholasta wrote: >> Added patch which adds new hidden option no_members to suppress membership >> processing for commands of all objects that have member attributes. This can be >> used by the WebUI to prevent member lookups where they are not necessary (as we >> discussed off-line with Martin and Petr). >> >> Honza >> > > 1) Should the new option really have "exclude='webui'? I thought that Web UI is > the main and only consumer of this option. The 'webui' context doesn't actually exist and the only meaning of this stanza is that the option is not shown in the output of the show_mappings command. > > 2) I would clearly state this is an internal option only, e.g. > > + doc=_('INTERNAL: suppress processing of membership attributes.'), No other internal option has this kind of thing in its doc and nobody will see it anyway, so we might just leave it like that IMHO. > > 3) It would be nice to state that this option is mutually exclusive with --all, > but given it is internal anyway and there is no central place to define it, we > do not need to do that. The options are not really mutually exclusive at this point, they can be specified together, --all takes precedence. Honza -- Jan Cholasta From mkosek at redhat.com Thu Jul 18 15:26:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 17:26:20 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E80823.6020605@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> Message-ID: <51E8091C.90109@redhat.com> On 07/18/2013 05:22 PM, Jan Cholasta wrote: > On 18.7.2013 17:07, Martin Kosek wrote: >> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>> Added patch which adds new hidden option no_members to suppress membership >>> processing for commands of all objects that have member attributes. This can be >>> used by the WebUI to prevent member lookups where they are not necessary (as we >>> discussed off-line with Martin and Petr). >>> >>> Honza >>> >> >> 1) Should the new option really have "exclude='webui'? I thought that Web UI is >> the main and only consumer of this option. > > The 'webui' context doesn't actually exist and the only meaning of this stanza > is that the option is not shown in the output of the show_mappings command. > >> >> 2) I would clearly state this is an internal option only, e.g. >> >> + doc=_('INTERNAL: suppress processing of membership attributes.'), > > No other internal option has this kind of thing in its doc and nobody will see > it anyway, so we might just leave it like that IMHO. OK. > >> >> 3) It would be nice to state that this option is mutually exclusive with --all, >> but given it is internal anyway and there is no central place to define it, we >> do not need to do that. > > The options are not really mutually exclusive at this point, they can be > specified together, --all takes precedence. Well, they can be specified together, but the option is then NOOP which could confuse users which may have different expectations. Being explicit helps. But as I said, in this case this is not a requirement. Martin From jcholast at redhat.com Thu Jul 18 15:29:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Jul 2013 17:29:42 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E8091C.90109@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> Message-ID: <51E809E6.4040103@redhat.com> On 18.7.2013 17:26, Martin Kosek wrote: > On 07/18/2013 05:22 PM, Jan Cholasta wrote: >> On 18.7.2013 17:07, Martin Kosek wrote: >>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>> Added patch which adds new hidden option no_members to suppress membership >>>> processing for commands of all objects that have member attributes. This can be >>>> used by the WebUI to prevent member lookups where they are not necessary (as we >>>> discussed off-line with Martin and Petr). >>>> >>>> Honza >>>> >>> >>> 1) Should the new option really have "exclude='webui'? I thought that Web UI is >>> the main and only consumer of this option. >> >> The 'webui' context doesn't actually exist and the only meaning of this stanza >> is that the option is not shown in the output of the show_mappings command. >> >>> >>> 2) I would clearly state this is an internal option only, e.g. >>> >>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >> >> No other internal option has this kind of thing in its doc and nobody will see >> it anyway, so we might just leave it like that IMHO. > > OK. > >> >>> >>> 3) It would be nice to state that this option is mutually exclusive with --all, >>> but given it is internal anyway and there is no central place to define it, we >>> do not need to do that. >> >> The options are not really mutually exclusive at this point, they can be >> specified together, --all takes precedence. > > Well, they can be specified together, but the option is then NOOP which could > confuse users which may have different expectations. Being explicit helps. I agree. > But > as I said, in this case this is not a requirement. I agree as well :-) Honza -- Jan Cholasta From abokovoy at redhat.com Thu Jul 18 15:30:46 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 18:30:46 +0300 Subject: [Freeipa-devel] [PATCH] Use libunistring ulc_casecmp() on unicode strings In-Reply-To: <1233670647.2645096.1374157370088.JavaMail.root@redhat.com> References: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> <51E7BF55.70904@redhat.com> <1233670647.2645096.1374157370088.JavaMail.root@redhat.com> Message-ID: <20130718153046.GV18587@redhat.com> On Thu, 18 Jul 2013, Nathaniel McCallum wrote: >----- Original Message ----- >> I did not review/test the actual code, but shouldn't we also add libunistring >> as BuildRequires in spec file so that it is automatically installed before >> the build? > >Good catch. Fixed version attached. ACK. Works fine. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 18 15:32:08 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 18:32:08 +0300 Subject: [Freeipa-devel] [PATCH] 0044 Add 'ipa_server_mode' option to SSSD configuration In-Reply-To: <51E7C35A.4060203@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <51E7C35A.4060203@redhat.com> Message-ID: <20130718153208.GW18587@redhat.com> On Thu, 18 Jul 2013, Ana Krivokapic wrote: >On 07/18/2013 09:57 AM, Alexander Bokovoy wrote: >> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. >> Could you please rebase it on top of git master? >> >> > >Sure, patches are attached. Spec changes have been split to a separate patch. ACK. Works fine. Note to others: with this patch going in master, master will require using SSSD 1.11 (available from ipa-devel repository). -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 18 15:37:33 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 18:37:33 +0300 Subject: [Freeipa-devel] [PATCH] 0109-0110 Support querying AD DC when establishing trust as HTTP/ipa.server principal Message-ID: <20130718153733.GX18587@redhat.com> Hi! Attached patches make possible to use HTTP/ipa.server at REALM to query AD DC over LDAP immediately after trust is established. We need this to get range discovery working prior to creating range for trusted domain. The patch 0109 makes KDC hostname cached on ipadb context to avoid resolving own hostname multiple times. The patch 0110 depends on ulc_casemap patches by Nathaniel and makes exception for HTTP/ipa.server at REALM when TGT is requested and MS-PAC is asked for -- we force refreshing list of trusted domains here. More details are available in the commit logs. -- / Alexander Bokovoy -------------- next part -------------- >From c6c2991ddf939d1e4245564b666d9b04a8c7be12 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 18 Jul 2013 17:10:01 +0300 Subject: [PATCH 6/7] ipa-kdb: cache KDC hostname on startup We need KDC hostname for several purposes: - short-circuit detection of principals on the same server as KDC - generating NetBIOS name Make sure we cache hostname information on startup and use it instead of detecting the hostname in run-time. This will miss the case that KDC hostname got changed but such cases are not supported anyway without restarting KDC and making changes to principals. --- daemons/ipa-kdb/ipa_kdb.c | 15 +++++++++++++++ daemons/ipa-kdb/ipa_kdb.h | 1 + daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++------ 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 8464264..51b879c 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -21,6 +21,7 @@ */ #include +#include #include "ipa_kdb.h" @@ -46,6 +47,7 @@ static void ipadb_context_free(krb5_context kcontext, free((*ctx)->uri); free((*ctx)->base); free((*ctx)->realm_base); + free((*ctx)->kdc_hostname); /* ldap free lcontext */ if ((*ctx)->lcontext) { ldap_unbind_ext_s((*ctx)->lcontext, NULL, NULL); @@ -442,6 +444,7 @@ static krb5_error_code ipadb_init_module(krb5_context kcontext, krb5_error_code kerr; int ret; int i; + struct utsname uname_data; /* make sure the context is freed to avoid leaking it */ ipactx = ipadb_get_context(kcontext); @@ -494,6 +497,18 @@ static krb5_error_code ipadb_init_module(krb5_context kcontext, goto fail; } + ret = uname(&uname_data); + if (ret) { + ret = EINVAL; + goto fail; + } + + ipactx->kdc_hostname = strdup(uname_data.nodename); + if (!ipactx->kdc_hostname) { + ret = ENOMEM; + goto fail; + } + ret = ipadb_get_connection(ipactx); if (ret != 0) { /* not a fatal failure, as the LDAP server may be temporarily down */ diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f7797c4..a611bc2 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -92,6 +92,7 @@ struct ipadb_context { char *base; char *realm; char *realm_base; + char *kdc_hostname; LDAP *lcontext; krb5_context kcontext; bool override_restrictions; diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 96eac6f..d6c4f9a 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1905,16 +1905,13 @@ done: return kerr; } -static char *get_server_netbios_name(void) +static char *get_server_netbios_name(struct ipadb_context *ipactx) { char hostname[MAXHOSTNAMELEN + 1]; /* NOTE: this is 64, too little ? */ char *p; int ret; - ret = gethostname(hostname, MAXHOSTNAMELEN); - if (ret) { - return NULL; - } + strncpy(hostname, ipactx->kdc_hostname, MAXHOSTNAMELEN); /* May miss termination */ hostname[MAXHOSTNAMELEN] = '\0'; for (p = hostname; *p; p++) { @@ -2245,7 +2242,7 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) free(resstr); free(ipactx->mspac->flat_server_name); - ipactx->mspac->flat_server_name = get_server_netbios_name(); + ipactx->mspac->flat_server_name = get_server_netbios_name(ipactx); if (!ipactx->mspac->flat_server_name) { kerr = ENOMEM; goto done; -- 1.8.3.1 -------------- next part -------------- >From 7c452bb3501bf7d5e3fce774d4edce8b2b46579d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 18 Jul 2013 13:32:42 +0300 Subject: [PATCH 7/7] ipa-kdb: reinit mspac on HTTP TGT acquisition to aid trust-add case When trust is established, we also create idrange for the trusted domain. With FreeIPA 3.3 these ranges can have different types, and in order to detect which one is to create, we need to do lookup at AD LDAP server. Such lookup requires authenticated bind. We cannot bind as user because IPA framework operates under constrained delegation using the user's credentials and allowing HTTP/ipa.server at REALM to impersonate the user against trusted domain's services would require two major things: - first, as we don't really know exact AD LDAP server names (any AD DC can be used), constrained delegation would have to be defined against a wild-card - second, constrained delegation requires that target principal exists in IPA LDAP as DN. These two together limit use of user's ticket for the purpose of IPA framework looking up AD LDAP. Additionally, immediately after trust is established, issuing TGT with MS-PAC to HTTP/ipa.server at REALM may fail due to the fact that KDB driver did not yet refreshed its list of trusted domains -- we have limited refresh rate of 60 seconds by default. This patch makes possible to force re-initialization of trusted domains' view in KDB driver if we are asked for TGT for HTTP/ipa.server at REALM. We will need to improve refresh of trusted domains' view in KDB driver in future to notice changes in cn=etc,$SUFFIX tree automatically. This improvement is tracked in https://fedorahosted.org/freeipa/ticket/1302 and https://fedorahosted.org/freeipa/ticket/3626 Part of https://fedorahosted.org/freeipa/ticket/3649 --- daemons/ipa-kdb/ipa_kdb.c | 4 ++-- daemons/ipa-kdb/ipa_kdb.h | 2 +- daemons/ipa-kdb/ipa_kdb_mspac.c | 29 ++++++++++++++++++++++++++--- 3 files changed, 29 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 51b879c..cfdafce 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -393,8 +393,8 @@ int ipadb_get_connection(struct ipadb_context *ipactx) goto done; } - /* get adtrust options */ - ret = ipadb_reinit_mspac(ipactx); + /* get adtrust options using default refresh interval */ + ret = ipadb_reinit_mspac(ipactx, -1); if (ret && ret != ENOENT) { /* TODO: log that there is an issue with adtrust settings */ } diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index a611bc2..a117937 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -250,7 +250,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_authdata **tgt_auth_data, krb5_authdata ***signed_auth_data); -krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx); +krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, int interval); void ipadb_mspac_struct_free(struct ipadb_mspac **mspac); diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index d6c4f9a..4ddf3e8 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -24,6 +24,7 @@ #include "ipa_mspac.h" #include #include +#include #include "util/time.h" #include "gen_ndr/ndr_krb5pac.h" @@ -1282,7 +1283,8 @@ static struct ipadb_adtrusts *get_domain_from_realm_update(krb5_context context, return NULL; } - kerr = ipadb_reinit_mspac(ipactx); + /* re-init MS-PAC info using default update interval */ + kerr = ipadb_reinit_mspac(ipactx, -1); if (kerr != 0) { return NULL; } @@ -1805,8 +1807,10 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; + struct ipadb_context *ipactx; bool with_pac; bool with_pad; + int result; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1831,6 +1835,22 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { + /* Be aggressive here: special case for discovering range type + * immediately after establishing the trust by IPA framework */ + if ((krb5_princ_size(context, ks_client_princ) == 2) && + (strncmp(krb5_princ_component(context, ks_client_princ, 0)->data, "HTTP", + krb5_princ_component(context, ks_client_princ, 0)->length) == 0)) { + ipactx = ipadb_get_context(context); + if (!ipactx) { + goto done; + } + if (ulc_casecmp(krb5_princ_component(context, ks_client_princ, 1)->data, + krb5_princ_component(context, ks_client_princ, 1)->length, + ipactx->kdc_hostname, strlen(ipactx->kdc_hostname), + NULL, NULL, &result) == 0) { + kerr = ipadb_reinit_mspac(ipactx, 1); + } + } kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { @@ -2155,7 +2175,7 @@ done: return ret; } -krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) +krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, int interval) { char *dom_attrs[] = { "ipaNTFlatName", "ipaNTFallbackPrimaryGroup", @@ -2174,8 +2194,11 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) * avoid heavy load on the directory server if there are lots of requests * from domains which we do not trust. */ now = time(NULL); + if (interval <= 0) { + interval = 60; + } if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && - (now - ipactx->mspac->last_update) < 60) { + (now - ipactx->mspac->last_update) < interval) { return 0; } -- 1.8.3.1 From abokovoy at redhat.com Thu Jul 18 15:45:03 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 18 Jul 2013 18:45:03 +0300 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users In-Reply-To: <20130716151953.GB22079@hendrix.brq.redhat.com> References: <20130715171452.GE18587@redhat.com> <20130716125447.GJ9163@hendrix.brq.redhat.com> <20130716132201.GK18587@redhat.com> <20130716151953.GB22079@hendrix.brq.redhat.com> Message-ID: <20130718154503.GY18587@redhat.com> On Tue, 16 Jul 2013, Jakub Hrozek wrote: >> >>+ if self.enable_compat: >> >>+ self.step("Enabling trusted domains support for older clients via Schema Compatibility plugin", >> > >> > ^^^^ >> > Nitpick: all the other steps begin with lowercased >> > letter. Only this one is uppercased, which makes the >> > tool output looks inconsistent: >> >[15/21]: adding special DNS service records >> >[16/21]: Enabling trusted domains support for older clients via Schema Compatibility plugin >> >[17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes into account >> Thanks. Lowcased it. >> >> Updated patch is attached. > >Maybe it would be nice if some native English speaker read the man page >change as well. To me it sounds like there are some articles missing. But >the code works correctly and sets up the SSSD compat attributes during >install when told to. > >Ack from me, however. Thanks. When this patch will be pushed to master, you will need slapi-nis built with my patch in order to actually provide older clients with trusted domains' users. The patch to slapi-nis uncovers dead-lock issue in slapi-nis because its operation means SSSD will be contacted as part of serving LDAP query over compat tree. SSSD then will want to obtain a TGT using host/ipa.server principal to be able to contact AD DC. Our KDC driver will modify host entry in the main LDAP tree which will cause post-op callback triggered in slapi-nis. At this point the callback will encounter that global slapi-nis write lock is already taken by the original query and will dead-lock. However, IPA patch can be applied safely because it only configures slapi-nis trees to serve trusted domains' users over compat tree and if there is no code in slapi-nis to do so, no dead-lock will be triggered. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jul 18 15:50:24 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 17:50:24 +0200 Subject: [Freeipa-devel] [PATCH] 0044 Add 'ipa_server_mode' option to SSSD configuration In-Reply-To: <20130718153208.GW18587@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <51E7C35A.4060203@redhat.com> <20130718153208.GW18587@redhat.com> Message-ID: <51E80EC0.5050309@redhat.com> On 07/18/2013 05:32 PM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Ana Krivokapic wrote: >> On 07/18/2013 09:57 AM, Alexander Bokovoy wrote: >>> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3652. >>> Could you please rebase it on top of git master? >>> >>> >> >> Sure, patches are attached. Spec changes have been split to a separate patch. > ACK. Works fine. > > Note to others: with this patch going in master, master will require > using SSSD 1.11 (available from ipa-devel repository). > Pushed to master. Martin From purpleidea at gmail.com Thu Jul 18 15:50:33 2013 From: purpleidea at gmail.com (James) Date: Thu, 18 Jul 2013 11:50:33 -0400 Subject: [Freeipa-devel] [PATCH] 428 Hide delete button in multivalued widget if attr is not writable In-Reply-To: <51E7BF57.6060802@redhat.com> References: <51E7BF57.6060802@redhat.com> Message-ID: <1374162633.6496.1.camel@freed.mh.shawcable.net> On Thu, 2013-07-18 at 12:11 +0200, Petr Vobornik wrote: > Hide delete button in multivalued widget if attr is not writable Hey, Maybe it would be a good idea to set the disabled state of the button instead of removing it? That way it's obvious that some attrs can be deleted, and it won't cause users to "search" for a button that doesn't exist... Cheers, James > > https://fedorahosted.org/freeipa/ticket/3799 > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mkosek at redhat.com Thu Jul 18 15:57:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 17:57:47 +0200 Subject: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users In-Reply-To: <20130718154503.GY18587@redhat.com> References: <20130715171452.GE18587@redhat.com> <20130716125447.GJ9163@hendrix.brq.redhat.com> <20130716132201.GK18587@redhat.com> <20130716151953.GB22079@hendrix.brq.redhat.com> <20130718154503.GY18587@redhat.com> Message-ID: <51E8107B.4040900@redhat.com> On 07/18/2013 05:45 PM, Alexander Bokovoy wrote: > On Tue, 16 Jul 2013, Jakub Hrozek wrote: >>> >>+ if self.enable_compat: >>> >>+ self.step("Enabling trusted domains support for older clients >>> via Schema Compatibility plugin", >>> > >>> > ^^^^ >>> > Nitpick: all the other steps begin with lowercased >>> > letter. Only this one is uppercased, which makes the >>> > tool output looks inconsistent: >>> >[15/21]: adding special DNS service records >>> >[16/21]: Enabling trusted domains support for older clients via Schema >>> Compatibility plugin >>> >[17/21]: restarting Directory Server to take MS PAC and LDAP plugins >>> changes into account >>> Thanks. Lowcased it. >>> >>> Updated patch is attached. >> >> Maybe it would be nice if some native English speaker read the man page >> change as well. To me it sounds like there are some articles missing. But >> the code works correctly and sets up the SSSD compat attributes during >> install when told to. >> >> Ack from me, however. > Thanks. > > When this patch will be pushed to master, you will need slapi-nis built > with my patch in order to actually provide older clients with trusted > domains' users. > > The patch to slapi-nis uncovers dead-lock issue in slapi-nis because its > operation means SSSD will be contacted as part of serving LDAP query > over compat tree. SSSD then will want to obtain a TGT using > host/ipa.server principal to be able to contact AD DC. Our KDC driver will > modify host entry in the main LDAP tree which will cause post-op > callback triggered in slapi-nis. At this point the callback will > encounter that global slapi-nis write lock is already taken by the > original query and will dead-lock. > > However, IPA patch can be applied safely because it only configures > slapi-nis trees to serve trusted domains' users over compat tree and if > there is no code in slapi-nis to do so, no dead-lock will be triggered. Pushed to master. I left the ticket open as tracker until we also fix the slapi-nis part. Martin From mkosek at redhat.com Thu Jul 18 16:09:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Jul 2013 18:09:33 +0200 Subject: [Freeipa-devel] [PATCH] Use libunistring ulc_casecmp() on unicode strings In-Reply-To: <20130718153046.GV18587@redhat.com> References: <1519431852.2148399.1374081207500.JavaMail.root@redhat.com> <51E7BF55.70904@redhat.com> <1233670647.2645096.1374157370088.JavaMail.root@redhat.com> <20130718153046.GV18587@redhat.com> Message-ID: <51E8133D.6010602@redhat.com> On 07/18/2013 05:30 PM, Alexander Bokovoy wrote: > On Thu, 18 Jul 2013, Nathaniel McCallum wrote: >> ----- Original Message ----- >>> I did not review/test the actual code, but shouldn't we also add libunistring >>> as BuildRequires in spec file so that it is automatically installed before >>> the build? >> >> Good catch. Fixed version attached. > ACK. Works fine. Pushed to master. Martin From akrivoka at redhat.com Thu Jul 18 17:56:01 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 18 Jul 2013 19:56:01 +0200 Subject: [Freeipa-devel] [PATCH] 0049 Use admin@REALM when testing if SSSD is ready Message-ID: <51E82C31.1000009@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3771. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0049-Use-admin-REALM-when-testing-if-SSSD-is-ready.patch Type: text/x-patch Size: 2863 bytes Desc: not available URL: From pviktori at redhat.com Fri Jul 19 08:46:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Jul 2013 10:46:13 +0200 Subject: [Freeipa-devel] [PATCH] 0253 ipa-client: Use "ipa" as the package name for i18n Message-ID: <51E8FCD5.8040201@redhat.com> IPA uses "ipa" as the "package name" for all translations, even in the ipa-client package. https://fedorahosted.org/freeipa/ticket/3695 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0253-ipa-client-Use-ipa-as-the-package-name-for-i18n.patch Type: text/x-patch Size: 1048 bytes Desc: not available URL: From jpazdziora at redhat.com Fri Jul 19 09:30:00 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 19 Jul 2013 11:30:00 +0200 Subject: [Freeipa-devel] [PATCH] 0253 ipa-client: Use "ipa" as the package name for i18n In-Reply-To: <51E8FCD5.8040201@redhat.com> References: <51E8FCD5.8040201@redhat.com> Message-ID: <20130719093000.GE1972@redhat.com> On Fri, Jul 19, 2013 at 10:46:13AM +0200, Petr Viktorin wrote: > > IPA uses "ipa" as the "package name" for all translations, > even in the ipa-client package. > > https://fedorahosted.org/freeipa/ticket/3695 > --- > ipa-client/ipa-client-common.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/ipa-client/ipa-client-common.c b/ipa-client/ipa-client-common.c > index 68861c654e2254c4aceccd5497e8eda3f2c593de..23f384a6e0855582de8a83b84f40c40dd3b6c148 100644 > --- a/ipa-client/ipa-client-common.c > +++ b/ipa-client/ipa-client-common.c > @@ -33,13 +33,13 @@ int init_gettext(void) > } > > errno = 0; > - c = bindtextdomain(PACKAGE, LOCALEDIR); > + c = bindtextdomain("ipa", LOCALEDIR); > if (c == NULL) { > return errno; > } > > errno = 0; > - c = textdomain(PACKAGE); > + c = textdomain("ipa"); Ack. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Fri Jul 19 10:27:26 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Jul 2013 12:27:26 +0200 Subject: [Freeipa-devel] [PATCH] 0253 ipa-client: Use "ipa" as the package name for i18n In-Reply-To: <20130719093000.GE1972@redhat.com> References: <51E8FCD5.8040201@redhat.com> <20130719093000.GE1972@redhat.com> Message-ID: <51E9148E.7020104@redhat.com> On 07/19/2013 11:30 AM, Jan Pazdziora wrote: > On Fri, Jul 19, 2013 at 10:46:13AM +0200, Petr Viktorin wrote: >> >> IPA uses "ipa" as the "package name" for all translations, >> even in the ipa-client package. >> >> https://fedorahosted.org/freeipa/ticket/3695 >> --- >> ipa-client/ipa-client-common.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipa-client/ipa-client-common.c b/ipa-client/ipa-client-common.c >> index 68861c654e2254c4aceccd5497e8eda3f2c593de..23f384a6e0855582de8a83b84f40c40dd3b6c148 100644 >> --- a/ipa-client/ipa-client-common.c >> +++ b/ipa-client/ipa-client-common.c >> @@ -33,13 +33,13 @@ int init_gettext(void) >> } >> >> errno = 0; >> - c = bindtextdomain(PACKAGE, LOCALEDIR); >> + c = bindtextdomain("ipa", LOCALEDIR); >> if (c == NULL) { >> return errno; >> } >> >> errno = 0; >> - c = textdomain(PACKAGE); >> + c = textdomain("ipa"); > > Ack. > Second ACK, works fine: # LANG=es_ES ipa-getkeytab -k /tmp/foo.keytab -s vm-119.example.com -p foo/vm-119.example.com at EXAMPLE.COM Tabla de claves recuperada y almacenada correctamente en:/tmp/foo.keytab Pushed to master, ipa-3-2. Martin From tbabej at redhat.com Fri Jul 19 10:32:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 19 Jul 2013 12:32:04 +0200 Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range Message-ID: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> Hi, I still need to test this with AD 2008. Sending so that code can get some review before that. https://fedorahosted.org/freeipa/ticket/3649 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0076-Use-AD-LDAP-probing-to-create-trusted-domain-ID-rang.patch Type: text/x-patch Size: 16625 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jul 19 10:41:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Jul 2013 13:41:05 +0300 Subject: [Freeipa-devel] [PATCH] 0049 Use admin@REALM when testing if SSSD is ready In-Reply-To: <51E82C31.1000009@redhat.com> References: <51E82C31.1000009@redhat.com> Message-ID: <20130719104105.GZ18587@redhat.com> On Thu, 18 Jul 2013, Ana Krivokapic wrote: >Hello, > >This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3771. ACK. -- / Alexander Bokovoy From mkosek at redhat.com Fri Jul 19 10:41:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Jul 2013 12:41:12 +0200 Subject: [Freeipa-devel] [PATCH] 0049 Use admin@REALM when testing if SSSD is ready In-Reply-To: <51E82C31.1000009@redhat.com> References: <51E82C31.1000009@redhat.com> Message-ID: <51E917C8.40807@redhat.com> On 07/18/2013 07:56 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3771. > ACK. Pushed to master, ipa-3-2. Martin From pvoborni at redhat.com Fri Jul 19 11:10:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 13:10:49 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E809E6.4040103@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> Message-ID: <51E91EB9.3000306@redhat.com> On 07/18/2013 05:29 PM, Jan Cholasta wrote: > On 18.7.2013 17:26, Martin Kosek wrote: >> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>> On 18.7.2013 17:07, Martin Kosek wrote: >>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>> Added patch which adds new hidden option no_members to suppress >>>>> membership >>>>> processing for commands of all objects that have member attributes. >>>>> This can be >>>>> used by the WebUI to prevent member lookups where they are not >>>>> necessary (as we >>>>> discussed off-line with Martin and Petr). >>>>> >>>>> Honza >>>>> >>>> >>>> 1) Should the new option really have "exclude='webui'? I thought >>>> that Web UI is >>>> the main and only consumer of this option. >>> >>> The 'webui' context doesn't actually exist and the only meaning of >>> this stanza >>> is that the option is not shown in the output of the show_mappings >>> command. >>> >>>> >>>> 2) I would clearly state this is an internal option only, e.g. >>>> >>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>> >>> No other internal option has this kind of thing in its doc and nobody >>> will see >>> it anyway, so we might just leave it like that IMHO. >> >> OK. >> >>> >>>> >>>> 3) It would be nice to state that this option is mutually exclusive >>>> with --all, >>>> but given it is internal anyway and there is no central place to >>>> define it, we >>>> do not need to do that. >>> >>> The options are not really mutually exclusive at this point, they can be >>> specified together, --all takes precedence. >> >> Well, they can be specified together, but the option is then NOOP >> which could >> confuse users which may have different expectations. Being explicit >> helps. > > I agree. > >> But >> as I said, in this case this is not a requirement. > > I agree as well :-) > > Honza > Functional ACK for Honza's patch (didn't break Web UI test suite) Attaching Web UI patch. It: 1) Removed --all from _find and _show commands used by search pages. All displayed attributes should be already included in default attributes. 2) Removed search_all_attributes - Not needed since introduction of paging. 3) Added --no-members options to search _show commmands. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0435-Web-UI-search-optimization.patch Type: text/x-patch Size: 5453 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 19 11:44:57 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 13:44:57 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label Message-ID: <51E926B9.4000108@redhat.com> Remove word 'field' from GECOS param label No other param/field has 'field' in a label. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0436-Remove-word-field-from-GECOS-param-label.patch Type: text/x-patch Size: 870 bytes Desc: not available URL: From jpazdziora at redhat.com Fri Jul 19 12:20:21 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 19 Jul 2013 14:20:21 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51E926B9.4000108@redhat.com> References: <51E926B9.4000108@redhat.com> Message-ID: <20130719122021.GI1972@redhat.com> On Fri, Jul 19, 2013 at 01:44:57PM +0200, Petr Vobornik wrote: > Remove word 'field' from GECOS param label > > No other param/field has 'field' in a label. I'm not sure I'm in favour of the change. Calling it just "GECOS" does not make much sense because as an informational field in /etc/passwd, it is not General Electric Comprehensive Operating System. It is the field that was (I assume) acced by/for GECOS back then but still the full name is "GECOS field (of /etc/passwd)". -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From tbabej at redhat.com Fri Jul 19 12:24:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 19 Jul 2013 14:24:55 +0200 Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> Message-ID: <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> On Friday 19 of July 2013 12:32:04 Tomas Babej wrote: > Hi, > > I still need to test this with AD 2008. Sending so that code can get some review before that. > > https://fedorahosted.org/freeipa/ticket/3649 > > Tomas This version fixes few small build nitpicks. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0076-2-Use-AD-LDAP-probing-to-create-trusted-domain-ID-rang.patch Type: text/x-patch Size: 19245 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 19 13:17:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 15:17:49 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <20130719122021.GI1972@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> Message-ID: <51E93C7D.5010600@redhat.com> On 07/19/2013 02:20 PM, Jan Pazdziora wrote: > On Fri, Jul 19, 2013 at 01:44:57PM +0200, Petr Vobornik wrote: >> Remove word 'field' from GECOS param label >> >> No other param/field has 'field' in a label. > > I'm not sure I'm in favour of the change. Calling it just "GECOS" does > not make much sense because as an informational field in /etc/passwd, > it is not General Electric Comprehensive Operating System. It is the > field that was (I assume) acced by/for GECOS back then but still the > full name is "GECOS field (of /etc/passwd)". > Disclaimer: I have no strong feelings in this matter, it just looks weird to me, so I'm OK with not doing it if it's general consensus. Originally we wanted to do this change in https://fedorahosted.org/freeipa/ticket/3569 but it was not done because of string freeze. I guess you can add field suffix to every field from /etc/password when you use it in a sentence but that doesn't necessary mean that it's its name. man 5 passwd doesn't use word 'field' next to GECOS in fields description/list either. IMO our use case is the same. Historically correct label would probably be 'GECOS identity' but that's not usable today as it's purpose is more general. -- Petr Vobornik From jpazdziora at redhat.com Fri Jul 19 13:26:40 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 19 Jul 2013 15:26:40 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51E93C7D.5010600@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> Message-ID: <20130719132640.GL1972@redhat.com> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: > > Disclaimer: I have no strong feelings in this matter, it just looks > weird to me, so I'm OK with not doing it if it's general consensus. > Originally we wanted to do this change in > https://fedorahosted.org/freeipa/ticket/3569 but it was not done > because of string freeze. > > I guess you can add field suffix to every field from /etc/password > when you use it in a sentence but that doesn't necessary mean that You can. But gid exists as a concept beyond /etc/passwd. So does home directory. The GECOS field value does not, really. > it's its name. man 5 passwd doesn't use word 'field' next to GECOS > in fields description/list either. IMO our use case is the same. It says: GECOS This field (sometimes called the "comment field") [...] The gcos field in the password file was [...] > Historically correct label would probably be 'GECOS identity' but > that's not usable today as it's purpose is more general. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From jcholast at redhat.com Fri Jul 19 13:49:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 19 Jul 2013 15:49:38 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E91EB9.3000306@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> Message-ID: <51E943F2.9080700@redhat.com> On 19.7.2013 13:10, Petr Vobornik wrote: > On 07/18/2013 05:29 PM, Jan Cholasta wrote: >> On 18.7.2013 17:26, Martin Kosek wrote: >>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>> Added patch which adds new hidden option no_members to suppress >>>>>> membership >>>>>> processing for commands of all objects that have member attributes. >>>>>> This can be >>>>>> used by the WebUI to prevent member lookups where they are not >>>>>> necessary (as we >>>>>> discussed off-line with Martin and Petr). >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> 1) Should the new option really have "exclude='webui'? I thought >>>>> that Web UI is >>>>> the main and only consumer of this option. >>>> >>>> The 'webui' context doesn't actually exist and the only meaning of >>>> this stanza >>>> is that the option is not shown in the output of the show_mappings >>>> command. >>>> >>>>> >>>>> 2) I would clearly state this is an internal option only, e.g. >>>>> >>>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>>> >>>> No other internal option has this kind of thing in its doc and nobody >>>> will see >>>> it anyway, so we might just leave it like that IMHO. >>> >>> OK. >>> >>>> >>>>> >>>>> 3) It would be nice to state that this option is mutually exclusive >>>>> with --all, >>>>> but given it is internal anyway and there is no central place to >>>>> define it, we >>>>> do not need to do that. >>>> >>>> The options are not really mutually exclusive at this point, they >>>> can be >>>> specified together, --all takes precedence. >>> >>> Well, they can be specified together, but the option is then NOOP >>> which could >>> confuse users which may have different expectations. Being explicit >>> helps. >> >> I agree. >> >>> But >>> as I said, in this case this is not a requirement. >> >> I agree as well :-) >> >> Honza >> > > Functional ACK for Honza's patch (didn't break Web UI test suite) > > Attaching Web UI patch. > > It: > 1) Removed --all from _find and _show commands used by search pages. All > displayed attributes should be already included in default attributes. > > 2) Removed search_all_attributes - Not needed since introduction of paging. > > 3) Added --no-members options to search _show commmands. Hmm, is the has_members function used to distinguish between objects with members and without members? If so, would it be helpful to add the no_members option to all commands (just like "all" and "raw"), so that you don't have to do this check? Honza -- Jan Cholasta From pvoborni at redhat.com Fri Jul 19 14:01:35 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 16:01:35 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E943F2.9080700@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> <51E943F2.9080700@redhat.com> Message-ID: <51E946BF.10609@redhat.com> On 07/19/2013 03:49 PM, Jan Cholasta wrote: > On 19.7.2013 13:10, Petr Vobornik wrote: >> On 07/18/2013 05:29 PM, Jan Cholasta wrote: >>> On 18.7.2013 17:26, Martin Kosek wrote: >>>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>>> Added patch which adds new hidden option no_members to suppress >>>>>>> membership >>>>>>> processing for commands of all objects that have member attributes. >>>>>>> This can be >>>>>>> used by the WebUI to prevent member lookups where they are not >>>>>>> necessary (as we >>>>>>> discussed off-line with Martin and Petr). >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> 1) Should the new option really have "exclude='webui'? I thought >>>>>> that Web UI is >>>>>> the main and only consumer of this option. >>>>> >>>>> The 'webui' context doesn't actually exist and the only meaning of >>>>> this stanza >>>>> is that the option is not shown in the output of the show_mappings >>>>> command. >>>>> >>>>>> >>>>>> 2) I would clearly state this is an internal option only, e.g. >>>>>> >>>>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>>>> >>>>> No other internal option has this kind of thing in its doc and nobody >>>>> will see >>>>> it anyway, so we might just leave it like that IMHO. >>>> >>>> OK. >>>> >>>>> >>>>>> >>>>>> 3) It would be nice to state that this option is mutually exclusive >>>>>> with --all, >>>>>> but given it is internal anyway and there is no central place to >>>>>> define it, we >>>>>> do not need to do that. >>>>> >>>>> The options are not really mutually exclusive at this point, they >>>>> can be >>>>> specified together, --all takes precedence. >>>> >>>> Well, they can be specified together, but the option is then NOOP >>>> which could >>>> confuse users which may have different expectations. Being explicit >>>> helps. >>> >>> I agree. >>> >>>> But >>>> as I said, in this case this is not a requirement. >>> >>> I agree as well :-) >>> >>> Honza >>> >> >> Functional ACK for Honza's patch (didn't break Web UI test suite) >> >> Attaching Web UI patch. >> >> It: >> 1) Removed --all from _find and _show commands used by search pages. All >> displayed attributes should be already included in default attributes. >> >> 2) Removed search_all_attributes - Not needed since introduction of >> paging. >> >> 3) Added --no-members options to search _show commmands. > > Hmm, is the has_members function used to distinguish between objects > with members and without members? If so, would it be helpful to add the > no_members option to all commands (just like "all" and "raw"), so that > you don't have to do this check? > > Honza > Yes, that's its purpose. IMO it doesn't matter now, the function is implemented. The only benefits would be small, not noticeable, performance gain and tolerance to incorrect use of --no-members. Doesn't look like a reason for polluting all commands with it. -- Petr Vobornik From pvoborni at redhat.com Fri Jul 19 15:17:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 17:17:55 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E946BF.10609@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> <51E943F2.9080700@redhat.com> <51E946BF.10609@redhat.com> Message-ID: <51E958A3.4080705@redhat.com> On 07/19/2013 04:01 PM, Petr Vobornik wrote: > On 07/19/2013 03:49 PM, Jan Cholasta wrote: >> On 19.7.2013 13:10, Petr Vobornik wrote: >>> On 07/18/2013 05:29 PM, Jan Cholasta wrote: >>>> On 18.7.2013 17:26, Martin Kosek wrote: >>>>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>>>> Added patch which adds new hidden option no_members to suppress >>>>>>>> membership >>>>>>>> processing for commands of all objects that have member attributes. >>>>>>>> This can be >>>>>>>> used by the WebUI to prevent member lookups where they are not >>>>>>>> necessary (as we >>>>>>>> discussed off-line with Martin and Petr). >>>>>>>> >>>>>>>> Honza snip >>>>>>> >>>>>>> 3) It would be nice to state that this option is mutually exclusive >>>>>>> with --all, >>>>>>> but given it is internal anyway and there is no central place to >>>>>>> define it, we >>>>>>> do not need to do that. >>>>>> >>>>>> The options are not really mutually exclusive at this point, they >>>>>> can be >>>>>> specified together, --all takes precedence. >>>>> >>>>> Well, they can be specified together, but the option is then NOOP >>>>> which could >>>>> confuse users which may have different expectations. Being explicit >>>>> helps. >>>> >>>> I agree. >>>> >>>>> But >>>>> as I said, in this case this is not a requirement. >>>> >>>> I agree as well :-) >>>> >>>> Honza >>>> >>> >>> Functional ACK for Honza's patch (didn't break Web UI test suite) >>> >>> Attaching Web UI patch. >>> >>> It: >>> 1) Removed --all from _find and _show commands used by search pages. All >>> displayed attributes should be already included in default attributes. >>> >>> 2) Removed search_all_attributes - Not needed since introduction of >>> paging. >>> >>> 3) Added --no-members options to search _show commmands. >> >> Hmm, is the has_members function used to distinguish between objects >> with members and without members? If so, would it be helpful to add the >> no_members option to all commands (just like "all" and "raw"), so that >> you don't have to do this check? >> >> Honza >> > > Yes, that's its purpose. IMO it doesn't matter now, the function is > implemented. The only benefits would be small, not noticeable, > performance gain and tolerance to incorrect use of --no-members. Doesn't > look like a reason for polluting all commands with it. Here are backports of jcholast-160 and pvoborni-435 to ipa-3-0. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-160-ipa-3-0-Add-new-hidden-command-option-to-suppress-processing.patch Type: text/x-patch Size: 113901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0435-ipa-3-0-Web-UI-search-optimization.patch Type: text/x-patch Size: 5898 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 19 15:59:52 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Jul 2013 17:59:52 +0200 Subject: [Freeipa-devel] [PATCH] 428 Hide delete button in multivalued widget if attr is not writable In-Reply-To: <1374162633.6496.1.camel@freed.mh.shawcable.net> References: <51E7BF57.6060802@redhat.com> <1374162633.6496.1.camel@freed.mh.shawcable.net> Message-ID: <51E96278.4040206@redhat.com> On 07/18/2013 05:50 PM, James wrote: > On Thu, 2013-07-18 at 12:11 +0200, Petr Vobornik wrote: >> Hide delete button in multivalued widget if attr is not writable > Hey, > > Maybe it would be a good idea to set the disabled state of the button > instead of removing it? That way it's obvious that some attrs can be > deleted, and it won't cause users to "search" for a button that doesn't > exist... > > Cheers, > James Hello, Note: the button is actually in a form of a link The approach you're proposing is often valid and a preferred one but I don't think it's the best approach for our case. Web UI uses a pattern where textboxes are changed to simple text when user doesn't have write rights. This transformation pretty much says: "no you can't do anything with this attribute". This pattern is all around the UI since textbox is the most common widget. Multivalued widget internally uses textboxes and so that transformation. It also already hides the 'add' button (link). IMO leaving 'delete' buttons next to the text values just clutters the UI. -- Petr Vobornik From abokovoy at redhat.com Fri Jul 19 16:18:50 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Jul 2013 19:18:50 +0300 Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> Message-ID: <20130719161850.GD18587@redhat.com> On Fri, 19 Jul 2013, Tomas Babej wrote: >On Friday 19 of July 2013 12:32:04 Tomas Babej wrote: >> Hi, >> >> I still need to test this with AD 2008. Sending so that code can get some review before that. >> >> https://fedorahosted.org/freeipa/ticket/3649 >> >> Tomas > >This version fixes few small build nitpicks. ACK, works fine for me. It requires my patches 0109-0110. -- / Alexander Bokovoy From pspacek at redhat.com Fri Jul 19 16:29:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Jul 2013 18:29:06 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1374078320.32040.96.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> Message-ID: <51E96952.2070804@redhat.com> On 17.7.2013 18:25, Simo Sorce wrote: > On Tue, 2013-07-16 at 17:15 +0200, Petr Spacek wrote: >> On 15.7.2013 21:07, Simo Sorce wrote: [...] >>>> KSK has to be rolled over manually because it requires changes in parent zone. >>>> (It could be automated for sub-zones if their parent zone is also managed by >>>> the same IPA server.) >>> >>> Is there any provision for using DNSSEC with private DNS deployments ? >> Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS resolvers >> can be configured with 'trust anchors' explicitly. E.g. 'trust domain >> example.com only if it is signed by /this/ key, use root key for rest of the >> Internet' etc. >> >> [Terminology] http://tools.ietf.org/html/rfc4033#section-2 > > This means clients would have to be configured to explicitly trust a > specific key for a zone right ? How hard would it be for us to configure > IPA clients this way assuming by then we have a DNSSEC aware resolver we > can configure on them ? Answer really depends on 'DNSSEC aware resolver we can configure'. Glibc doesn't support DNSSEC validation at all. Fedora 17+ solves this problem via Unbound daemon: Glibc is configured to use local DNS server (127.0.0.1 in /etc/resolv.conf) and local Unbound daemon does the actual resolution and validation. Details are here: https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations Unbound can be configured with custom trust anchor via single line with public key in a configuration file, it is really simple. The problem could be with other clients. I don't know how Windows can handle this. There are some options in Group Policy, but I have no idea what can be configured and what can't. >>> Or is this going to make sense only for IPA deployments that have valid >>> delegation from the public DNS system ? >>> >>> Hmmm I guess that as long as the KSK in the 'parent' zone is imported >>> properly a private deployment of corp.myzone.com using the KSK of >>> myzone.com will work just fine even if corp.myzone.com is not actually >>> delegated but is a private DNS tree ? >>> Or is that incorrect ? >> >> AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from >> the parent, but IMHO it could work if only the public key for internal zones >> is published (without any delegation to internal name servers etc.). I didn't >> try it, so 'here be dragons'. > > Are there test/zones keys that can be used to experiment ? It is possible to generate own keys, sign own root zone etc. and have own private DNS tree, including the root. The only caveat is that you has to put your 'root key' to each testing client, but it is relatively simple. I did it in lab :-) After some experiments I found that publishing of DS records will not work without proper delegation (including NS records and IP addresses). Delegation from public servers is not usable if the clients can't start from public servers and go down through the tree to the internal servers. Reasons are clear from the top-down verification process, as described in: http://backreference.org/2010/11/17/dnssec-verification-with-dig/ Interesting reading is: https://www.dnssec-tools.org/svn/dnssec-tools/tags/dnssec-tools-1.3/validator/doc/libval-implementation-notes Particularly the section "Top-down versus bottom-up validation" is very interesting. It could work if either internal and external zones are delegated from public DNS (i.e. DS, NS and A/AAAA records are in place) but the internal name servers reply only to internal clients. To conclude it, purely internal deployments require explicit trust anchor configuration in all cases. Moreover, explicit trust anchor configuration will be required if the user/company is paranoid and don't want to publish delegation records for internal zones in public DNS. [...] >>> No, the problem is that we need to define 'who' generates the keys. >>> Remember FreeIPA is a multimaster system, we cannot have potentially >>> conflicting cron jobs running on multiple servers. >> Right. It sounds like the CRL generation problem. Should we do the same for >> DNSSEC key regeneration? I.e. select one super-master and let it to handle key >> regeneration? Or should we find some more robust solution? I'm not against any >> of these possibilities :-) > > Falling back to SPOF should be the last resort or a temporary step > during development. Sure. Fedora 20 dead lines are really close. Are you okay with something like do-it-in-cron-on-sigle-machine for the first implementation? > I would like to avoid SPOF architectures if at all possible. > We could devise a way to automatically 'elect' a master, but have all > other DNS servers also monitor that keys are regenerated an made > available in the expected time frame and if not have one of the other > DNS servers try to assume the leader role. > > I have some ideas hear using priorities etc, but I need to let them brew > in my mind a little bit more :) I'm curious! :-) > > [..] > >>>> For these reasons I think that we can define new public key attribute in the >>>> same way as private key attribute: >>>> attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX >>>> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) >>>> >>>> The resulting object class could be: >>>> objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP >>>> top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) >>> >>> Will bind read these attributes ? >>> Or will we have to dump these values into files via bind-dyndb-ldap for >>> bind9 to read them back ? >> AFAIK it has to be in files: Private key in one file and public key in the >> other file. I can't find any support for reading private keys from buffers. > > Ok so to summarize we basically are going to load the private key file > in idnsSecPrivateKey and the public key file in idnsSecPublicKey as > blobs and the have bind-dyndb-ldap fetch them and save them into files > that bind can access. > This means bind-dyndb-ldap will need to grow the ability to also clean p > and synchronize the files over time. So there will need to be hooks to > regularly check all needed files are in place and obsolete ones are > deleted. Syncrepl will notify bind-dyndb-ldap about each change via LDAP, it should be enough if we decide to do key management in a helper daemon. > Maybe we can grow a companion python helper to do this, as it > is a relatively simple task, that is not performance critical and will > be much easier to write in a scripting language than in C. But I am not > opposed to an in-daemon solution either. Again, schedule is tight: Could we do something simple & stupid for the first version? Of course, we have to warn: 'We have first DNSSEC implementation, but it is fragile!' :-) > [..] > >>> ack, should we have an explicit attribute that tells us what type it >>> is ? >> May be, we will see. It is possible that we will need to store key algorithm >> and key ID explicitly for some reason. >> >> I'm still not sure that I understand to all aspects of key management in BIND. > > Ok, so I guess we need some reasearch in here before committing 100% to > a plan, but so far it looks like the general plan is clear enough. I spent some time with the code and it seems that: - Public and private keys have to be in separate files - File names have to follow special format - We are able to reconstruct file name by this: - 1) Save keys to temporary directory - 2) Load & parse keys to the memory - 3) Get key metadata and reconstruct correct file names - 4) Save keys again and remove temporary files - This magic will be unnecessary if we decide to save algorithm *number* (not a readable name) and key id explicitly in LDAP >>> One weak reason to allow read by admins would be to allow them to >>> migrate away, but I do not like to put these keys completely unprotected >>> in LDAP. Given bind has a keytab I was thinking we may want to encrypt >>> these keys with the DNS long term key, however this complicates the code >>> slightly in 2 ways: >>> 1. we can have multiple DNS Servers (ie multiple keys) >>> 2. we need to allow for roll-over >> >> I see two more problems: >> 3. it would make Kerberos required (now the plugin doesn't require Kerberos) > > It could be optional, if the option is not enabled no master-key > encryption scheme is used. > >> 4. we use SASL but I think that your approach would require direct >> manipulation with keytab > > Yes we'd need to read the keytab to get the long term key, but we could > defer this to a companion tool in python as I mentioned before and let > bind-dyndb-ldap ignorant of the keytab. > Actually this is a quite compelling argument, as this means we could use > gssproxy to not give access to the keytab at all to the bind process, > thus adding extra privilege seapration and protection, The python > companion would instea dneed access so communication between > bind-dyndb-ldap and the companion daemon would need to happen cross > trust boundary, ie a socket and/or systemd/dbus activation or similar. May be. At this point the separate daemon sounds like really good idea. [...] >>>> The rest of the configuration options are related to the key management >>>> problem. We need to know: >>>> - how many key pairs (e.g. 2 KSKs, 2 ZSKs) >>> >>> Shouldn't we allow an arbitrary number ? Does bind have strict limits ? >> Yes, arbitrary number sounds fine. 2 + 2 was just an example. >> >>>> - when (e.g. generate new key pair 30 days before active key expires) >>> >>> probably needs to be tunable. new attribute ? >>> >>>> - of which key types (KSK or ZSK) >>>> - with which algorithms >>>> - with which key lengths >>>> should be generated. Note that we need to store configuration about X KSKs and >>>> Y ZSKs. >>> >>> seem all of these needs to be tunables and require their own >>> attributes ? >> I agree. The question is how to group the attributes to make it useful. > > ok > >> IMHO it should express something like this: >> - I want to use 1 KSK with algorithm RSASHA1, key length 2048 bits, the key >> should be used for 1 year. >> - I want to have 1 other KSK (with same parameters) ready for roll over at any >> time. >> - Roll over period is 1 month. (The time required for incremental resigning >> with the new key, i.e. the time period when old and new signatures will co-exist.) >> >> The result should be: >> >> In time 0 (zone creation), generate 2 KSKs: >> The KSK 'A' would have these timestamps: >> - created = published = active from = 0 (generate signatures immediately) >> - inactive = 0 + 1 year - 1 month (stop generating signatures after 11 months) >> - delete = 0 + 1 year (one month was transitional period for incremental >> resigning with the new key, then delete the key 'A') >> >> The KSK 'B' would be generated at the same time as 'A': >> - created = published = 0 (publish key, but don't generate signatures) >> - active from = 0 + 1 year >> - inactive = 0 + 2 years - 1 month >> - delete = 0 + 2 years >> >> During the first year, all records will be signed with KSK 'A'. In time '0 + 1 >> year - 1 month' KSK 'A' will become inactive and KSK 'B' will become active. >> At the same time, new KSK 'C' will be generated with following timestamps: >> - created = published = 1 year - 1 month (publish key, but don't generate >> signatures) >> - active from = 0 + 2 year - 1 month >> - inactive = 0 + 3 years - 1 month >> - delete = 0 + 3 years >> >> All records will be re-signed using KSK 'B' during time <1 year - 1 month, 1 >> year>. >> >> In time '0 + 1 year' all signatures were regenerated with using KSK 'B' and >> KSK 'A' will be removed. > > shouldn't we regenerate all signatures with KSK B at '0 + 11mo', ie 1 > month before KSK A is finally deleted ? BIND will handle this auto-magically for us. We just need to specify how long is the period between 'obsoleting' of the key and removing of the key from zone. AFAIK the current code in BIND9 computes required re-signing rate and does re-signing incrementally to not kill CPU on the server. IMHO important point is that each individual signature has validity-end timestamp and this timestamp limits TTL in all caches. Invalid signatures will be purged when the old key expires (at the latest). This forces clients to get new signatures, even if the record was re-signed in the last minute. Naturally, cache is very important part of DNS and nobody wants to flush all data from all caches at once. >> Note that you may want to use 1 KSK with algorithm RSA and another KSK with DSA. > > Ok > >> I'm not really sure if it makes sense. Could something like this work? >> >> objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyGroup' DESC 'DNSSEC key group' SUP >> top STRUCTURAL MUST >> ( cn $ >> key type $ # (KSK or ZSK) >> algorithm $ # (RSA, DSA) >> key length $ # (2048) >> lifetime of the key $ # (1 year) >> roll over period $ # (1 month) >> number of active keys $ # (1) >> number of spare keys $ # (1) >> ) ) > > To summarize it seem you have 2 distinctive objects you really need. > > 1. additional parameters to the key (active time and delete time, and > although those times are also embedded in the blob they should probably > be replicated also in idnsSecKeyPair objectclass so that this info can > be easily queried w/o needing access to the key material itself. It makes sense, but we have to solve synchronization if some timestamp is changed. It is possible to change timestamps via dnssec-settime utility (e.g. timestamp of revocation). > 2. a policy about how often you want to rotate and use keys, and what > parameters to use by default when creating new keys automatically at > rotation time. And that policy may need to be per zone. > > so > > I would rename 'idnsSecKeyGroup' to 'idnsSecKeyPolicy', make it > auxiliary and add it to the zone object when DNSSEc is in use. > The attributes you mention seem all is needed. > >> The key group could be stored as >> cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test >> Keys could be stored as individual objects under >> cn=id, cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test > > This is also an option, but why an aditional object when we can simply > ad the attributes to the zone file ? > > Is there any instance where you might want multiple policies for zones? > (I do not see how that would work) Yes, there is. My example didn't mention that explicitly, but Remember that there are at least two groups of keys: KSK (long-term) and ZSK (shorter-term). For this reason we need to store two distinct sets of 'policy' attributes at least. The situation will be even worse if you need to migrate to different algorithm/key length etc., because it can (temporarily) increase number of 'policies'. More specifically, because we need at least: cn=ksk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test cn=zsk-rsa, idsname=example.com, cn=dns, dc=ipa,dc=test E.g. for migration to DSA (but still with RSA in place): cn=zsk-dsa, idsname=example.com, cn=dns, dc=ipa,dc=test >> In usual cases it solves grouping of KSKs and ZSKs. > > Why do you need to further 'group' them ? There is no technical reason. It could simplify some UI operations (listing all KSKs, deleting whole group of keys at once etc.), but that is all. We can live without it. >> Also, it enables us to >> define key group with RSA and another one with DSA algorithm or to migrate >> from a key group with shorter keys to a key group with longer keys. > > I am not sure how this would help, isn't is sufficient to add the 'type' > to 'idnsSecKeyPair', so you know what type it is regardless ? Although I > am not even sure why we would care, bind is the one doing the signing > and the type is already known to bind as it reads it from the private > file, right ? Explicit attribute for key type could simplify UI and key manipulation, but it not truly necessary. > I may be missing some detail here ... > > [..] > >> I have a crazy idea: Could OpenSSL PKCS#11 implementation help us to deal with >> the key management problems mentioned above - somehow? >> >> I know next to nothing about PKCS#11 and related areas, but problems we met >> (like safe key storage & transport) sounds like something common. >> >> Could we use PKCS#11 in some clever way, let OpenSSL to do the dirty work with >> key encryption/retrieval and solve HSM support and security at once? > > Yes we will certainly reuse crypto primitives from NSS or OpenSSL, but > that doesn't help with 'key management' itself, that's on us :) > >> Would it be possible to write PKCS#11 module for OpenSSL and let it to store >> keys in IPA - in some generic way? So it will solve key storage for all >> OpenSSL/PKCS#11 enabled applications and not only for bind-dyndb-ldap? > > Dogtag has a generic store, but a generic store is not really our > problem here. and I am not sure we want to tie this to dogtag, we might. > >> As I said, it is just crazy idea ... and I really know nothing about this area. > > Let's explore and see pros/cons. > , the main con I see to involving dogtag is that it would force us to > install dogtag on each DNS server (or risk having keys in a remote > server so net communicationa nd additional issues of reachability). > > I think we want to be able to keep installing FreeIPA+DNS and FreeIPA+CA > and not force FreeIPa+DNS+CA for all DNS servers, as we might want a > 'lightweight' FreeIPA+DNS replica or even in future just a LDAP+DNS > 'replica' only for load balancing of DNSes, so forcing the full CA > dependency would be undesirable. Extreme case, given syncrepl will keep > everything synced locally we may even go with bind+bind-dyndb-ldap > *only* and rely on remote LDAP server to bind to ... I agree. I still like the idea of 'The Something' which provides PKCS#11 interface. The 'something' could be configured to use Dogtag or real HSM or our home-grown-IPA-key-storage or e.g. 'softhsm' storage provided by the same package in Fedora. It would allow us to simply switch to really secure storage if it is required for particular deployment or stay with files on disk very simply. Remember that I have no idea what 'The Something' could be and how it could work! :-) I just think that general key storage storage with well-defined interface is better than our private magic tool. Other programs could use it for key storage if it is general enough. The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Have a nice weekend. -- Petr^2 Spacek From simo at redhat.com Fri Jul 19 17:55:00 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Jul 2013 13:55:00 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <51E96952.2070804@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> Message-ID: <1374256500.32040.248.camel@willson.li.ssimo.org> I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > > The most important question at the moment is "What can we postpone? > How > fragile it can be for shipping it as part of Fedora 20?" Could we > declare > DNSSEC support as "technology preview"/"don't use it for anything > serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Simo. > -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Fri Jul 19 20:24:48 2013 From: purpleidea at gmail.com (James) Date: Fri, 19 Jul 2013 16:24:48 -0400 Subject: [Freeipa-devel] [PATCH] 428 Hide delete button in multivalued widget if attr is not writable In-Reply-To: <51E96278.4040206@redhat.com> References: <51E7BF57.6060802@redhat.com> <1374162633.6496.1.camel@freed.mh.shawcable.net> <51E96278.4040206@redhat.com> Message-ID: <1374265488.12153.6.camel@freed> On Fri, 2013-07-19 at 17:59 +0200, Petr Vobornik wrote: > Hello, > > Note: the button is actually in a form of a link I didn't notice this before. Sorry for the noise. James > > The approach you're proposing is often valid and a preferred one but > I > don't think it's the best approach for our case. > > Web UI uses a pattern where textboxes are changed to simple text when > user doesn't have write rights. This transformation pretty much says: > "no you can't do anything with this attribute". This pattern is all > around the UI since textbox is the most common widget. > > Multivalued widget internally uses textboxes and so that > transformation. > It also already hides the 'add' button (link). IMO leaving 'delete' > buttons next to the text values just clutters the UI. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Fri Jul 19 21:19:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Jul 2013 17:19:38 -0400 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <20130719132640.GL1972@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> Message-ID: <51E9AD6A.80104@redhat.com> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: > On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >> Disclaimer: I have no strong feelings in this matter, it just looks >> weird to me, so I'm OK with not doing it if it's general consensus. >> Originally we wanted to do this change in >> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >> because of string freeze. >> >> I guess you can add field suffix to every field from /etc/password >> when you use it in a sentence but that doesn't necessary mean that > You can. But gid exists as a concept beyond /etc/passwd. So does home > directory. The GECOS field value does not, really. > >> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >> in fields description/list either. IMO our use case is the same. > It says: > > GECOS This field (sometimes called the "comment field") > [...] > The gcos field in the password file was > [...] > >> Historically correct label would probably be 'GECOS identity' but >> that's not usable today as it's purpose is more general. Do we have tips in the UI? May be we should add them in future to provide extra information about meaning of the field or button. For now I think GECOS would probably be good enough. Adding "field" makes it more precise but looks weird. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Jul 19 21:56:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Jul 2013 17:56:15 -0400 Subject: [Freeipa-devel] FreeIPA AD Trust improvements, Fedora 19 Test Day, July 25th Message-ID: <51E9B5FF.7020306@redhat.com> Hello, The FreeIPA team is happy to welcome you to a Fedora Test Day that is being held on Thursday, July 25th. We would like to invite you to take part in testing of the upcoming FreeIPA 3.3 release containing 2 major improvements for easier deployment of FreeIPA Active Directory Trust feature to existing environments: 1) Use POSIX attributes defined in Active Directory [1] With previous FreeIPA releases, users coming from Active Directory to FreeIPA managed machines were always assigned POSIX attributes (UID and GID) by algorithmic mapping. However, in some deployments, Active Directory users and groups already have defined custom POSIX attribute values (UID and GID), which may then be leveraged on Linux machines via other 3rd party Active Directory integration solutions. Administrator may choose to keep the values to not disrupt file ownerships. With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use these attributes when Active Directory user authenticates to Linux machines. 2) Expose POSIX data on legacy systems without recent SSSD Administrators may have a deployment of machines which cannot use the recent SSSD with Active Directory Trust support but would still like to be able to authenticate with Active Directory user to these machines. This may affect for example older Linux machines, UNIX machines. With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree which will contain identities of the Active Directory users to the legacy systems. These systems may then leverage standard LDAP authentication in this tree allowing selected Active Directory users to authenticate. To read more about the Test Day and suggested tests, see the following link: https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients Thank you for your help and participation! The FreeIPA team [1] http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD [2] http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts [IdM | IPA] FAQs: https://url.corp.redhat.com/idm-faq Identity Management SME Team on Docspace https://url.corp.redhat.com/sme-idm Search the archives: post-office.corp.redhat.com/mailman/listinfo/idm-tech From mkosek at redhat.com Mon Jul 22 07:01:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Jul 2013 09:01:42 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51E9AD6A.80104@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> Message-ID: <51ECD8D6.30400@redhat.com> On 07/19/2013 11:19 PM, Dmitri Pal wrote: > On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>> Disclaimer: I have no strong feelings in this matter, it just looks >>> weird to me, so I'm OK with not doing it if it's general consensus. >>> Originally we wanted to do this change in >>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>> because of string freeze. >>> >>> I guess you can add field suffix to every field from /etc/password >>> when you use it in a sentence but that doesn't necessary mean that >> You can. But gid exists as a concept beyond /etc/passwd. So does home >> directory. The GECOS field value does not, really. >> >>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>> in fields description/list either. IMO our use case is the same. >> It says: >> >> GECOS This field (sometimes called the "comment field") >> [...] >> The gcos field in the password file was >> [...] >> >>> Historically correct label would probably be 'GECOS identity' but >>> that's not usable today as it's purpose is more general. > Do we have tips in the UI? > May be we should add them in future to provide extra information about > meaning of the field or button. > For now I think GECOS would probably be good enough. > Adding "field" makes it more precise but looks weird. +1 for just "GECOS". Petr showed me both variants in the UI and "GECOS field" really looked weird. Martin From pviktori at redhat.com Mon Jul 22 08:51:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Jul 2013 10:51:25 +0200 Subject: [Freeipa-devel] [PATCH] 0043 Fix internal error in idrange-add In-Reply-To: <20130712153238.GX18587@redhat.com> References: <51E01E2D.3050507@redhat.com> <20130712153238.GX18587@redhat.com> Message-ID: <51ECF28D.4020107@redhat.com> On 07/12/2013 05:32 PM, Alexander Bokovoy wrote: > On Fri, 12 Jul 2013, Ana Krivokapic wrote: >> Hello, >> >> This patch fixes https://fedorahosted.org/freeipa/ticket/3781 > ACK. > Pushed to master: 8a8a9045b92547ee5536c156926affe0d32de96c -- Petr? From pspacek at redhat.com Mon Jul 22 11:23:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Jul 2013 13:23:02 +0200 Subject: [Freeipa-devel] [PATCH 0180] Remove support for zone_refresh mode and options cache_ttl and psearch Message-ID: <51ED1616.20501@redhat.com> Hello, Remove support for zone_refresh mode and options cache_ttl and psearch. All three options are ignored and persistent search is always enabled. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0180-Remove-support-for-zone_refresh-mode-and-options-cac.patch Type: text/x-patch Size: 29590 bytes Desc: not available URL: From pspacek at redhat.com Mon Jul 22 11:23:51 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Jul 2013 13:23:51 +0200 Subject: [Freeipa-devel] [PATCH 0181] Replace LDAP persistent search with syncrepl (RFC 4533) Message-ID: <51ED1647.5020805@redhat.com> Hello, Replace LDAP persistent search with syncrepl (RFC 4533). All direct operations with LDAP Persistent Search control are replaced by ldap_sync_* calls. Syncrepl code works in exactly same way as old psearch code: Only the DN of the modified object is re-used from the message, data from the object are fetched via separate LDAP search. Current code is not able to detect object renaming because we don't have UUID->DN mapping yet. Another limitation is that current code can't detect unchanged entries, so serial is incremented after each parsed LDAP object. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0181-Replace-LDAP-persistent-search-with-syncrepl-RFC-453.patch Type: text/x-patch Size: 27184 bytes Desc: not available URL: From tbabej at redhat.com Mon Jul 22 12:31:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 22 Jul 2013 08:31:46 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <20130719161850.GD18587@redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> <20130719161850.GD18587@redhat.com> Message-ID: <1268663087.2035674.1374496306141.JavaMail.root@redhat.com> ----- Original Message ----- From: "Alexander Bokovoy" To: "Tomas Babej" Cc: freeipa-devel at redhat.com Sent: Friday, July 19, 2013 6:18:50 PM Subject: Re: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range On Fri, 19 Jul 2013, Tomas Babej wrote: >On Friday 19 of July 2013 12:32:04 Tomas Babej wrote: >> Hi, >> >> I still need to test this with AD 2008. Sending so that code can get some review before that. >> >> https://fedorahosted.org/freeipa/ticket/3649 >> >> Tomas > >This version fixes few small build nitpicks. ACK, works fine for me. It requires my patches 0109-0110. Yes. This revision also respects enforcement of ipa-ad-trust range type despite the fact that AD has UNIX support configured. Also surpressed the warning messages from AD searches in search_in_dc method when probing for the range information, since first one-two queries usually fail (expected) and leave warning messages in the log. Tomas -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0076-3-Use-AD-LDAP-probing-to-create-trusted-domain-ID-rang.patch Type: text/x-patch Size: 19687 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jul 22 12:38:20 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Jul 2013 14:38:20 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51E9AD6A.80104@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> Message-ID: <51ED27BC.2030005@redhat.com> On 07/19/2013 11:19 PM, Dmitri Pal wrote: > On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>> Disclaimer: I have no strong feelings in this matter, it just looks >>> weird to me, so I'm OK with not doing it if it's general consensus. >>> Originally we wanted to do this change in >>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>> because of string freeze. >>> >>> I guess you can add field suffix to every field from /etc/password >>> when you use it in a sentence but that doesn't necessary mean that >> You can. But gid exists as a concept beyond /etc/passwd. So does home >> directory. The GECOS field value does not, really. >> >>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>> in fields description/list either. IMO our use case is the same. >> It says: >> >> GECOS This field (sometimes called the "comment field") >> [...] >> The gcos field in the password file was >> [...] >> >>> Historically correct label would probably be 'GECOS identity' but >>> that's not usable today as it's purpose is more general. > Do we have tips in the UI? > May be we should add them in future to provide extra information about > meaning of the field or button. We do, but UX is not the best. 'doc' defined in .py files is displayed as a textbox tooltip. This feature is not apparent and for most of the fields the tooltip is the same as label. There is an idea to display a question mark icon next to textboxes to draw an attention to a presence of the doc text and provide it in a tooltip. I like the way how it's done in Alchemy UI: http://www.ui-alchemy.org/form You can notice there an additional information (string length limitation, example...) when field is focused. I went through open tickets and found few which touches the topic: - https://fedorahosted.org/freeipa/ticket/2912 [RFE] [Web UI] Use doc as field's tooltip instead of label * Seems to be already implemented. - https://fedorahosted.org/freeipa/ticket/2413 [RFE]: add in UI examples of what is the requested field - https://fedorahosted.org/freeipa/ticket/3661 [RFE] IPA Web UI: When adding new reverse zone in DNS there could be an example of expected address format * Looks like duplicate of #2413 IMO we should close #2413 and maybe #2912 or change #2912 to cover the above mentioned proposals (in case of agreement). > For now I think GECOS would probably be good enough. > Adding "field" makes it more precise but looks weird. > -- Petr Vobornik From aly.khimji at gmail.com Sat Jul 20 03:51:02 2013 From: aly.khimji at gmail.com (Aly Khimji) Date: Fri, 19 Jul 2013 23:51:02 -0400 Subject: [Freeipa-devel] [Freeipa-users] FreeIPA AD Trust improvements, Fedora 19 Test Day, July 25th In-Reply-To: <51E9B5FF.7020306@redhat.com> References: <51E9B5FF.7020306@redhat.com> Message-ID: Wow.. These sound like some amazing additions and enhancements, great work! keep up the good job guys! Aly On Jul 19, 2013 5:57 PM, "Dmitri Pal" wrote: > Hello, > > The FreeIPA team is happy to welcome you to a Fedora Test Day that is > being held on Thursday, July 25th. > > We would like to invite you to take part in testing of the upcoming > FreeIPA 3.3 > release containing 2 major improvements for easier deployment of FreeIPA > Active > Directory Trust feature to existing environments: > > 1) Use POSIX attributes defined in Active Directory [1] > > With previous FreeIPA releases, users coming from Active Directory to > FreeIPA > managed machines were always assigned POSIX attributes (UID and GID) by > algorithmic mapping. > > However, in some deployments, Active Directory users and groups already > have > defined custom POSIX attribute values (UID and GID), which may then be > leveraged on Linux machines via other 3rd party Active Directory > integration > solutions. Administrator may choose to keep the values to not disrupt file > ownerships. > > With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use > these > attributes when Active Directory user authenticates to Linux machines. > > > 2) Expose POSIX data on legacy systems without recent SSSD > > Administrators may have a deployment of machines which cannot use the > recent > SSSD with Active Directory Trust support but would still like to be able to > authenticate with Active Directory user to these machines. This may affect > for > example older Linux machines, UNIX machines. > > With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree > which > will contain identities of the Active Directory users to the legacy > systems. > These systems may then leverage standard LDAP authentication in this tree > allowing selected Active Directory users to authenticate. > > > To read more about the Test Day and suggested tests, see the following > link: > > > https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients > > Thank you for your help and participation! > > The FreeIPA team > > [1] http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD > [2] http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > [IdM | IPA] FAQs: https://url.corp.redhat.com/idm-faq > Identity Management SME Team on Docspace > https://url.corp.redhat.com/sme-idm > Search the archives: post-office.corp.redhat.com/mailman/listinfo/idm-tech > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Jul 22 13:16:01 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Jul 2013 15:16:01 +0200 Subject: [Freeipa-devel] [PATCH 0181] Replace LDAP persistent search with syncrepl (RFC 4533) In-Reply-To: <51ED1647.5020805@redhat.com> References: <51ED1647.5020805@redhat.com> Message-ID: <51ED3091.8050003@redhat.com> On 22.7.2013 13:23, Petr Spacek wrote: > Hello, > > Replace LDAP persistent search with syncrepl (RFC 4533). > > All direct operations with LDAP Persistent Search control are replaced > by ldap_sync_* calls. > > Syncrepl code works in exactly same way as old psearch code: > Only the DN of the modified object is re-used from the message, > data from the object are fetched via separate LDAP search. > > Current code is not able to detect object renaming because we don't have > UUID->DN mapping yet. > > Another limitation is that current code can't detect unchanged entries, > so serial is incremented after each parsed LDAP object. Clang noticed potential NULL dereference in cleanup section of ldap_syncrepl_watcher(). Fixed patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0181-2-Replace-LDAP-persistent-search-with-syncrepl-RFC-453.patch Type: text/x-patch Size: 27205 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 22 13:19:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Jul 2013 16:19:38 +0300 Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <1268663087.2035674.1374496306141.JavaMail.root@redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> <20130719161850.GD18587@redhat.com> <1268663087.2035674.1374496306141.JavaMail.root@redhat.com> Message-ID: <20130722131938.GB15859@redhat.com> On Mon, 22 Jul 2013, Tomas Babej wrote: > > >----- Original Message ----- >From: "Alexander Bokovoy" >To: "Tomas Babej" >Cc: freeipa-devel at redhat.com >Sent: Friday, July 19, 2013 6:18:50 PM >Subject: Re: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range > >On Fri, 19 Jul 2013, Tomas Babej wrote: >>On Friday 19 of July 2013 12:32:04 Tomas Babej wrote: >>> Hi, >>> >>> I still need to test this with AD 2008. Sending so that code can get some review before that. >>> >>> https://fedorahosted.org/freeipa/ticket/3649 >>> >>> Tomas >> >>This version fixes few small build nitpicks. >ACK, works fine for me. It requires my patches 0109-0110. > >Yes. This revision also respects enforcement of ipa-ad-trust range type despite the fact that >AD has UNIX support configured. > >Also surpressed the warning messages from AD searches in search_in_dc method when probing >for the range information, since first one-two queries usually fail (expected) and leave >warning messages in the log. ACK again. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 22 13:24:40 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Jul 2013 16:24:40 +0300 Subject: [Freeipa-devel] [PATCH] 0111 ipaserver/dcerpc: attempt to resolve SIDs through SSSD first Message-ID: <20130722132440.GC15859@redhat.com> Hi, with my patches 0109-0110, Tomas patch 0076, and my patch to SSSD to provide pysss.getgrouplist() API, it is now possible to prefer resolving SIDs through SSSD before we go and hit AD LDAP. This should help with both caching and allowing more regular admins to set up mapping of AD users and test HBAC rules with them. You would need SSSD git master (758ce3f01b4ed73c3bc35cd7039fac26fdf16386 or later) in order to test this patch. I'm not adding version increase for SSSD dependency because the change to SSSD is anyway will be in 1.11. -- / Alexander Bokovoy -------------- next part -------------- >From 106d51ef0474f71dc8af701986bbcb9c5adf0b63 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 19 Jul 2013 17:04:14 +0300 Subject: [PATCH 4/4] ipaserver/dcerpc: attempt to resolve SIDs through SSSD first Attempt to resolve SIDs through SSSD first to avoid using trust account password. This makes possible to run HBAC test requests without being in 'trusted admins' group. https://fedorahosted.org/freeipa/ticket/3803 --- ipalib/plugins/hbactest.py | 9 +++------ ipaserver/dcerpc.py | 45 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 47 insertions(+), 7 deletions(-) diff --git a/ipalib/plugins/hbactest.py b/ipalib/plugins/hbactest.py index 9cc497c..fed39b0 100644 --- a/ipalib/plugins/hbactest.py +++ b/ipalib/plugins/hbactest.py @@ -400,17 +400,14 @@ class hbactest(Command): ldap = self.api.Backend.ldap2 group_container = DN(api.env.container_group, api.env.basedn) try: - entries, truncated = ldap.find_entries(filter_sids, ['cn', 'memberOf'], group_container) + entries, truncated = ldap.find_entries(filter_sids, ['cn'], group_container) except errors.NotFound: request.user.groups = [] else: groups = [] for dn, entry in entries: - memberof_dns = entry.get('memberof', []) - for memberof_dn in memberof_dns: - if memberof_dn.endswith(group_container): - # this is a group object - groups.append(memberof_dn[0][0].value) + if dn.endswith(group_container): + groups.append(dn[0][0].value) request.user.groups = sorted(set(groups)) else: # try searching for a local user diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 88ad928..4660842 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -53,6 +53,8 @@ from ipapython.ipaldap import IPAdmin from ipalib.session import krbccache_dir, krbccache_prefix from dns import resolver, rdatatype from dns.exception import DNSException +import pysss_nss_idmap +import pysss __doc__ = _(""" Classes to manage trust joins using DCE-RPC calls @@ -312,6 +314,12 @@ class DomainValidator(object): return entries def get_trusted_domain_object_sid(self, object_name): + result = pysss_nss_idmap.getsidbyname(object_name) + if object_name in result and (pysss_nss_idmap.SID_KEY in result[object_name]): + object_sid = result[object_name][pysss_nss_idmap.SID_KEY] + return object_sid + + # Else, we are going to contact AD DC LDAP components = normalize_name(object_name) if not ('domain' in components or 'flatname' in components): # No domain or realm specified, ambiguous search @@ -337,7 +345,7 @@ class DomainValidator(object): raise errors.ValidationError(name=_('trusted domain object'), error= _('Trusted domain did not return a valid SID for the object')) - def get_trusted_domain_user_and_groups(self, object_name): + def __get_trusted_domain_user_and_groups(self, object_name): """ Returns a tuple with user SID and a list of SIDs of all groups he is a member of. @@ -393,6 +401,41 @@ class DomainValidator(object): group_sids = [self.__sid_to_str(sid) for sid in entries[0][1]['tokenGroups']] return (object_sid, group_sids) + def get_trusted_domain_user_and_groups(self, object_name): + """ + Returns a tuple with user SID and a list of SIDs of all groups he is + a member of. + + First attempts to perform SID lookup via SSSD and in case of failure + resorts back to checking trusted domain's AD DC LDAP directly. + + LIMITATIONS: + - only Trusted Admins group members can use this function as it + uses secret for IPA-Trusted domain link if SSSD lookup failed + - List of group SIDs does not contain group memberships outside + of the trusted domain + """ + group_sids = None + group_list = None + object_sid = None + is_valid_sid = is_sid_valid(object_name) + if is_valid_sid: + object_sid = object_name + result = pysss_nss_idmap.getnamebysid(object_name) + if object_name in result and (pysss_nss_idmap.NAME_KEY in result[object_name]): + group_list = pysss.getgrouplist(result[object_name][pysss_nss_idmap.NAME_KEY]) + else: + result = pysss_nss_idmap.getsidbyname(object_name) + if object_name in result and (pysss_nss_idmap.SID_KEY in result[object_name]): + object_sid = result[object_name][pysss_nss_idmap.SID_KEY] + group_list = pysss.getgrouplist(object_name) + + if not group_list: + return self.__get_trusted_domain_user_and_groups(object_name) + + group_sids = pysss_nss_idmap.getsidbyname(group_list) + return (object_sid, [el[1][pysss_nss_idmap.SID_KEY] for el in group_sids.items()]) + def __sid_to_str(self, sid): """ Converts binary SID to string representation -- 1.8.3.1 From akrivoka at redhat.com Mon Jul 22 14:46:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Jul 2013 16:46:35 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51E79D84.7010304@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> Message-ID: <51ED45CB.7080604@redhat.com> On 07/18/2013 09:47 AM, Petr Vobornik wrote: > On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >> > > Hello, > > 1) IMO we should not create attribute which is just a negation of another. > > 2) We should add set_enabled method to base widget. Existing set_enabled > methods should use it and maintain widget output consistent with the attribute > (ie. one should not directly set the attr and should use set_enabled instead). > The method should be also callable when content is not yet created. > get_enabled methods might become unnecessary - one can get the state form > 'enabled' attribute. > The attached updated patch implements the following changes: 1) set_enabled method has been added to the base widget class. 2) get_enabled/is_enabled methods have been removed. 3) Widget classes that inherit from the base widget class override the set_enabled method where necessary. 4) Using 'enabled: true/false' in the widget definition should now work correctly for all types of widgets. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0047-02-Honor-enabled-option-for-widgets.patch Type: text/x-patch Size: 11305 bytes Desc: not available URL: From akrivoka at redhat.com Mon Jul 22 15:19:25 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Jul 2013 17:19:25 +0200 Subject: [Freeipa-devel] [PATCH] 430 Break long words in notification area In-Reply-To: <51E7CA4A.7000408@redhat.com> References: <51E7CA4A.7000408@redhat.com> Message-ID: <51ED4D7D.7060708@redhat.com> On 07/18/2013 12:58 PM, Petr Vobornik wrote: > Long words (ie. service principal) breaks out of notification area. It doesn't > look good. Patch adds word-wrap to break them to multiple pieces. > > Reproduction: modify a service in Web UI > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Mon Jul 22 15:33:13 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Jul 2013 17:33:13 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51ECD8D6.30400@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ECD8D6.30400@redhat.com> Message-ID: <51ED50B9.4070101@redhat.com> On 07/22/2013 09:01 AM, Martin Kosek wrote: > On 07/19/2013 11:19 PM, Dmitri Pal wrote: >> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>> Originally we wanted to do this change in >>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>> because of string freeze. >>>> >>>> I guess you can add field suffix to every field from /etc/password >>>> when you use it in a sentence but that doesn't necessary mean that >>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>> directory. The GECOS field value does not, really. >>> >>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>> in fields description/list either. IMO our use case is the same. >>> It says: >>> >>> GECOS This field (sometimes called the "comment field") >>> [...] >>> The gcos field in the password file was >>> [...] >>> >>>> Historically correct label would probably be 'GECOS identity' but >>>> that's not usable today as it's purpose is more general. >> Do we have tips in the UI? >> May be we should add them in future to provide extra information about >> meaning of the field or button. >> For now I think GECOS would probably be good enough. >> Adding "field" makes it more precise but looks weird. > +1 for just "GECOS". Petr showed me both variants in the UI and "GECOS field" > really looked weird. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel +1 for removing the word 'field'. The phrase 'GECOS field' also exists in the following files: install/ui/test/data/ipa_init_commands.json install/ui/test/data/ipa_init_objects.json install/ui/test/data/json_metadata.json So it should be fixed there as well. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From jcholast at redhat.com Mon Jul 22 15:36:22 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Jul 2013 17:36:22 +0200 Subject: [Freeipa-devel] [PATCH] 161 Use configured dogtag LDAP port instead of default one when renewing certs Message-ID: <51ED5176.4060605@redhat.com> Hi, the attached patch should fix . I haven't actually tested the patch, as I didn't manage to successfully install old Fedora with FreeIPA which uses separate DS instances and upgrade that to Fedora 19. Simo, you opened the ticket, would you mind testing the patch? It should be sufficient to resubmit certmonger requests which use renew_ca_cert and renew_ra_cert and see if it works. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-161-Use-configured-dogtag-LDAP-port-instead-of-default-o.patch Type: text/x-patch Size: 3153 bytes Desc: not available URL: From simo at redhat.com Mon Jul 22 15:40:56 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Jul 2013 11:40:56 -0400 Subject: [Freeipa-devel] [PATCH] 161 Use configured dogtag LDAP port instead of default one when renewing certs In-Reply-To: <51ED5176.4060605@redhat.com> References: <51ED5176.4060605@redhat.com> Message-ID: <1374507656.32040.268.camel@willson.li.ssimo.org> On Mon, 2013-07-22 at 17:36 +0200, Jan Cholasta wrote: > if nickname == 'subsystemCert cert-pki-ca': > - update_people_entry('pkidbuser', cert) > + update_people_entry(dogtag_uri, 'pkidbuser', cert) > > This is probably wrong, there is no pkidbuser in old instances. My subsystemCert has a subject of "CN=CA Subsystem,O=REALM" and this cert is associated to an object named: uid=CA--9443,ou=people,o=ipaca I think you need to search the db to find the right object(s) to update. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Jul 22 18:14:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Jul 2013 14:14:39 -0400 Subject: [Freeipa-devel] Proposal to have spec changes as a separate patch In-Reply-To: <51E7DE8D.2020402@redhat.com> References: <51E3F3FB.5060600@redhat.com> <20130718075747.GQ18587@redhat.com> <20130718081045.GR18587@redhat.com> <51E7BE94.6020902@redhat.com> <20130718120111.GT18587@redhat.com> <51E7DE8D.2020402@redhat.com> Message-ID: <51ED768F.4080304@redhat.com> Martin Kosek wrote: > On 07/18/2013 02:01 PM, Alexander Bokovoy wrote: >> On Thu, 18 Jul 2013, Petr Viktorin wrote: >>> On 07/18/2013 10:10 AM, Alexander Bokovoy wrote: >>>> On Thu, 18 Jul 2013, Alexander Bokovoy wrote: >>>>> On Mon, 15 Jul 2013, Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> This patch addresses ticket >>>>>> https://fedorahosted.org/freeipa/ticket/3652. >>>>> Could you please rebase it on top of git master? >>>> BTW, I was thinking on it and given that majority of rebases like this >>>> one come due to spec changes, may be we could establishe a practice to >>>> send spec-related changes as a separate patch in a patchset? >>>> >>>> This would allow easily testing the actual code changes since you don't >>>> really need spec changes at that point or could handle it clearer with >>>> pre-installed build dependencies. >>>> >>>> >>> >>> Or you could just set the union merge strategy on the spec file. >>> This is potentially dangerous so only do it if for pushing to master you >>> apply patches in a separate "clean" repository without this setting. >>> >>> Add the following line to .git/info/gitattributes: >>> freeipa.spec.in merge=union >>> >>> Docs & caveats: >>> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers >>> >> I would still prefer to have the changes in separate patches in a >> patchset simply because it makes clearer and easier to handle in active >> development. > > Hmm, I am personally not convinced - when I just update one Requires, splitting > it to 2 patches seems as an overkill to me... > >> >> When we push commits to the main git tree, we anyway push whole patchset >> as one push operation. As result, anyone who pulls that tree, will get >> consistent patchset -- be it another developer or continuous integration >> machinery. For developers who touch spec files reduced context of the >> changes in a pulled tree will also be helpful. >> >> Besides that, you anyway will need to do manual adoption after >> merge=union in order to get changelog entries in proper chronological >> order and release numbering. > > I am still not sure about the gain of this - unless people provide special > patch with comment for all affected branches, I will have to merge the doc > change manually (+ give higher maintenance effort by splitting the patches again). > > To sum it up, I would not personally make this a strict rule unless we find > that current patches with spec comment included are unbearable (so far, they > were not unbearable for me...). It's almost always the changelog that conflicts. Given the relative rarity of this dealing with a few rebases a year doesn't seem like a big deal to me. The alternative is to not update the changelog, but I find it handy to look there sometimes. The data is all in git in any case. rob From dpal at redhat.com Mon Jul 22 23:31:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Jul 2013 19:31:44 -0400 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51ED27BC.2030005@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ED27BC.2030005@redhat.com> Message-ID: <51EDC0E0.1050602@redhat.com> On 07/22/2013 08:38 AM, Petr Vobornik wrote: > On 07/19/2013 11:19 PM, Dmitri Pal wrote: >> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>> Originally we wanted to do this change in >>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>> because of string freeze. >>>> >>>> I guess you can add field suffix to every field from /etc/password >>>> when you use it in a sentence but that doesn't necessary mean that >>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>> directory. The GECOS field value does not, really. >>> >>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>> in fields description/list either. IMO our use case is the same. >>> It says: >>> >>> GECOS This field (sometimes called the "comment field") >>> [...] >>> The gcos field in the password file was >>> [...] >>> >>>> Historically correct label would probably be 'GECOS identity' but >>>> that's not usable today as it's purpose is more general. > >> Do we have tips in the UI? > > May be we should add them in future to provide extra information about > > meaning of the field or button. > > We do, but UX is not the best. 'doc' defined in .py files is displayed > as a textbox tooltip. This feature is not apparent and for most of the > fields the tooltip is the same as label. > > There is an idea to display a question mark icon next to textboxes to > draw an attention to a presence of the doc text and provide it in a > tooltip. > > I like the way how it's done in Alchemy UI: > http://www.ui-alchemy.org/form You can notice there an additional > information (string length limitation, example...) when field is focused. > > I went through open tickets and found few which touches the topic: > - https://fedorahosted.org/freeipa/ticket/2912 [RFE] [Web UI] Use doc > as field's tooltip instead of label > * Seems to be already implemented. > - https://fedorahosted.org/freeipa/ticket/2413 [RFE]: add in UI > examples of what is the requested field > - https://fedorahosted.org/freeipa/ticket/3661 [RFE] IPA Web UI: When > adding new reverse zone in DNS there could be an example of expected > address format > * Looks like duplicate of #2413 > > IMO we should close #2413 and maybe #2912 or change #2912 to cover the > above mentioned proposals (in case of agreement). > >> For now I think GECOS would probably be good enough. >> Adding "field" makes it more precise but looks weird. >> > > Sounds reasonable. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nalin at redhat.com Tue Jul 23 06:46:34 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 23 Jul 2013 02:46:34 -0400 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130715173003.GF18587@redhat.com> References: <20130715173003.GF18587@redhat.com> Message-ID: <20130723064634.GA20085@redhat.com> Apologies for the delay. On Mon, Jul 15, 2013 at 08:30:03PM +0300, Alexander Bokovoy wrote: > Here is the logic: > > 0. Configuration is performed by setting > > schema-compat-lookup-sssd: > schema-compat-sssd-min-id: > > in corresponding schema-compat plugin tree (cn=users and cn=groups). > > If schema-compat-sssd-min-id is not set, it will default to 1000. It is > used to filter out attempts to fetch system users (<1000 on Fedora by > default). > > 1. On query, we parse query filter to identify what type of request is > this: user or group lookup and then issue getpwnam_r()/getgrnam_r() and > getsidbyid() for libsss_nss_idmap to fetch all needed information. > > SSSD caches these requests they should be relatively fast. > > 2. Once we served the request, it is cached in schema-compat cache map. > The entry in the cache is currently not expired explicitly but I'm > working on expiring it on wrong authentication -- if PAM stack returns a > response telling there is no such user. > > 3. Authentication bind for cached entries is done via PAM service > 'system-auth'. If HBAC rule 'allow_all' is disabled in FreeIPA, one > needs to create a rule with service 'system-auth' and allow all users to > access it on IPA masters. Since system-auth is never used explicitly by > any application (it is always included through PAM stack and only > top-level PAM service is used to drive the HBAC ruleset), there is no > problem. > > PAM authentication code is taken from pam_passthru DS plugin. We cannot > use it unchanged because pam_passthru expects that LDAP entry will exist > in DS, while it is not true for these synthetic entries representing > trusted domain users. > > On Fedora one needs pam-devel and libsss_nss_idmap-devel to build the > plugin with new functionality. The bits about how to configure this facility need to be in the documentation somewhere. Right now there is none being added, and no new self-tests. > diff --git a/configure.ac b/configure.ac > index 8d7cbe1..4a47d36 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) > AC_SUBST(ASYNCNS_LIBS) > fi > > +AC_ARG_WITH(sss_nss_idmap, > + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), > + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) > +if pkg-config sss_nss_idmap 2> /dev/null ; then > + if test x$use_sss_nss_idmap != xno ; then > + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) > + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > + else > + SSS_NSS_IDMAP_CFLAGS= > + SSS_NSS_IDMAP_LIBS= > + fi > +else > + if test $use_sss_idmap = yes ; then Should this reference to $use_sss_idmap be referring to $use_sss_nss_idmap instead? > + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) > + else > + SSS_NSS_IDMAP_CFLAGS= > + SSS_NSS_IDMAP_LIBS= > + fi > +fi > +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) I suspect this'll need to quote SSS_NSS_IDMAP_LIBS here, in case its value ever starts to include whitespace. > +if x$SSS_NSS_IDMAP_LIBS != x ; then Likewise here. > + AC_CHECK_HEADERS(pam.h) > + if test x$ac_cv_header_pam_h = xno ; then > + use_pam=yes > + else > + use_pam=no > + fi > + > + if test $use_pam = yes ; then > + PAM_CFLAGS= > + PAM_LIBS=-lpam > + else > + AC_ERROR([ not found and it is required for SSSD mode]) > + fi > + AC_SUBST(PAM_CFLAGS) > + AC_SUBST(PAM_LIBS) > +fi Jakub already noted that this should be checking for . > @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", > attrattr=schema-compat-entry-attribute > AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", > [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) > +sssdattr=schema-compat-lookup-sssd > +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", > + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) Is this a boolean attribute? > diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c > new file mode 100644 > index 0000000..3266261 > --- /dev/null > +++ b/src/back-sch-pam.c > @@ -0,0 +1,361 @@ > +/** BEGIN COPYRIGHT BLOCK > + * 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 the Free Software > + * Foundation; version 2 of the License. > + * > + * This Program is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS > + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along with > + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple > + * Place, Suite 330, Boston, MA 02111-1307 USA. > + * > + * In addition, as a special exception, Red Hat, Inc. gives You the additional > + * right to link the code of this Program with code not covered under the GNU > + * General Public License ("Non-GPL Code") and to distribute linked combinations > + * including the two, subject to the limitations in this paragraph. Non-GPL Code > + * permitted under this exception must only link to the code of this Program > + * through those well defined interfaces identified in the file named EXCEPTION > + * found in the source code files (the "Approved Interfaces"). The files of > + * Non-GPL Code may instantiate templates or use macros or inline functions from > + * the Approved Interfaces without causing the resulting work to be covered by > + * the GNU General Public License. Only Red Hat, Inc. may make changes or > + * additions to the list of Approved Interfaces. You must obey the GNU General > + * Public License in all respects for all of the Program code and other code used > + * in conjunction with the Program except the Non-GPL Code covered by this > + * exception. If you modify this file, you may extend this exception to your > + * version of the file, but you are not obligated to do so. If you do not wish to > + * provide this exception without modification, you must delete this exception > + * statement from your version and license this file solely under the GPL without > + * exception. > + * > + * > + * Copyright (C) 2005 Red Hat, Inc. > + * All rights reserved. > + * END COPYRIGHT BLOCK **/ Did you mean to use the server's GPLv2+exceptions license for this code? It differs from the rest of the plugin. And that date of 2005 looks kind of odd. > +#ifdef HAVE_CONFIG_H > +#include "config.h" > +#endif > + > +#include > +#include > +#include > +#include > +#include > + > +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H > +#include > +#include > +#include > +#else > +#include > +#endif > + > + > +#include > + > +/* > + * PAM is not thread safe. We have to execute any PAM API calls in > + * a critical section. This is the lock that protects that code. > + */ > +static Slapi_Mutex *PAMLock = NULL; Right now this mutex is being initialized after the server's gone and launched multiple threads, which if timed right could go badly. Move the pointer into the plugin_state structure, and initialize it when the rest of the structure's being initialized when the compat plugin starts up. Also, please avoid using caps in variable names and use underscores, like the rest of the plugin does. > +/* Utility struct to wrap strings to avoid mallocs if possible - use > + stack allocated string space */ > +#define MY_STATIC_BUF_SIZE 256 > +typedef struct my_str_buf { > + char fixbuf[MY_STATIC_BUF_SIZE]; > + char *str; > +} MyStrBuf; > + > +static char * > +init_my_str_buf(MyStrBuf *buf, const char *s) > +{ > + PR_ASSERT(buf); > + if (s && (strlen(s) < sizeof(buf->fixbuf))) { > + strcpy(buf->fixbuf, s); > + buf->str = buf->fixbuf; > + } else { > + buf->str = slapi_ch_strdup(s); > + buf->fixbuf[0] = 0; > + } > + > + return buf->str; > +} > + > +static void > +delete_my_str_buf(MyStrBuf *buf) > +{ > + if (buf->str != buf->fixbuf) { > + slapi_ch_free_string(&(buf->str)); > + } > +} This seems unnecessary. > +/* for third arg to pam_start */ > +struct my_pam_conv_str { > + Slapi_PBlock *pb; > + char *pam_identity; > +}; > + > +/* returns a berval value as a null terminated string */ > +static char *strdupbv(struct berval *bv) > +{ > + char *str = slapi_ch_malloc(bv->bv_len+1); > + memcpy(str, bv->bv_val, bv->bv_len); > + str[bv->bv_len] = 0; > + return str; > +} Please reformat this so that the function name is in the first column, to make it easier to find with a trivial grep ^$functionname. Also applies to do_pam_auth() below. In non-error cases, this new string is going to be freed by free(). Please avoid allocating memory with slapi_ch_malloc() if it'll be freed with free(), or allocating with malloc()/calloc()/strdup() if it'll be freed with slapi_ch_free(). > +static void > +free_pam_response(int nresp, struct pam_response *resp) > +{ > + int ii; > + for (ii = 0; ii < nresp; ++ii) { > + if (resp[ii].resp) { > + slapi_ch_free((void **)&(resp[ii].resp)); > + } > + } > + slapi_ch_free((void **)&resp); > +} In non-error cases, these pointers would be freed by a plugin calling free(). Please avoid mixing calls to slapi_ch_malloc() and slapi_ch_free() with malloc()/free()/strdup(). > +/* > + * This is the conversation function passed into pam_start(). This is what sets the password > + * that PAM uses to authenticate. This function is sort of stupid - it assumes all echo off > + * or binary prompts are for the password, and other prompts are for the username. Time will > + * tell if this is actually the case. > + */ > +static int > +pam_conv_func(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *mydata) > +{ > + int ii; > + struct berval *creds; > + struct my_pam_conv_str *my_data = (struct my_pam_conv_str *)mydata; > + struct pam_response *reply; > + int ret = PAM_SUCCESS; > + > + if (num_msg <= 0) { > + return PAM_CONV_ERR; > + } > + > + /* empty reply structure */ > + reply = (struct pam_response *)slapi_ch_calloc(num_msg, > + sizeof(struct pam_response)); > + slapi_pblock_get( my_data->pb, SLAPI_BIND_CREDENTIALS, &creds ); /* the password */ > + for (ii = 0; ii < num_msg; ++ii) { > + /* hard to tell what prompt is for . . . */ > + /* assume prompts for password are either BINARY or ECHO_OFF */ > + if (msg[ii]->msg_style == PAM_PROMPT_ECHO_OFF) { > + reply[ii].resp = strdupbv(creds); > +#ifdef LINUX > + } else if (msg[ii]->msg_style == PAM_BINARY_PROMPT) { > + reply[ii].resp = strdupbv(creds); > +#endif > + } else if (msg[ii]->msg_style == PAM_PROMPT_ECHO_ON) { /* assume username */ > + reply[ii].resp = slapi_ch_strdup(my_data->pam_identity); > + } else if (msg[ii]->msg_style == PAM_ERROR_MSG) { > + } else if (msg[ii]->msg_style == PAM_TEXT_INFO) { > + } else { > + ret = PAM_CONV_ERR; > + } Replace this with a switch{} construction. > + } > + > + if (ret == PAM_CONV_ERR) { > + free_pam_response(num_msg, reply); > + reply = NULL; > + } > + > + *resp = reply; > + > + return ret; > +} You're mixing hard tabs and spaces for indentation here. > +/* > + * Do the actual work of authenticating with PAM. First, get the PAM identity > + * based on the method used to convert the BIND identity to the PAM identity. > + * Set up the structures that pam_start needs and call pam_start(). After > + * that, call pam_authenticate and pam_acct_mgmt. Check the various return > + * values from these functions and map them to their corresponding LDAP BIND > + * return values. Return the appropriate LDAP error code. > + * This function will also set the appropriate LDAP response controls in > + * the given pblock. > + * Since this function can be called multiple times, we only want to return > + * the errors and controls to the user if this is the final call, so the > + * final_method parameter tells us if this is the last one. Coupled with > + * the fallback argument, we can tell if we are able to send the response > + * back to the client. > + */ There aren't parameters named final_method or fallback in the function signature. Please update the comment to better describe the current implementation. > +static int > +do_pam_auth( > + Slapi_PBlock *pb, > + char *pam_service, /* name of service for pam_start() */ > + int pw_response_requested, /* do we need to send pwd policy resp control */ > + Slapi_Entry *entry > +) Fix the formatting for this to match the rest of the plugin, please. > +{ > + MyStrBuf pam_id; > + const char *binddn = NULL; > + Slapi_DN *bindsdn = NULL; > + int rc = PAM_SUCCESS; > + int retcode = LDAP_SUCCESS; > + pam_handle_t *pam_handle; > + struct my_pam_conv_str my_data; > + struct pam_conv my_pam_conv = {pam_conv_func, NULL}; > + char *errmsg = NULL; /* free with PR_smprintf_free */ > + > + slapi_pblock_get( pb, SLAPI_BIND_TARGET_SDN, &bindsdn ); > + if (NULL == bindsdn) { > + errmsg = PR_smprintf("Null bind dn"); > + retcode = LDAP_OPERATIONS_ERROR; > + pam_id.str = NULL; /* initialize pam_id.str */ > + goto done; /* skip the pam stuff */ > + } > + binddn = slapi_sdn_get_dn(bindsdn); > + > + char *val = slapi_entry_attr_get_charptr(entry, "uid"); > + init_my_str_buf(&pam_id, val); > + slapi_ch_free_string(&val); Move the declaration of val to the beginning of the function. Also, if we already have a non-const copy of the uid value, there's no need to bother with the second one -- just use val directly. > + if (!pam_id.str) { > + errmsg = PR_smprintf("Bind DN [%s] is invalid or not found", binddn); > + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ > + goto done; /* skip the pam stuff */ > + } > + > + /* do the pam stuff */ > + my_data.pb = pb; > + my_data.pam_identity = pam_id.str; > + my_pam_conv.appdata_ptr = &my_data; > + slapi_lock_mutex(PAMLock); > + /* from this point on we are in the critical section */ > + rc = pam_start(pam_service, pam_id.str, &my_pam_conv, &pam_handle); > + > + if (rc == PAM_SUCCESS) { > + /* use PAM_SILENT - there is no user interaction at this point */ > + rc = pam_authenticate(pam_handle, 0); Should this call to pam_authenticate be specifying PAM_SILENT or not? > + /* check different types of errors here */ > + if (rc == PAM_USER_UNKNOWN) { > + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", > + pam_id.str, binddn); > + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ > + } else if (rc == PAM_AUTH_ERR) { > + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", > + pam_id.str, binddn); > + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ > + } else if (rc == PAM_MAXTRIES) { > + errmsg = PR_smprintf("Authentication retry limit exceeded in PAM for " > + "user id [%s], bind DN [%s]", > + pam_id.str, binddn); > + if (pw_response_requested) { > + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); > + } > + retcode = LDAP_CONSTRAINT_VIOLATION; /* max retries */ > + } else if (rc != PAM_SUCCESS) { > + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", > + pam_strerror(pam_handle, rc), pam_id.str, binddn); > + retcode = LDAP_OPERATIONS_ERROR; /* pam config or network problem */ > + } Replace this with a switch{} construction. > + } > + > + /* if user authenticated successfully, see if there is anything we need > + to report back w.r.t. password or account lockout */ > + if (rc == PAM_SUCCESS) { > + rc = pam_acct_mgmt(pam_handle, 0); > + /* check different types of errors here */ > + if (rc == PAM_USER_UNKNOWN) { > + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", > + pam_id.str, binddn); > + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ > + } else if (rc == PAM_AUTH_ERR) { > + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", > + pam_id.str, binddn); > + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ > + } else if (rc == PAM_PERM_DENIED) { > + errmsg = PR_smprintf("Access denied for PAM user id [%s], bind DN [%s]" > + " - see administrator", > + pam_id.str, binddn); > + if (pw_response_requested) { > + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); > + } > + retcode = LDAP_UNWILLING_TO_PERFORM; > + } else if (rc == PAM_ACCT_EXPIRED) { > + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " > + "reset required", > + pam_id.str, binddn); > + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); > + if (pw_response_requested) { > + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); > + } > + retcode = LDAP_INVALID_CREDENTIALS; > + } else if (rc == PAM_NEW_AUTHTOK_REQD) { /* handled same way as ACCT_EXPIRED */ > + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " > + "reset required", > + pam_id.str, binddn); > + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); > + if (pw_response_requested) { > + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); > + } > + retcode = LDAP_INVALID_CREDENTIALS; > + } else if (rc != PAM_SUCCESS) { > + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", > + pam_strerror(pam_handle, rc), pam_id.str, binddn); > + retcode = LDAP_OPERATIONS_ERROR; /* unknown */ > + } Replace this with a switch{} construction. > + } > + > + rc = pam_end(pam_handle, rc); > + slapi_unlock_mutex(PAMLock); > + /* not in critical section any more */ > + > +done: > + delete_my_str_buf(&pam_id); > + > + if ((retcode == LDAP_SUCCESS) && (rc != PAM_SUCCESS)) { > + errmsg = PR_smprintf("Unknown PAM error [%d] for user id [%s], bind DN [%s]", > + rc, pam_id.str, binddn); > + retcode = LDAP_OPERATIONS_ERROR; > + } > + > + if (retcode != LDAP_SUCCESS) { > + slapi_send_ldap_result(pb, retcode, NULL, errmsg, 0, NULL); > + } > + > + if (errmsg) { > + PR_smprintf_free(errmsg); > + } > + > + return retcode; > +} > + > +/* > + * Entry point into the PAM auth code. Shields the rest of the app > + * from PAM API code. Get our config params, then call the actual > + * code that does the PAM auth. Can call that code up to 3 times, > + * depending on what methods are set in the config. > + */ > +int > +backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry) > +{ > + int rc = LDAP_SUCCESS; > + MyStrBuf pam_service; /* avoid malloc if possible */ > + int pw_response_requested; > + LDAPControl **reqctrls = NULL; > + > + if (!PAMLock && !(PAMLock = slapi_new_mutex())) { > + return LDAP_LOCAL_ERROR; > + } > + > + init_my_str_buf(&pam_service, "system-auth"); > + > + slapi_pblock_get (pb, SLAPI_REQCONTROLS, &reqctrls); > + slapi_pblock_get (pb, SLAPI_PWPOLICY, &pw_response_requested); > + > + /* figure out which method is the last one - we only return error codes, controls > + to the client and send a response on the last method */ This comment doesn't seem to be current. > + rc = do_pam_auth(pb, pam_service.str, pw_response_requested, entry); > + > + delete_my_str_buf(&pam_service); > + > + return rc; > +} reqctrls isn't being used after it's assigned. Unless I'm missing where it is, go ahead and remove it. There's also no need to make a copy of the "system-auth" string when it can be used directly. > diff --git a/src/back-sch-sssd.c b/src/back-sch-sssd.c > new file mode 100644 > index 0000000..8168675 > --- /dev/null > +++ b/src/back-sch-sssd.c > @@ -0,0 +1,335 @@ > +/* > + * Copyright 2008,2009,2010,2011,2012 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 > + * the Free Software Foundation; version 2 of the License. > + * > + * This Program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this Program; if not, write to the > + * > + * Free Software Foundation, Inc. > + * 59 Temple Place, Suite 330 > + * Boston, MA 02111-1307 USA > + * > + */ > + > +#ifdef HAVE_CONFIG_H > +#include "config.h" > +#endif > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H > +#include > +#include > +#include > +#else > +#include > +#endif > + > +#include > +#include > + > +#include "backend.h" > +#include "back-shr.h" > +#include "plugin.h" > +#include "map.h" > +#include "back-sch.h" > + > +struct backend_search_filter_config { > + bool_t search_user; > + bool_t search_group; > + bool_t search_uid; > + bool_t search_gid; > + bool_t name_set; > + char *name; > +}; > + > +/* Check simple filter to see if it has > + * (cn|uid|uidNumber|gidNumber=) or (objectClass=posixGroup) > + * Called by slapi_filter_apply(). */ > +static int > +backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) > +{ > + struct backend_search_filter_config *config = arg; > + struct berval *bval; > + char *filter_type; > + int f_choice, rc; > + > + f_choice = slapi_filter_get_choice(filter); > + rc = slapi_filter_get_ava(filter, &filter_type, &bval); > + if ((LDAP_FILTER_EQUALITY == f_choice) && (0 == rc)) { > + if (0 == strcasecmp(filter_type, "uidNumber")) { > + config->search_uid = TRUE; > + config->name_set = TRUE; > + } else if (0 == strcasecmp(filter_type, "gidNumber")) { > + config->search_gid = TRUE; > + config->name_set = TRUE; > + } else if (0 == strcasecmp(filter_type, "uid")) { > + config->search_user = TRUE; > + config->name_set = TRUE; > + } else if (0 == strcasecmp(filter_type, "cn")) { > + config->name_set = TRUE; > + } else if ((0 == strcasecmp(filter_type, "objectClass")) && > + (0 == strcasecmp(bval->bv_val, "posixGroup"))) { > + config->search_group = TRUE; > + } > + > + if ((NULL == config->name) && config->name_set) { > + config->name = bval->bv_val; Is bval->bv_val guaranteed to be nul-terminated here? > + } > + } > + > + if ((config->search_uid || > + config->search_gid || > + config->search_user || > + config->search_group) && (config->name != NULL)) { > + return SLAPI_FILTER_SCAN_STOP; > + } > + return SLAPI_FILTER_SCAN_CONTINUE; > +} > + > +static Slapi_Entry * > +backend_retrieve_user_entry_from_sssd(char *user_name, bool_t is_uid, > + struct backend_set_data *set_data, > + struct backend_search_cbdata *cbdata) > +{ > + struct passwd pwd, *result; > + Slapi_Entry *entry; > + int rc; > + enum sss_id_type id_type; > + char *sid_str; > + > + if (set_data->sssd_buffer == NULL) { > + return NULL; > + } > + > + if (is_uid) { > + rc = getpwuid_r(atoi(user_name), &pwd, > + set_data->sssd_buffer, > + set_data->sssd_buffer_len, &result); Please check this conversion for errors, and that it produces a value in the range of unsigned int (uid_t is unsigned). Why do the function names all suggest that we're retrieving data from SSSD, when we don't verify that? > + } else { > + rc = getpwnam_r(user_name, &pwd, > + set_data->sssd_buffer, > + set_data->sssd_buffer_len, &result); > + } These need to handle ERANGE errors. > + if ((result == NULL) || (rc != 0)) { > + return NULL; > + } > + > + if (pwd.pw_uid < cbdata->sssd_min_id) { > + return NULL; > + } > + > + entry = slapi_entry_alloc(); > + if (entry == NULL) { > + return NULL; > + } > + > + slapi_entry_add_string(entry, > + "objectClass", "top"); > + slapi_entry_add_string(entry, > + "objectClass", "posixAccount"); > + slapi_entry_add_string(entry, > + "objectClass", "extensibleObject"); > + slapi_entry_add_string(entry, > + "uid", user_name); If is_uid is true, this is a numeric string. Intentional? > + slapi_entry_attr_set_int(entry, > + "uidNumber", pwd.pw_uid); > + slapi_entry_attr_set_int(entry, > + "gidNumber", pwd.pw_gid); > + slapi_entry_add_string(entry, > + "gecos", pwd.pw_gecos); > + if (strlen(pwd.pw_gecos) > 0) { > + slapi_entry_add_string(entry, > + "cn", pwd.pw_gecos); > + } else { > + slapi_entry_add_string(entry, > + "cn", user_name); > + } > + > + slapi_entry_add_string(entry, > + "homeDirectory", pwd.pw_dir); > + slapi_entry_add_string(entry, > + "loginShell", pwd.pw_shell); > + slapi_entry_set_sdn(entry, set_data->container_sdn); > + slapi_entry_set_dn(entry, slapi_ch_smprintf("uid=%s,%s", > + user_name, slapi_sdn_get_dn(set_data->container_sdn))); I don't think that call to slapi_entry_set_sdn() is necessary if we're calling slapi_entry_set_dn() immediately after it. This DN needs to be escaped properly. > + rc = sss_nss_getsidbyid(pwd.pw_uid, &sid_str, &id_type); > + if ((rc == 0) && (sid_str != NULL)) { > + slapi_entry_add_string(entry, "objectClass", "ipaNTUserAttrs"); Either this is unnecessary here, or it needs to start being copied into the entries that we're adding to the cache. > + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); > + free(sid_str); > + } > + > + > + return entry; > +} > + > + > +static Slapi_Entry * > +backend_retrieve_group_entry_from_sssd(char *group_name, bool_t is_gid, > + struct backend_set_data *set_data, > + struct backend_search_cbdata *cbdata) > +{ > + struct group grp, *result; > + const char *sdn; > + Slapi_Entry *entry; > + int rc, i; > + enum sss_id_type id_type; > + char *sid_str; > + > + if (set_data->sssd_buffer == NULL) { > + return NULL; > + } > + > + if (is_gid) { > + rc = getgrgid_r(atoi(group_name), &grp, > + set_data->sssd_buffer, > + set_data->sssd_buffer_len, &result); Please check this conversion for errors, and that it produces a value in the range of unsigned int (gid_t is unsigned). > + } else { > + rc = getgrnam_r(group_name, &grp, > + set_data->sssd_buffer, > + set_data->sssd_buffer_len, &result); > + } These need to handle ERANGE errors, too. > + if ((result == NULL) || (rc != 0)) { > + return NULL; > + } > + > + if (grp.gr_gid < cbdata->sssd_min_id) { > + return NULL; > + } > + > + entry = slapi_entry_alloc(); > + if (entry == NULL) { > + return NULL; > + } > + > + slapi_entry_add_string(entry, > + "objectClass", "top"); > + slapi_entry_add_string(entry, > + "objectClass", "posixGroup"); > + slapi_entry_add_string(entry, > + "objectClass", "extensibleObject"); > + slapi_entry_add_string(entry, > + "cn", group_name); If is_gid is true, this is a numeric string. Intentional? > + slapi_entry_attr_set_int(entry, > + "gidNumber", grp.gr_gid); > + > + slapi_entry_set_sdn(entry, set_data->container_sdn); > + slapi_entry_set_dn(entry, > + slapi_ch_smprintf("cn=%s,%s", group_name, > + slapi_sdn_get_dn(set_data->container_sdn))); I don't think that call to slapi_entry_set_sdn() is necessary if we're calling slapi_entry_set_dn() immediately after it. This DN needs to be escaped properly. > + if (grp.gr_mem) { > + if (set_data->sssd_relevant_set != NULL) { > + sdn = slapi_sdn_get_dn(set_data->sssd_relevant_set->container_sdn); > + } else { > + sdn = slapi_sdn_get_dn(set_data->container_sdn); > + } > + for (i=0; grp.gr_mem[i]; i++) { > + slapi_entry_add_string(entry, "memberUid", > + slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); > + } The "memberUid" attribute doesn't typically contain DNs. Did you mean to use "member" here? Or to just use the user login name for the value? > + } > + > + rc = sss_nss_getsidbyid(grp.gr_gid, &sid_str, &id_type); > + if ((rc == 0) && (sid_str != NULL)) { > + slapi_entry_add_string(entry, "objectClass", "ipaNTGroupAttrs"); Either this is unnecessary here, or it needs to start being copied into the entries that we're adding to the cache. > + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); > + free(sid_str); > + } > + > + return entry; > +} > + > +static void > +backend_search_sssd_send_entry(struct backend_set_data *set_data, > + struct backend_search_cbdata *cbdata, > + Slapi_Entry *entry) > +{ > + char *ndn; > + if (entry) { > + slapi_entry_add_string(entry, > + "schema-compat-origin", "sssd"); > + cbdata->matched = TRUE; > + ndn = slapi_entry_get_ndn(entry); > + backend_set_entry(cbdata->pb, entry, set_data); Problem: we only have a reading lock at this point. > + slapi_send_ldap_search_entry(cbdata->pb, entry, > + NULL, cbdata->attrs, > + cbdata->attrsonly); > + cbdata->n_entries++; > + if (cbdata->closest_match) { > + free(cbdata->closest_match); > + } > + cbdata->closest_match = strdup(ndn); > + /* Entry is created, cache it via map. > + * Next request will be served from the cache */ > + //backend_set_entry(cbdata->pb, entry, set_data); Is this commented-out call supposed to be here? > + slapi_entry_free(entry); > + } > +} > + > +/* Check filter for a component like (uid=) and if found, > + * perform look up against SSSD and create entry based on that */ > +void > +backend_search_sssd(struct backend_set_data *set_data, > + struct backend_search_cbdata *cbdata) > +{ > + int result, rc; > + Slapi_Entry *entry; > + struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; > + > + /* There was no match but we asked to check SSSD */ > + /* First, we search the filter to see if it includes cn|uid= check */ > + result = slapi_filter_apply(cbdata->filter, > + backend_search_filter_has_cn_uid, &config, &rc); > + if ((result != SLAPI_FILTER_SCAN_STOP) || > + (NULL == config.name)) { > + return; > + } > + > + /* Drop irrelevant requests. Each set only works with a single type */ > + if ((cbdata->check_sssd == SCH_SSSD_GROUP) && > + (config.search_uid || config.search_user)) { > + return; > + } > + > + if ((cbdata->check_sssd == SCH_SSSD_USER) && > + (config.search_gid || config.search_group)) { > + return; > + } > + > + if ((config.search_gid || config.search_uid) && > + (atol(config.name) < set_data->sssd_min_id)) { > + return; > + } > + > + if ((config.search_group || config.search_gid) && > + (NULL != config.name)) { > + entry = backend_retrieve_group_entry_from_sssd(config.name, > + config.search_gid, set_data, cbdata); > + backend_search_sssd_send_entry(set_data, cbdata, entry); > + return; > + } > + > + if ((config.search_user || config.search_uid) && > + (NULL != config.name)) { > + entry = backend_retrieve_user_entry_from_sssd(config.name, > + config.search_uid, set_data, cbdata); > + backend_search_sssd_send_entry(set_data, cbdata, entry); > + } > +} > diff --git a/src/back-sch.c b/src/back-sch.c > index 142bdb9..a235998 100644 > --- a/src/back-sch.c > +++ b/src/back-sch.c > @@ -50,23 +50,10 @@ > #include "format.h" > #include "plugin.h" > #include "map.h" > +#include "back-sch.h" > > #define SCH_CONTAINER_CONFIGURATION_FILTER "(&(" SCH_CONTAINER_CONFIGURATION_GROUP_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_BASE_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_FILTER_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_RDN_ATTR "=*))" > > -/* The data we ask the map cache to keep, for us, for each set. */ > -struct backend_set_data { > - struct backend_shr_set_data common; > - /* Schema compatibility-specific data. */ > - Slapi_DN *container_sdn; > - char *rdn_format; > - char **attribute_format; > - bool_t check_access; > -}; > -struct backend_entry_data { > - Slapi_DN *original_entry_dn; > - Slapi_Entry *e; > -}; > - > /* Read the name of the NIS master. A dummy function for the schema > * compatibility plugin. */ > void > @@ -98,9 +85,18 @@ backend_set_config_free_config_contents(void *data) > format_free_ref_attr_list(set_data->common.ref_attr_list); > format_free_ref_attr_list(set_data->common.inref_attr_list); > free(set_data->common.entry_filter); > + if (set_data->check_sssd != SCH_SSSD_NONE) { > + /* Remove association to another set (groups/users) */ > + if ((set_data->sssd_relevant_set != NULL) && > + (set_data->sssd_relevant_set->sssd_relevant_set == set_data)) { > + set_data->sssd_relevant_set->sssd_relevant_set = NULL; > + set_data->sssd_relevant_set = NULL; > + } > + } > slapi_sdn_free(&set_data->container_sdn); > free(set_data->rdn_format); > backend_shr_free_strlist(set_data->attribute_format); > + free(set_data->sssd_buffer); > } > } > void > @@ -146,6 +142,12 @@ backend_copy_set_config(const struct backend_set_data *data) > ret->rdn_format = strdup(data->rdn_format); > ret->attribute_format = backend_shr_dup_strlist(data->attribute_format); > ret->check_access = data->check_access; > + ret->check_sssd = data->check_sssd; > + ret->sssd_min_id = data->sssd_min_id; > + ret->sssd_buffer = data->sssd_buffer; > + ret->sssd_buffer_len = data->sssd_buffer_len; > + ret->sssd_relevant_set = data->sssd_relevant_set; > + > if ((ret->common.group == NULL) || > (ret->common.set == NULL) || > (ret->common.bases == NULL) || > @@ -164,7 +166,7 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, > const char *group, const char *container, > bool_t *flag, struct backend_shr_set_data **pret) > { > - char **bases, *entry_filter, **attributes, *rdn_format, *dn; > + char **bases, *entry_filter, **attributes, *rdn_format, *dn, *sssd_min_id, *check_sssd; > bool_t check_access; > struct backend_set_data ret; > Slapi_DN *tmp_sdn; > @@ -179,6 +181,10 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, > check_access = backend_shr_get_vattr_boolean(state, e, > SCH_CONTAINER_CONFIGURATION_ACCESS_ATTR, > TRUE); > + check_sssd = backend_shr_get_vattr_str(state, e, > + SCH_CONTAINER_CONFIGURATION_SSSD_ATTR); > + sssd_min_id = backend_shr_get_vattr_str(state, e, > + SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR); > attributes = backend_shr_get_vattr_strlist(state, e, > SCH_CONTAINER_CONFIGURATION_ATTR_ATTR); > /* Populate the returned structure. */ > @@ -213,6 +219,51 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, > ret.rdn_format = rdn_format; > ret.attribute_format = attributes; > ret.check_access = check_access; > + > + if (check_sssd != NULL) { > + if (strcasecmp(check_sssd, "group") == 0) { > + ret.check_sssd = SCH_SSSD_GROUP; > + } else if (strcasecmp(check_sssd, "user") == 0) { > + ret.check_sssd = SCH_SSSD_USER; > + } else { > + ret.check_sssd = SCH_SSSD_NONE; > + } > + } else { > + ret.check_sssd = SCH_SSSD_NONE; > + } > + ret.sssd_buffer = NULL; > + > + /* Make sure we don't return system users/groups > + * by limiting lower bound on searches */ > + ret.sssd_min_id = 1000; /* default in Fedora */ > + if (sssd_min_id != NULL) { > + ret.sssd_min_id = atol(sssd_min_id); > + } > + > + if (ret.sssd_min_id == 0) { > + /* enforce id in case of an error or too low limit */ > + ret.sssd_min_id = 1000; > + } > + > + if (ret.check_sssd != SCH_SSSD_NONE) { > + /* Auto-populate attributes based on selected SSSD tree > + * and add special attribute to track whether the entry requires PAM-based bind */ > + backend_shr_add_strlist(&ret.attribute_format, "objectClass=extensibleObject"); > + backend_shr_add_strlist(&ret.attribute_format, "schema-compat-origin=%{schema-compat-origin}"); > + backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); > + > + /* Allocate buffer to be used for getpwnam_r/getgrnam_r requests */ > + if (ret.check_sssd == SCH_SSSD_USER) { > + ret.sssd_buffer_len = sysconf(_SC_GETPW_R_SIZE_MAX); > + } else { > + ret.sssd_buffer_len = sysconf(_SC_GETGR_R_SIZE_MAX); > + } > + if ((long) ret.sssd_buffer_len == -1 ) > + ret.sssd_buffer_len = 16384; > + ret.sssd_buffer = malloc(ret.sssd_buffer_len); > + } > + > + ret.sssd_relevant_set = NULL; > *pret = backend_copy_set_config(&ret); > free(ret.common.group); > free(ret.common.set); > @@ -315,7 +366,7 @@ backend_entry_get_usn(Slapi_PBlock *pb, Slapi_Entry *e, > } > > /* Add operational attributes to a synthetic entry. */ > -static void > +void > backend_set_operational_attributes(Slapi_Entry *e, > struct plugin_state *state, > time_t timestamp, This function's being made non-static here, but it's not being called from any new locations. > @@ -879,25 +930,6 @@ backend_update_params(Slapi_PBlock *pb, struct plugin_state *state) > slapi_entry_free(our_entry); > } > > -/* Intercept a search request, and if it belongs to one of our compatibility > - * trees, answer from our cache before letting the default database have a > - * crack at it. */ > -struct backend_search_cbdata { > - Slapi_PBlock *pb; > - struct plugin_state *state; > - char *target, *strfilter, **attrs; > - int scope, sizelimit, timelimit, attrsonly; > - bool_t check_access; > - Slapi_DN *target_dn; > - Slapi_Filter *filter; > - > - bool_t answer; > - int result; > - bool_t matched; > - char *closest_match, *text; > - int n_entries; > -}; > - > static bool_t > backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) > { > @@ -993,11 +1025,17 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, > struct backend_set_data *set_data; > Slapi_Entry *set_entry; > int result, n_entries; > + int n_entries_sssd; > const char *ndn; > > cbdata = cb_data; > set_data = backend_data; > cbdata->check_access = set_data->check_access; > + cbdata->check_sssd = set_data->check_sssd; > + cbdata->sssd_min_id = set_data->sssd_min_id; > + /* If any entries were actually returned by the descending callback, > + * avoid to look up in sssd even if this set is marked to look up */ > + n_entries_sssd = cbdata->n_entries; > > /* Check the set itself, unless it's also the group, in which case we > * already evaluated it for this search. */ > @@ -1054,6 +1092,15 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, > backend_search_entry_cb, cbdata); > } > > +#ifdef HAVE_SSS_NSS_IDMAP > + /* If we didn't find an exact match for the entry but asked to look up SSSD, > + * then try to search SSSD and if successful, return that entry */ > + if ((n_entries_sssd == cbdata->n_entries) && > + (cbdata->check_sssd != SCH_SSSD_NONE)) { > + backend_search_sssd(set_data, cbdata); > + } > +#endif > + > /* If we didn't find an exact match for the entry, then store this > * container's DN as the closest match. */ > if ((!cbdata->matched) && > @@ -1409,6 +1456,7 @@ backend_bind_cb(Slapi_PBlock *pb) > struct berval ref; > struct berval *urls[] = {&ref, NULL}; > const char *ndn; > + char *is_sssd_origin = NULL; > > if (wrap_get_call_level() > 0) { > return 0; > @@ -1418,18 +1466,59 @@ backend_bind_cb(Slapi_PBlock *pb) > map_rdlock(); > backend_locate(pb, &data); > if (data != NULL) { > - ndn = slapi_sdn_get_ndn(data->original_entry_dn); > - ref.bv_len = strlen("ldap:///") + strlen(ndn); > - ref.bv_val = malloc(ref.bv_len + 1); > - if (ref.bv_val != NULL) { > - sprintf(ref.bv_val, "ldap:///%s", ndn); > - slapi_send_ldap_result(pb, LDAP_REFERRAL, > - NULL, NULL, 0, urls); > - free(ref.bv_val); > +#ifdef HAVE_SSS_NSS_IDMAP > + is_sssd_origin = slapi_entry_attr_get_charptr(data->e, "schema-compat-origin"); > + if ((is_sssd_origin != NULL) && > + (strcasecmp(is_sssd_origin, "sssd") == 0)) { > + ret = backend_sch_do_pam_auth(pb, data->e); > + if (ret != 0) { > + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, > + NULL, NULL, 0, NULL); > + ret = -1; > + } else { > + /* > + * If bind succeeded, change authentication information associated > + * with this connection. > + */ > + if (ret == LDAP_SUCCESS) { > + ndn = slapi_ch_strdup(slapi_sdn_get_ndn(data->original_entry_dn)); > + if ((slapi_pblock_set(pb, SLAPI_CONN_DN, (void*)ndn) != 0) || > + (slapi_pblock_set(pb, SLAPI_CONN_AUTHMETHOD, SLAPD_AUTH_SIMPLE) != 0)) { > + ret = LDAP_OPERATIONS_ERROR; > + } else { > + LDAPControl **reqctrls = NULL; > + slapi_pblock_get(pb, SLAPI_REQCONTROLS, &reqctrls); > + if (slapi_control_present(reqctrls, LDAP_CONTROL_AUTH_REQUEST, NULL, NULL)) { > + slapi_add_auth_response_control(pb, ndn); > + } > + } > + } > + > + if (ret == LDAP_SUCCESS) { > + /* we are handling the result */ > + slapi_send_ldap_result(pb, ret, NULL, NULL, 0, NULL); > + /* tell bind code we handled the result */ > + ret = 0; > + } > + } This leg's hanging on to the map lock while it calls into PAM. If we retrieved the two attributes we care about (uid and schema-compat-origin), and kept a copy of the DN we're going to assign if the bind succeeds, we could let go of the lock that keeps the "data" structure from being modified before calling into PAM. > } else { > - slapi_send_ldap_result(pb, LDAP_BUSY, > - NULL, NULL, 0, NULL); > +#endif > + ndn = slapi_sdn_get_ndn(data->original_entry_dn); > + ref.bv_len = strlen("ldap:///") + strlen(ndn); > + ref.bv_val = malloc(ref.bv_len + 1); > + if (ref.bv_val != NULL) { > + sprintf(ref.bv_val, "ldap:///%s", ndn); > + slapi_send_ldap_result(pb, LDAP_REFERRAL, > + NULL, NULL, 0, urls); > + free(ref.bv_val); > + } else { > + slapi_send_ldap_result(pb, LDAP_BUSY, > + NULL, NULL, 0, NULL); > + } > +#ifdef HAVE_SSS_NSS_IDMAP > } > + free(is_sssd_origin); > +#endif > ret = -1; > } else { > if (backend_check_scope_pb(pb)) { Please rework this function so that the conditional logic isn't interspersed with preprocessor logic. It's kind of hard to follow. HTH, Nalin From mkosek at redhat.com Tue Jul 23 07:02:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Jul 2013 09:02:43 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51EDC0E0.1050602@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ED27BC.2030005@redhat.com> <51EDC0E0.1050602@redhat.com> Message-ID: <51EE2A93.10409@redhat.com> On 07/23/2013 01:31 AM, Dmitri Pal wrote: > On 07/22/2013 08:38 AM, Petr Vobornik wrote: >> On 07/19/2013 11:19 PM, Dmitri Pal wrote: >>> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>>> Originally we wanted to do this change in >>>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>>> because of string freeze. >>>>> >>>>> I guess you can add field suffix to every field from /etc/password >>>>> when you use it in a sentence but that doesn't necessary mean that >>>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>>> directory. The GECOS field value does not, really. >>>> >>>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>>> in fields description/list either. IMO our use case is the same. >>>> It says: >>>> >>>> GECOS This field (sometimes called the "comment field") >>>> [...] >>>> The gcos field in the password file was >>>> [...] >>>> >>>>> Historically correct label would probably be 'GECOS identity' but >>>>> that's not usable today as it's purpose is more general. >> >>> Do we have tips in the UI? >>> May be we should add them in future to provide extra information about >>> meaning of the field or button. >> >> We do, but UX is not the best. 'doc' defined in .py files is displayed >> as a textbox tooltip. This feature is not apparent and for most of the >> fields the tooltip is the same as label. >> >> There is an idea to display a question mark icon next to textboxes to >> draw an attention to a presence of the doc text and provide it in a >> tooltip. >> >> I like the way how it's done in Alchemy UI: >> http://www.ui-alchemy.org/form You can notice there an additional >> information (string length limitation, example...) when field is focused. >> >> I went through open tickets and found few which touches the topic: >> - https://fedorahosted.org/freeipa/ticket/2912 [RFE] [Web UI] Use doc >> as field's tooltip instead of label >> * Seems to be already implemented. Then please close it and move it to the milestone where it was closed (if possible). >> - https://fedorahosted.org/freeipa/ticket/2413 [RFE]: add in UI >> examples of what is the requested field >> - https://fedorahosted.org/freeipa/ticket/3661 [RFE] IPA Web UI: When >> adding new reverse zone in DNS there could be an example of expected >> address format >> * Looks like duplicate of #2413 Right, please proceed with closing as duplicate then. I would prefer leaving only ticket 2413 open instead of changing description of 2912 though. Martin >> >> IMO we should close #2413 and maybe #2912 or change #2912 to cover the >> above mentioned proposals (in case of agreement). >> >>> For now I think GECOS would probably be good enough. >>> Adding "field" makes it more precise but looks weird. >>> >> >> > Sounds reasonable. > > From abokovoy at redhat.com Tue Jul 23 07:15:47 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Jul 2013 10:15:47 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130723064634.GA20085@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> Message-ID: <20130723071547.GF15859@redhat.com> On Tue, 23 Jul 2013, Nalin Dahyabhai wrote: >Apologies for the delay. Thanks for the review! One short comment -- PAM code is from PAM pass-through plugin from 389-ds. That's the reason why its code doesn't follow slapi-nis way and why it has that license. I tried to keep it mostly intact to share changes but looking at git log it gets roughly two commits per year so maybe it is better to rework it completely. I'll address other comments and will send updated version for the review today. This was my first sizable SLAPI code so errors are inevitable. >On Mon, Jul 15, 2013 at 08:30:03PM +0300, Alexander Bokovoy wrote: >> Here is the logic: >> >> 0. Configuration is performed by setting >> >> schema-compat-lookup-sssd: >> schema-compat-sssd-min-id: >> >> in corresponding schema-compat plugin tree (cn=users and cn=groups). >> >> If schema-compat-sssd-min-id is not set, it will default to 1000. It is >> used to filter out attempts to fetch system users (<1000 on Fedora by >> default). >> >> 1. On query, we parse query filter to identify what type of request is >> this: user or group lookup and then issue getpwnam_r()/getgrnam_r() and >> getsidbyid() for libsss_nss_idmap to fetch all needed information. >> >> SSSD caches these requests they should be relatively fast. >> >> 2. Once we served the request, it is cached in schema-compat cache map. >> The entry in the cache is currently not expired explicitly but I'm >> working on expiring it on wrong authentication -- if PAM stack returns a >> response telling there is no such user. >> >> 3. Authentication bind for cached entries is done via PAM service >> 'system-auth'. If HBAC rule 'allow_all' is disabled in FreeIPA, one >> needs to create a rule with service 'system-auth' and allow all users to >> access it on IPA masters. Since system-auth is never used explicitly by >> any application (it is always included through PAM stack and only >> top-level PAM service is used to drive the HBAC ruleset), there is no >> problem. >> >> PAM authentication code is taken from pam_passthru DS plugin. We cannot >> use it unchanged because pam_passthru expects that LDAP entry will exist >> in DS, while it is not true for these synthetic entries representing >> trusted domain users. >> >> On Fedora one needs pam-devel and libsss_nss_idmap-devel to build the >> plugin with new functionality. > >The bits about how to configure this facility need to be in the >documentation somewhere. Right now there is none being added, and no >new self-tests. > >> diff --git a/configure.ac b/configure.ac >> index 8d7cbe1..4a47d36 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -309,6 +309,47 @@ AC_SUBST(ASYNCNS_CFLAGS) >> AC_SUBST(ASYNCNS_LIBS) >> fi >> >> +AC_ARG_WITH(sss_nss_idmap, >> + AS_HELP_STRING([--with-sss-nss-idmap], [use libsss_nss_idmap]), >> + use_sss_nss_idmap=$withval,use_sss_nss_idmap=AUTO) >> +if pkg-config sss_nss_idmap 2> /dev/null ; then >> + if test x$use_sss_nss_idmap != xno ; then >> + AC_DEFINE(HAVE_SSS_NSS_IDMAP,1,[Define if you have libsss_nss_idmap.]) >> + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> + else >> + SSS_NSS_IDMAP_CFLAGS= >> + SSS_NSS_IDMAP_LIBS= >> + fi >> +else >> + if test $use_sss_idmap = yes ; then > >Should this reference to $use_sss_idmap be referring to >$use_sss_nss_idmap instead? > >> + PKG_CHECK_MODULES(SSS_NSS_IDMAP,sss_nss_idmap) >> + else >> + SSS_NSS_IDMAP_CFLAGS= >> + SSS_NSS_IDMAP_LIBS= >> + fi >> +fi >> +AM_CONDITIONAL([SSS_NSS_IDMAP], [test x$SSS_NSS_IDMAP_LIBS != x]) > >I suspect this'll need to quote SSS_NSS_IDMAP_LIBS here, in case its >value ever starts to include whitespace. > >> +if x$SSS_NSS_IDMAP_LIBS != x ; then > >Likewise here. > >> + AC_CHECK_HEADERS(pam.h) >> + if test x$ac_cv_header_pam_h = xno ; then >> + use_pam=yes >> + else >> + use_pam=no >> + fi >> + >> + if test $use_pam = yes ; then >> + PAM_CFLAGS= >> + PAM_LIBS=-lpam >> + else >> + AC_ERROR([ not found and it is required for SSSD mode]) >> + fi >> + AC_SUBST(PAM_CFLAGS) >> + AC_SUBST(PAM_LIBS) >> +fi > >Jakub already noted that this should be checking for >. > >> @@ -401,6 +442,13 @@ AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_RDN_ATTR,"$rdnattr", >> attrattr=schema-compat-entry-attribute >> AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_ATTR_ATTR,"$attrattr", >> [Define to name of the attribute which is used to specify attributes to be used when constructing entries.]) >> +sssdattr=schema-compat-lookup-sssd >> +AC_DEFINE_UNQUOTED(SCH_CONTAINER_CONFIGURATION_SSSD_ATTR,"$sssdattr", >> + [Define to name of the attribute which dictates whether or not SSSD on FreeIPA master is consulted about trusted domains' users.]) > >Is this a boolean attribute? > >> diff --git a/src/back-sch-pam.c b/src/back-sch-pam.c >> new file mode 100644 >> index 0000000..3266261 >> --- /dev/null >> +++ b/src/back-sch-pam.c >> @@ -0,0 +1,361 @@ >> +/** BEGIN COPYRIGHT BLOCK >> + * 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 the Free Software >> + * Foundation; version 2 of the License. >> + * >> + * This Program is distributed in the hope that it will be useful, but WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS >> + * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License along with >> + * this Program; if not, write to the Free Software Foundation, Inc., 59 Temple >> + * Place, Suite 330, Boston, MA 02111-1307 USA. >> + * >> + * In addition, as a special exception, Red Hat, Inc. gives You the additional >> + * right to link the code of this Program with code not covered under the GNU >> + * General Public License ("Non-GPL Code") and to distribute linked combinations >> + * including the two, subject to the limitations in this paragraph. Non-GPL Code >> + * permitted under this exception must only link to the code of this Program >> + * through those well defined interfaces identified in the file named EXCEPTION >> + * found in the source code files (the "Approved Interfaces"). The files of >> + * Non-GPL Code may instantiate templates or use macros or inline functions from >> + * the Approved Interfaces without causing the resulting work to be covered by >> + * the GNU General Public License. Only Red Hat, Inc. may make changes or >> + * additions to the list of Approved Interfaces. You must obey the GNU General >> + * Public License in all respects for all of the Program code and other code used >> + * in conjunction with the Program except the Non-GPL Code covered by this >> + * exception. If you modify this file, you may extend this exception to your >> + * version of the file, but you are not obligated to do so. If you do not wish to >> + * provide this exception without modification, you must delete this exception >> + * statement from your version and license this file solely under the GPL without >> + * exception. >> + * >> + * >> + * Copyright (C) 2005 Red Hat, Inc. >> + * All rights reserved. >> + * END COPYRIGHT BLOCK **/ > >Did you mean to use the server's GPLv2+exceptions license for this code? >It differs from the rest of the plugin. And that date of 2005 looks >kind of odd. > >> +#ifdef HAVE_CONFIG_H >> +#include "config.h" >> +#endif >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H >> +#include >> +#include >> +#include >> +#else >> +#include >> +#endif >> + >> + >> +#include >> + >> +/* >> + * PAM is not thread safe. We have to execute any PAM API calls in >> + * a critical section. This is the lock that protects that code. >> + */ >> +static Slapi_Mutex *PAMLock = NULL; > >Right now this mutex is being initialized after the server's gone and >launched multiple threads, which if timed right could go badly. Move >the pointer into the plugin_state structure, and initialize it when the >rest of the structure's being initialized when the compat plugin starts >up. > >Also, please avoid using caps in variable names and use underscores, >like the rest of the plugin does. > >> +/* Utility struct to wrap strings to avoid mallocs if possible - use >> + stack allocated string space */ >> +#define MY_STATIC_BUF_SIZE 256 >> +typedef struct my_str_buf { >> + char fixbuf[MY_STATIC_BUF_SIZE]; >> + char *str; >> +} MyStrBuf; >> + >> +static char * >> +init_my_str_buf(MyStrBuf *buf, const char *s) >> +{ >> + PR_ASSERT(buf); >> + if (s && (strlen(s) < sizeof(buf->fixbuf))) { >> + strcpy(buf->fixbuf, s); >> + buf->str = buf->fixbuf; >> + } else { >> + buf->str = slapi_ch_strdup(s); >> + buf->fixbuf[0] = 0; >> + } >> + >> + return buf->str; >> +} >> + >> +static void >> +delete_my_str_buf(MyStrBuf *buf) >> +{ >> + if (buf->str != buf->fixbuf) { >> + slapi_ch_free_string(&(buf->str)); >> + } >> +} > >This seems unnecessary. > >> +/* for third arg to pam_start */ >> +struct my_pam_conv_str { >> + Slapi_PBlock *pb; >> + char *pam_identity; >> +}; >> + >> +/* returns a berval value as a null terminated string */ >> +static char *strdupbv(struct berval *bv) >> +{ >> + char *str = slapi_ch_malloc(bv->bv_len+1); >> + memcpy(str, bv->bv_val, bv->bv_len); >> + str[bv->bv_len] = 0; >> + return str; >> +} > >Please reformat this so that the function name is in the first column, >to make it easier to find with a trivial grep ^$functionname. Also >applies to do_pam_auth() below. > >In non-error cases, this new string is going to be freed by free(). >Please avoid allocating memory with slapi_ch_malloc() if it'll be freed >with free(), or allocating with malloc()/calloc()/strdup() if it'll be >freed with slapi_ch_free(). > >> +static void >> +free_pam_response(int nresp, struct pam_response *resp) >> +{ >> + int ii; >> + for (ii = 0; ii < nresp; ++ii) { >> + if (resp[ii].resp) { >> + slapi_ch_free((void **)&(resp[ii].resp)); >> + } >> + } >> + slapi_ch_free((void **)&resp); >> +} > >In non-error cases, these pointers would be freed by a plugin calling >free(). Please avoid mixing calls to slapi_ch_malloc() and >slapi_ch_free() with malloc()/free()/strdup(). > >> +/* >> + * This is the conversation function passed into pam_start(). This is what sets the password >> + * that PAM uses to authenticate. This function is sort of stupid - it assumes all echo off >> + * or binary prompts are for the password, and other prompts are for the username. Time will >> + * tell if this is actually the case. >> + */ >> +static int >> +pam_conv_func(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *mydata) >> +{ >> + int ii; >> + struct berval *creds; >> + struct my_pam_conv_str *my_data = (struct my_pam_conv_str *)mydata; >> + struct pam_response *reply; >> + int ret = PAM_SUCCESS; >> + >> + if (num_msg <= 0) { >> + return PAM_CONV_ERR; >> + } >> + >> + /* empty reply structure */ >> + reply = (struct pam_response *)slapi_ch_calloc(num_msg, >> + sizeof(struct pam_response)); >> + slapi_pblock_get( my_data->pb, SLAPI_BIND_CREDENTIALS, &creds ); /* the password */ >> + for (ii = 0; ii < num_msg; ++ii) { >> + /* hard to tell what prompt is for . . . */ >> + /* assume prompts for password are either BINARY or ECHO_OFF */ >> + if (msg[ii]->msg_style == PAM_PROMPT_ECHO_OFF) { >> + reply[ii].resp = strdupbv(creds); >> +#ifdef LINUX >> + } else if (msg[ii]->msg_style == PAM_BINARY_PROMPT) { >> + reply[ii].resp = strdupbv(creds); >> +#endif >> + } else if (msg[ii]->msg_style == PAM_PROMPT_ECHO_ON) { /* assume username */ >> + reply[ii].resp = slapi_ch_strdup(my_data->pam_identity); >> + } else if (msg[ii]->msg_style == PAM_ERROR_MSG) { >> + } else if (msg[ii]->msg_style == PAM_TEXT_INFO) { >> + } else { >> + ret = PAM_CONV_ERR; >> + } > >Replace this with a switch{} construction. > >> + } >> + >> + if (ret == PAM_CONV_ERR) { >> + free_pam_response(num_msg, reply); >> + reply = NULL; >> + } >> + >> + *resp = reply; >> + >> + return ret; >> +} > >You're mixing hard tabs and spaces for indentation here. > >> +/* >> + * Do the actual work of authenticating with PAM. First, get the PAM identity >> + * based on the method used to convert the BIND identity to the PAM identity. >> + * Set up the structures that pam_start needs and call pam_start(). After >> + * that, call pam_authenticate and pam_acct_mgmt. Check the various return >> + * values from these functions and map them to their corresponding LDAP BIND >> + * return values. Return the appropriate LDAP error code. >> + * This function will also set the appropriate LDAP response controls in >> + * the given pblock. >> + * Since this function can be called multiple times, we only want to return >> + * the errors and controls to the user if this is the final call, so the >> + * final_method parameter tells us if this is the last one. Coupled with >> + * the fallback argument, we can tell if we are able to send the response >> + * back to the client. >> + */ > >There aren't parameters named final_method or fallback in the function >signature. Please update the comment to better describe the current >implementation. > >> +static int >> +do_pam_auth( >> + Slapi_PBlock *pb, >> + char *pam_service, /* name of service for pam_start() */ >> + int pw_response_requested, /* do we need to send pwd policy resp control */ >> + Slapi_Entry *entry >> +) > >Fix the formatting for this to match the rest of the plugin, please. > >> +{ >> + MyStrBuf pam_id; >> + const char *binddn = NULL; >> + Slapi_DN *bindsdn = NULL; >> + int rc = PAM_SUCCESS; >> + int retcode = LDAP_SUCCESS; >> + pam_handle_t *pam_handle; >> + struct my_pam_conv_str my_data; >> + struct pam_conv my_pam_conv = {pam_conv_func, NULL}; >> + char *errmsg = NULL; /* free with PR_smprintf_free */ >> + >> + slapi_pblock_get( pb, SLAPI_BIND_TARGET_SDN, &bindsdn ); >> + if (NULL == bindsdn) { >> + errmsg = PR_smprintf("Null bind dn"); >> + retcode = LDAP_OPERATIONS_ERROR; >> + pam_id.str = NULL; /* initialize pam_id.str */ >> + goto done; /* skip the pam stuff */ >> + } >> + binddn = slapi_sdn_get_dn(bindsdn); >> + >> + char *val = slapi_entry_attr_get_charptr(entry, "uid"); >> + init_my_str_buf(&pam_id, val); >> + slapi_ch_free_string(&val); > >Move the declaration of val to the beginning of the function. Also, if >we already have a non-const copy of the uid value, there's no need to >bother with the second one -- just use val directly. > >> + if (!pam_id.str) { >> + errmsg = PR_smprintf("Bind DN [%s] is invalid or not found", binddn); >> + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ >> + goto done; /* skip the pam stuff */ >> + } >> + >> + /* do the pam stuff */ >> + my_data.pb = pb; >> + my_data.pam_identity = pam_id.str; >> + my_pam_conv.appdata_ptr = &my_data; >> + slapi_lock_mutex(PAMLock); >> + /* from this point on we are in the critical section */ >> + rc = pam_start(pam_service, pam_id.str, &my_pam_conv, &pam_handle); >> + >> + if (rc == PAM_SUCCESS) { >> + /* use PAM_SILENT - there is no user interaction at this point */ >> + rc = pam_authenticate(pam_handle, 0); > >Should this call to pam_authenticate be specifying PAM_SILENT or not? > >> + /* check different types of errors here */ >> + if (rc == PAM_USER_UNKNOWN) { >> + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", >> + pam_id.str, binddn); >> + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ >> + } else if (rc == PAM_AUTH_ERR) { >> + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", >> + pam_id.str, binddn); >> + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ >> + } else if (rc == PAM_MAXTRIES) { >> + errmsg = PR_smprintf("Authentication retry limit exceeded in PAM for " >> + "user id [%s], bind DN [%s]", >> + pam_id.str, binddn); >> + if (pw_response_requested) { >> + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); >> + } >> + retcode = LDAP_CONSTRAINT_VIOLATION; /* max retries */ >> + } else if (rc != PAM_SUCCESS) { >> + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", >> + pam_strerror(pam_handle, rc), pam_id.str, binddn); >> + retcode = LDAP_OPERATIONS_ERROR; /* pam config or network problem */ >> + } > >Replace this with a switch{} construction. > >> + } >> + >> + /* if user authenticated successfully, see if there is anything we need >> + to report back w.r.t. password or account lockout */ >> + if (rc == PAM_SUCCESS) { >> + rc = pam_acct_mgmt(pam_handle, 0); >> + /* check different types of errors here */ >> + if (rc == PAM_USER_UNKNOWN) { >> + errmsg = PR_smprintf("User id [%s] for bind DN [%s] does not exist in PAM", >> + pam_id.str, binddn); >> + retcode = LDAP_NO_SUCH_OBJECT; /* user unknown */ >> + } else if (rc == PAM_AUTH_ERR) { >> + errmsg = PR_smprintf("Invalid PAM password for user id [%s], bind DN [%s]", >> + pam_id.str, binddn); >> + retcode = LDAP_INVALID_CREDENTIALS; /* invalid creds */ >> + } else if (rc == PAM_PERM_DENIED) { >> + errmsg = PR_smprintf("Access denied for PAM user id [%s], bind DN [%s]" >> + " - see administrator", >> + pam_id.str, binddn); >> + if (pw_response_requested) { >> + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_ACCTLOCKED); >> + } >> + retcode = LDAP_UNWILLING_TO_PERFORM; >> + } else if (rc == PAM_ACCT_EXPIRED) { >> + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " >> + "reset required", >> + pam_id.str, binddn); >> + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); >> + if (pw_response_requested) { >> + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); >> + } >> + retcode = LDAP_INVALID_CREDENTIALS; >> + } else if (rc == PAM_NEW_AUTHTOK_REQD) { /* handled same way as ACCT_EXPIRED */ >> + errmsg = PR_smprintf("Expired PAM password for user id [%s], bind DN [%s]: " >> + "reset required", >> + pam_id.str, binddn); >> + slapi_add_pwd_control(pb, LDAP_CONTROL_PWEXPIRED, 0); >> + if (pw_response_requested) { >> + slapi_pwpolicy_make_response_control(pb, -1, -1, LDAP_PWPOLICY_PWDEXPIRED); >> + } >> + retcode = LDAP_INVALID_CREDENTIALS; >> + } else if (rc != PAM_SUCCESS) { >> + errmsg = PR_smprintf("Unknown PAM error [%s] for user id [%s], bind DN [%s]", >> + pam_strerror(pam_handle, rc), pam_id.str, binddn); >> + retcode = LDAP_OPERATIONS_ERROR; /* unknown */ >> + } > >Replace this with a switch{} construction. > >> + } >> + >> + rc = pam_end(pam_handle, rc); >> + slapi_unlock_mutex(PAMLock); >> + /* not in critical section any more */ >> + >> +done: >> + delete_my_str_buf(&pam_id); >> + >> + if ((retcode == LDAP_SUCCESS) && (rc != PAM_SUCCESS)) { >> + errmsg = PR_smprintf("Unknown PAM error [%d] for user id [%s], bind DN [%s]", >> + rc, pam_id.str, binddn); >> + retcode = LDAP_OPERATIONS_ERROR; >> + } >> + >> + if (retcode != LDAP_SUCCESS) { >> + slapi_send_ldap_result(pb, retcode, NULL, errmsg, 0, NULL); >> + } >> + >> + if (errmsg) { >> + PR_smprintf_free(errmsg); >> + } >> + >> + return retcode; >> +} >> + >> +/* >> + * Entry point into the PAM auth code. Shields the rest of the app >> + * from PAM API code. Get our config params, then call the actual >> + * code that does the PAM auth. Can call that code up to 3 times, >> + * depending on what methods are set in the config. >> + */ >> +int >> +backend_sch_do_pam_auth(Slapi_PBlock *pb, Slapi_Entry *entry) >> +{ >> + int rc = LDAP_SUCCESS; >> + MyStrBuf pam_service; /* avoid malloc if possible */ >> + int pw_response_requested; >> + LDAPControl **reqctrls = NULL; >> + >> + if (!PAMLock && !(PAMLock = slapi_new_mutex())) { >> + return LDAP_LOCAL_ERROR; >> + } >> + >> + init_my_str_buf(&pam_service, "system-auth"); >> + >> + slapi_pblock_get (pb, SLAPI_REQCONTROLS, &reqctrls); >> + slapi_pblock_get (pb, SLAPI_PWPOLICY, &pw_response_requested); >> + >> + /* figure out which method is the last one - we only return error codes, controls >> + to the client and send a response on the last method */ > >This comment doesn't seem to be current. > >> + rc = do_pam_auth(pb, pam_service.str, pw_response_requested, entry); >> + >> + delete_my_str_buf(&pam_service); >> + >> + return rc; >> +} > >reqctrls isn't being used after it's assigned. Unless I'm missing where >it is, go ahead and remove it. > >There's also no need to make a copy of the "system-auth" string when it >can be used directly. > >> diff --git a/src/back-sch-sssd.c b/src/back-sch-sssd.c >> new file mode 100644 >> index 0000000..8168675 >> --- /dev/null >> +++ b/src/back-sch-sssd.c >> @@ -0,0 +1,335 @@ >> +/* >> + * Copyright 2008,2009,2010,2011,2012 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 >> + * the Free Software Foundation; version 2 of the License. >> + * >> + * This Program is distributed in the hope that it will be useful, but >> + * WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + * General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this Program; if not, write to the >> + * >> + * Free Software Foundation, Inc. >> + * 59 Temple Place, Suite 330 >> + * Boston, MA 02111-1307 USA >> + * >> + */ >> + >> +#ifdef HAVE_CONFIG_H >> +#include "config.h" >> +#endif >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H >> +#include >> +#include >> +#include >> +#else >> +#include >> +#endif >> + >> +#include >> +#include >> + >> +#include "backend.h" >> +#include "back-shr.h" >> +#include "plugin.h" >> +#include "map.h" >> +#include "back-sch.h" >> + >> +struct backend_search_filter_config { >> + bool_t search_user; >> + bool_t search_group; >> + bool_t search_uid; >> + bool_t search_gid; >> + bool_t name_set; >> + char *name; >> +}; >> + >> +/* Check simple filter to see if it has >> + * (cn|uid|uidNumber|gidNumber=) or (objectClass=posixGroup) >> + * Called by slapi_filter_apply(). */ >> +static int >> +backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) >> +{ >> + struct backend_search_filter_config *config = arg; >> + struct berval *bval; >> + char *filter_type; >> + int f_choice, rc; >> + >> + f_choice = slapi_filter_get_choice(filter); >> + rc = slapi_filter_get_ava(filter, &filter_type, &bval); >> + if ((LDAP_FILTER_EQUALITY == f_choice) && (0 == rc)) { >> + if (0 == strcasecmp(filter_type, "uidNumber")) { >> + config->search_uid = TRUE; >> + config->name_set = TRUE; >> + } else if (0 == strcasecmp(filter_type, "gidNumber")) { >> + config->search_gid = TRUE; >> + config->name_set = TRUE; >> + } else if (0 == strcasecmp(filter_type, "uid")) { >> + config->search_user = TRUE; >> + config->name_set = TRUE; >> + } else if (0 == strcasecmp(filter_type, "cn")) { >> + config->name_set = TRUE; >> + } else if ((0 == strcasecmp(filter_type, "objectClass")) && >> + (0 == strcasecmp(bval->bv_val, "posixGroup"))) { >> + config->search_group = TRUE; >> + } >> + >> + if ((NULL == config->name) && config->name_set) { >> + config->name = bval->bv_val; > >Is bval->bv_val guaranteed to be nul-terminated here? > >> + } >> + } >> + >> + if ((config->search_uid || >> + config->search_gid || >> + config->search_user || >> + config->search_group) && (config->name != NULL)) { >> + return SLAPI_FILTER_SCAN_STOP; >> + } >> + return SLAPI_FILTER_SCAN_CONTINUE; >> +} >> + >> +static Slapi_Entry * >> +backend_retrieve_user_entry_from_sssd(char *user_name, bool_t is_uid, >> + struct backend_set_data *set_data, >> + struct backend_search_cbdata *cbdata) >> +{ >> + struct passwd pwd, *result; >> + Slapi_Entry *entry; >> + int rc; >> + enum sss_id_type id_type; >> + char *sid_str; >> + >> + if (set_data->sssd_buffer == NULL) { >> + return NULL; >> + } >> + >> + if (is_uid) { >> + rc = getpwuid_r(atoi(user_name), &pwd, >> + set_data->sssd_buffer, >> + set_data->sssd_buffer_len, &result); > >Please check this conversion for errors, and that it produces a value >in the range of unsigned int (uid_t is unsigned). > >Why do the function names all suggest that we're retrieving data from >SSSD, when we don't verify that? > >> + } else { >> + rc = getpwnam_r(user_name, &pwd, >> + set_data->sssd_buffer, >> + set_data->sssd_buffer_len, &result); >> + } > >These need to handle ERANGE errors. > >> + if ((result == NULL) || (rc != 0)) { >> + return NULL; >> + } >> + >> + if (pwd.pw_uid < cbdata->sssd_min_id) { >> + return NULL; >> + } >> + >> + entry = slapi_entry_alloc(); >> + if (entry == NULL) { >> + return NULL; >> + } >> + >> + slapi_entry_add_string(entry, >> + "objectClass", "top"); >> + slapi_entry_add_string(entry, >> + "objectClass", "posixAccount"); >> + slapi_entry_add_string(entry, >> + "objectClass", "extensibleObject"); >> + slapi_entry_add_string(entry, >> + "uid", user_name); > >If is_uid is true, this is a numeric string. Intentional? > >> + slapi_entry_attr_set_int(entry, >> + "uidNumber", pwd.pw_uid); >> + slapi_entry_attr_set_int(entry, >> + "gidNumber", pwd.pw_gid); >> + slapi_entry_add_string(entry, >> + "gecos", pwd.pw_gecos); >> + if (strlen(pwd.pw_gecos) > 0) { >> + slapi_entry_add_string(entry, >> + "cn", pwd.pw_gecos); >> + } else { >> + slapi_entry_add_string(entry, >> + "cn", user_name); >> + } >> + >> + slapi_entry_add_string(entry, >> + "homeDirectory", pwd.pw_dir); >> + slapi_entry_add_string(entry, >> + "loginShell", pwd.pw_shell); >> + slapi_entry_set_sdn(entry, set_data->container_sdn); >> + slapi_entry_set_dn(entry, slapi_ch_smprintf("uid=%s,%s", >> + user_name, slapi_sdn_get_dn(set_data->container_sdn))); > >I don't think that call to slapi_entry_set_sdn() is necessary if we're >calling slapi_entry_set_dn() immediately after it. > >This DN needs to be escaped properly. > >> + rc = sss_nss_getsidbyid(pwd.pw_uid, &sid_str, &id_type); >> + if ((rc == 0) && (sid_str != NULL)) { >> + slapi_entry_add_string(entry, "objectClass", "ipaNTUserAttrs"); > >Either this is unnecessary here, or it needs to start being copied into >the entries that we're adding to the cache. > >> + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); >> + free(sid_str); >> + } >> + >> + >> + return entry; >> +} >> + >> + >> +static Slapi_Entry * >> +backend_retrieve_group_entry_from_sssd(char *group_name, bool_t is_gid, >> + struct backend_set_data *set_data, >> + struct backend_search_cbdata *cbdata) >> +{ >> + struct group grp, *result; >> + const char *sdn; >> + Slapi_Entry *entry; >> + int rc, i; >> + enum sss_id_type id_type; >> + char *sid_str; >> + >> + if (set_data->sssd_buffer == NULL) { >> + return NULL; >> + } >> + >> + if (is_gid) { >> + rc = getgrgid_r(atoi(group_name), &grp, >> + set_data->sssd_buffer, >> + set_data->sssd_buffer_len, &result); > >Please check this conversion for errors, and that it produces a value >in the range of unsigned int (gid_t is unsigned). > >> + } else { >> + rc = getgrnam_r(group_name, &grp, >> + set_data->sssd_buffer, >> + set_data->sssd_buffer_len, &result); >> + } > >These need to handle ERANGE errors, too. > >> + if ((result == NULL) || (rc != 0)) { >> + return NULL; >> + } >> + >> + if (grp.gr_gid < cbdata->sssd_min_id) { >> + return NULL; >> + } >> + >> + entry = slapi_entry_alloc(); >> + if (entry == NULL) { >> + return NULL; >> + } >> + >> + slapi_entry_add_string(entry, >> + "objectClass", "top"); >> + slapi_entry_add_string(entry, >> + "objectClass", "posixGroup"); >> + slapi_entry_add_string(entry, >> + "objectClass", "extensibleObject"); >> + slapi_entry_add_string(entry, >> + "cn", group_name); > >If is_gid is true, this is a numeric string. Intentional? > >> + slapi_entry_attr_set_int(entry, >> + "gidNumber", grp.gr_gid); >> + >> + slapi_entry_set_sdn(entry, set_data->container_sdn); >> + slapi_entry_set_dn(entry, >> + slapi_ch_smprintf("cn=%s,%s", group_name, >> + slapi_sdn_get_dn(set_data->container_sdn))); > >I don't think that call to slapi_entry_set_sdn() is necessary if we're >calling slapi_entry_set_dn() immediately after it. > >This DN needs to be escaped properly. > >> + if (grp.gr_mem) { >> + if (set_data->sssd_relevant_set != NULL) { >> + sdn = slapi_sdn_get_dn(set_data->sssd_relevant_set->container_sdn); >> + } else { >> + sdn = slapi_sdn_get_dn(set_data->container_sdn); >> + } >> + for (i=0; grp.gr_mem[i]; i++) { >> + slapi_entry_add_string(entry, "memberUid", >> + slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); >> + } > >The "memberUid" attribute doesn't typically contain DNs. Did you mean >to use "member" here? Or to just use the user login name for the value? > >> + } >> + >> + rc = sss_nss_getsidbyid(grp.gr_gid, &sid_str, &id_type); >> + if ((rc == 0) && (sid_str != NULL)) { >> + slapi_entry_add_string(entry, "objectClass", "ipaNTGroupAttrs"); > >Either this is unnecessary here, or it needs to start being copied into >the entries that we're adding to the cache. > >> + slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); >> + free(sid_str); >> + } >> + >> + return entry; >> +} >> + >> +static void >> +backend_search_sssd_send_entry(struct backend_set_data *set_data, >> + struct backend_search_cbdata *cbdata, >> + Slapi_Entry *entry) >> +{ >> + char *ndn; >> + if (entry) { >> + slapi_entry_add_string(entry, >> + "schema-compat-origin", "sssd"); >> + cbdata->matched = TRUE; >> + ndn = slapi_entry_get_ndn(entry); >> + backend_set_entry(cbdata->pb, entry, set_data); > >Problem: we only have a reading lock at this point. > >> + slapi_send_ldap_search_entry(cbdata->pb, entry, >> + NULL, cbdata->attrs, >> + cbdata->attrsonly); >> + cbdata->n_entries++; >> + if (cbdata->closest_match) { >> + free(cbdata->closest_match); >> + } >> + cbdata->closest_match = strdup(ndn); >> + /* Entry is created, cache it via map. >> + * Next request will be served from the cache */ >> + //backend_set_entry(cbdata->pb, entry, set_data); > >Is this commented-out call supposed to be here? > >> + slapi_entry_free(entry); >> + } >> +} >> + >> +/* Check filter for a component like (uid=) and if found, >> + * perform look up against SSSD and create entry based on that */ >> +void >> +backend_search_sssd(struct backend_set_data *set_data, >> + struct backend_search_cbdata *cbdata) >> +{ >> + int result, rc; >> + Slapi_Entry *entry; >> + struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; >> + >> + /* There was no match but we asked to check SSSD */ >> + /* First, we search the filter to see if it includes cn|uid= check */ >> + result = slapi_filter_apply(cbdata->filter, >> + backend_search_filter_has_cn_uid, &config, &rc); >> + if ((result != SLAPI_FILTER_SCAN_STOP) || >> + (NULL == config.name)) { >> + return; >> + } >> + >> + /* Drop irrelevant requests. Each set only works with a single type */ >> + if ((cbdata->check_sssd == SCH_SSSD_GROUP) && >> + (config.search_uid || config.search_user)) { >> + return; >> + } >> + >> + if ((cbdata->check_sssd == SCH_SSSD_USER) && >> + (config.search_gid || config.search_group)) { >> + return; >> + } >> + >> + if ((config.search_gid || config.search_uid) && >> + (atol(config.name) < set_data->sssd_min_id)) { >> + return; >> + } >> + >> + if ((config.search_group || config.search_gid) && >> + (NULL != config.name)) { >> + entry = backend_retrieve_group_entry_from_sssd(config.name, >> + config.search_gid, set_data, cbdata); >> + backend_search_sssd_send_entry(set_data, cbdata, entry); >> + return; >> + } >> + >> + if ((config.search_user || config.search_uid) && >> + (NULL != config.name)) { >> + entry = backend_retrieve_user_entry_from_sssd(config.name, >> + config.search_uid, set_data, cbdata); >> + backend_search_sssd_send_entry(set_data, cbdata, entry); >> + } >> +} >> diff --git a/src/back-sch.c b/src/back-sch.c >> index 142bdb9..a235998 100644 >> --- a/src/back-sch.c >> +++ b/src/back-sch.c >> @@ -50,23 +50,10 @@ >> #include "format.h" >> #include "plugin.h" >> #include "map.h" >> +#include "back-sch.h" >> >> #define SCH_CONTAINER_CONFIGURATION_FILTER "(&(" SCH_CONTAINER_CONFIGURATION_GROUP_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_BASE_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_FILTER_ATTR "=*)(" SCH_CONTAINER_CONFIGURATION_RDN_ATTR "=*))" >> >> -/* The data we ask the map cache to keep, for us, for each set. */ >> -struct backend_set_data { >> - struct backend_shr_set_data common; >> - /* Schema compatibility-specific data. */ >> - Slapi_DN *container_sdn; >> - char *rdn_format; >> - char **attribute_format; >> - bool_t check_access; >> -}; >> -struct backend_entry_data { >> - Slapi_DN *original_entry_dn; >> - Slapi_Entry *e; >> -}; >> - >> /* Read the name of the NIS master. A dummy function for the schema >> * compatibility plugin. */ >> void >> @@ -98,9 +85,18 @@ backend_set_config_free_config_contents(void *data) >> format_free_ref_attr_list(set_data->common.ref_attr_list); >> format_free_ref_attr_list(set_data->common.inref_attr_list); >> free(set_data->common.entry_filter); >> + if (set_data->check_sssd != SCH_SSSD_NONE) { >> + /* Remove association to another set (groups/users) */ >> + if ((set_data->sssd_relevant_set != NULL) && >> + (set_data->sssd_relevant_set->sssd_relevant_set == set_data)) { >> + set_data->sssd_relevant_set->sssd_relevant_set = NULL; >> + set_data->sssd_relevant_set = NULL; >> + } >> + } >> slapi_sdn_free(&set_data->container_sdn); >> free(set_data->rdn_format); >> backend_shr_free_strlist(set_data->attribute_format); >> + free(set_data->sssd_buffer); >> } >> } >> void >> @@ -146,6 +142,12 @@ backend_copy_set_config(const struct backend_set_data *data) >> ret->rdn_format = strdup(data->rdn_format); >> ret->attribute_format = backend_shr_dup_strlist(data->attribute_format); >> ret->check_access = data->check_access; >> + ret->check_sssd = data->check_sssd; >> + ret->sssd_min_id = data->sssd_min_id; >> + ret->sssd_buffer = data->sssd_buffer; >> + ret->sssd_buffer_len = data->sssd_buffer_len; >> + ret->sssd_relevant_set = data->sssd_relevant_set; >> + >> if ((ret->common.group == NULL) || >> (ret->common.set == NULL) || >> (ret->common.bases == NULL) || >> @@ -164,7 +166,7 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, >> const char *group, const char *container, >> bool_t *flag, struct backend_shr_set_data **pret) >> { >> - char **bases, *entry_filter, **attributes, *rdn_format, *dn; >> + char **bases, *entry_filter, **attributes, *rdn_format, *dn, *sssd_min_id, *check_sssd; >> bool_t check_access; >> struct backend_set_data ret; >> Slapi_DN *tmp_sdn; >> @@ -179,6 +181,10 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, >> check_access = backend_shr_get_vattr_boolean(state, e, >> SCH_CONTAINER_CONFIGURATION_ACCESS_ATTR, >> TRUE); >> + check_sssd = backend_shr_get_vattr_str(state, e, >> + SCH_CONTAINER_CONFIGURATION_SSSD_ATTR); >> + sssd_min_id = backend_shr_get_vattr_str(state, e, >> + SCH_CONTAINER_CONFIGURATION_SSSD_MIN_ID_ATTR); >> attributes = backend_shr_get_vattr_strlist(state, e, >> SCH_CONTAINER_CONFIGURATION_ATTR_ATTR); >> /* Populate the returned structure. */ >> @@ -213,6 +219,51 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, >> ret.rdn_format = rdn_format; >> ret.attribute_format = attributes; >> ret.check_access = check_access; >> + >> + if (check_sssd != NULL) { >> + if (strcasecmp(check_sssd, "group") == 0) { >> + ret.check_sssd = SCH_SSSD_GROUP; >> + } else if (strcasecmp(check_sssd, "user") == 0) { >> + ret.check_sssd = SCH_SSSD_USER; >> + } else { >> + ret.check_sssd = SCH_SSSD_NONE; >> + } >> + } else { >> + ret.check_sssd = SCH_SSSD_NONE; >> + } >> + ret.sssd_buffer = NULL; >> + >> + /* Make sure we don't return system users/groups >> + * by limiting lower bound on searches */ >> + ret.sssd_min_id = 1000; /* default in Fedora */ >> + if (sssd_min_id != NULL) { >> + ret.sssd_min_id = atol(sssd_min_id); >> + } >> + >> + if (ret.sssd_min_id == 0) { >> + /* enforce id in case of an error or too low limit */ >> + ret.sssd_min_id = 1000; >> + } >> + >> + if (ret.check_sssd != SCH_SSSD_NONE) { >> + /* Auto-populate attributes based on selected SSSD tree >> + * and add special attribute to track whether the entry requires PAM-based bind */ >> + backend_shr_add_strlist(&ret.attribute_format, "objectClass=extensibleObject"); >> + backend_shr_add_strlist(&ret.attribute_format, "schema-compat-origin=%{schema-compat-origin}"); >> + backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); >> + >> + /* Allocate buffer to be used for getpwnam_r/getgrnam_r requests */ >> + if (ret.check_sssd == SCH_SSSD_USER) { >> + ret.sssd_buffer_len = sysconf(_SC_GETPW_R_SIZE_MAX); >> + } else { >> + ret.sssd_buffer_len = sysconf(_SC_GETGR_R_SIZE_MAX); >> + } >> + if ((long) ret.sssd_buffer_len == -1 ) >> + ret.sssd_buffer_len = 16384; >> + ret.sssd_buffer = malloc(ret.sssd_buffer_len); >> + } >> + >> + ret.sssd_relevant_set = NULL; >> *pret = backend_copy_set_config(&ret); >> free(ret.common.group); >> free(ret.common.set); >> @@ -315,7 +366,7 @@ backend_entry_get_usn(Slapi_PBlock *pb, Slapi_Entry *e, >> } >> >> /* Add operational attributes to a synthetic entry. */ >> -static void >> +void >> backend_set_operational_attributes(Slapi_Entry *e, >> struct plugin_state *state, >> time_t timestamp, > >This function's being made non-static here, but it's not being called >from any new locations. > >> @@ -879,25 +930,6 @@ backend_update_params(Slapi_PBlock *pb, struct plugin_state *state) >> slapi_entry_free(our_entry); >> } >> >> -/* Intercept a search request, and if it belongs to one of our compatibility >> - * trees, answer from our cache before letting the default database have a >> - * crack at it. */ >> -struct backend_search_cbdata { >> - Slapi_PBlock *pb; >> - struct plugin_state *state; >> - char *target, *strfilter, **attrs; >> - int scope, sizelimit, timelimit, attrsonly; >> - bool_t check_access; >> - Slapi_DN *target_dn; >> - Slapi_Filter *filter; >> - >> - bool_t answer; >> - int result; >> - bool_t matched; >> - char *closest_match, *text; >> - int n_entries; >> -}; >> - >> static bool_t >> backend_should_descend(Slapi_DN *this_dn, Slapi_DN *target_dn, int scope) >> { >> @@ -993,11 +1025,17 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, >> struct backend_set_data *set_data; >> Slapi_Entry *set_entry; >> int result, n_entries; >> + int n_entries_sssd; >> const char *ndn; >> >> cbdata = cb_data; >> set_data = backend_data; >> cbdata->check_access = set_data->check_access; >> + cbdata->check_sssd = set_data->check_sssd; >> + cbdata->sssd_min_id = set_data->sssd_min_id; >> + /* If any entries were actually returned by the descending callback, >> + * avoid to look up in sssd even if this set is marked to look up */ >> + n_entries_sssd = cbdata->n_entries; >> >> /* Check the set itself, unless it's also the group, in which case we >> * already evaluated it for this search. */ >> @@ -1054,6 +1092,15 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, >> backend_search_entry_cb, cbdata); >> } >> >> +#ifdef HAVE_SSS_NSS_IDMAP >> + /* If we didn't find an exact match for the entry but asked to look up SSSD, >> + * then try to search SSSD and if successful, return that entry */ >> + if ((n_entries_sssd == cbdata->n_entries) && >> + (cbdata->check_sssd != SCH_SSSD_NONE)) { >> + backend_search_sssd(set_data, cbdata); >> + } >> +#endif >> + >> /* If we didn't find an exact match for the entry, then store this >> * container's DN as the closest match. */ >> if ((!cbdata->matched) && >> @@ -1409,6 +1456,7 @@ backend_bind_cb(Slapi_PBlock *pb) >> struct berval ref; >> struct berval *urls[] = {&ref, NULL}; >> const char *ndn; >> + char *is_sssd_origin = NULL; >> >> if (wrap_get_call_level() > 0) { >> return 0; >> @@ -1418,18 +1466,59 @@ backend_bind_cb(Slapi_PBlock *pb) >> map_rdlock(); >> backend_locate(pb, &data); >> if (data != NULL) { >> - ndn = slapi_sdn_get_ndn(data->original_entry_dn); >> - ref.bv_len = strlen("ldap:///") + strlen(ndn); >> - ref.bv_val = malloc(ref.bv_len + 1); >> - if (ref.bv_val != NULL) { >> - sprintf(ref.bv_val, "ldap:///%s", ndn); >> - slapi_send_ldap_result(pb, LDAP_REFERRAL, >> - NULL, NULL, 0, urls); >> - free(ref.bv_val); >> +#ifdef HAVE_SSS_NSS_IDMAP >> + is_sssd_origin = slapi_entry_attr_get_charptr(data->e, "schema-compat-origin"); >> + if ((is_sssd_origin != NULL) && >> + (strcasecmp(is_sssd_origin, "sssd") == 0)) { >> + ret = backend_sch_do_pam_auth(pb, data->e); >> + if (ret != 0) { >> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, >> + NULL, NULL, 0, NULL); >> + ret = -1; >> + } else { >> + /* >> + * If bind succeeded, change authentication information associated >> + * with this connection. >> + */ >> + if (ret == LDAP_SUCCESS) { >> + ndn = slapi_ch_strdup(slapi_sdn_get_ndn(data->original_entry_dn)); >> + if ((slapi_pblock_set(pb, SLAPI_CONN_DN, (void*)ndn) != 0) || >> + (slapi_pblock_set(pb, SLAPI_CONN_AUTHMETHOD, SLAPD_AUTH_SIMPLE) != 0)) { >> + ret = LDAP_OPERATIONS_ERROR; >> + } else { >> + LDAPControl **reqctrls = NULL; >> + slapi_pblock_get(pb, SLAPI_REQCONTROLS, &reqctrls); >> + if (slapi_control_present(reqctrls, LDAP_CONTROL_AUTH_REQUEST, NULL, NULL)) { >> + slapi_add_auth_response_control(pb, ndn); >> + } >> + } >> + } >> + >> + if (ret == LDAP_SUCCESS) { >> + /* we are handling the result */ >> + slapi_send_ldap_result(pb, ret, NULL, NULL, 0, NULL); >> + /* tell bind code we handled the result */ >> + ret = 0; >> + } >> + } > >This leg's hanging on to the map lock while it calls into PAM. If we >retrieved the two attributes we care about (uid and >schema-compat-origin), and kept a copy of the DN we're going to assign >if the bind succeeds, we could let go of the lock that keeps the "data" >structure from being modified before calling into PAM. > >> } else { >> - slapi_send_ldap_result(pb, LDAP_BUSY, >> - NULL, NULL, 0, NULL); >> +#endif >> + ndn = slapi_sdn_get_ndn(data->original_entry_dn); >> + ref.bv_len = strlen("ldap:///") + strlen(ndn); >> + ref.bv_val = malloc(ref.bv_len + 1); >> + if (ref.bv_val != NULL) { >> + sprintf(ref.bv_val, "ldap:///%s", ndn); >> + slapi_send_ldap_result(pb, LDAP_REFERRAL, >> + NULL, NULL, 0, urls); >> + free(ref.bv_val); >> + } else { >> + slapi_send_ldap_result(pb, LDAP_BUSY, >> + NULL, NULL, 0, NULL); >> + } >> +#ifdef HAVE_SSS_NSS_IDMAP >> } >> + free(is_sssd_origin); >> +#endif >> ret = -1; >> } else { >> if (backend_check_scope_pb(pb)) { > >Please rework this function so that the conditional logic isn't >interspersed with preprocessor logic. It's kind of hard to follow. > >HTH, > >Nalin -- / Alexander Bokovoy From pspacek at redhat.com Tue Jul 23 08:55:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Jul 2013 10:55:05 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1374256500.32040.248.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> Message-ID: <51EE44E9.6010807@redhat.com> On 19.7.2013 19:55, Simo Sorce wrote: > I will reply to the rest of the message later if necessary, still > digesting some of your answers, but I wanted to address the following > first. > > On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >> >> The most important question at the moment is "What can we postpone? >> How >> fragile it can be for shipping it as part of Fedora 20?" Could we >> declare >> DNSSEC support as "technology preview"/"don't use it for anything >> serious"? > > Until we figur out proper management in LDAP we will be a bit stuck, esp > if we want to consider usin the 'somthing' that stores keys instead of > toring them stright in LDAP. > > So maybe we can start with allowing just one server to do DNSSEC and > source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. > as soon as we have that workign we should also have clearer plans about > how we manage keys in LDAP (or elsewhere). -- Petr^2 Spacek From tbabej at redhat.com Tue Jul 23 10:19:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Jul 2013 06:19:08 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <20130722131938.GB15859@redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> <20130719161850.GD18587@redhat.com> <1268663087.2035674.1374496306141.JavaMail.root@redhat.com> <20130722131938.GB15859@redhat.com> Message-ID: <677308821.2353676.1374574748159.JavaMail.root@redhat.com> This improved revision creates ranges of sizes that are multiples of default range size (200000). Tomas -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0076-4-Use-AD-LDAP-probing-to-create-trusted-domain-ID-rang.patch Type: text/x-patch Size: 19773 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jul 23 10:58:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Jul 2013 12:58:29 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51ED50B9.4070101@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ECD8D6.30400@redhat.com> <51ED50B9.4070101@redhat.com> Message-ID: <51EE61D5.7050601@redhat.com> On 07/22/2013 05:33 PM, Ana Krivokapic wrote: > On 07/22/2013 09:01 AM, Martin Kosek wrote: >> On 07/19/2013 11:19 PM, Dmitri Pal wrote: >>> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>>> Originally we wanted to do this change in >>>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>>> because of string freeze. >>>>> >>>>> I guess you can add field suffix to every field from /etc/password >>>>> when you use it in a sentence but that doesn't necessary mean that >>>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>>> directory. The GECOS field value does not, really. >>>> >>>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>>> in fields description/list either. IMO our use case is the same. >>>> It says: >>>> >>>> GECOS This field (sometimes called the "comment field") >>>> [...] >>>> The gcos field in the password file was >>>> [...] >>>> >>>>> Historically correct label would probably be 'GECOS identity' but >>>>> that's not usable today as it's purpose is more general. >>> Do we have tips in the UI? >>> May be we should add them in future to provide extra information about >>> meaning of the field or button. >>> For now I think GECOS would probably be good enough. >>> Adding "field" makes it more precise but looks weird. >> +1 for just "GECOS". Petr showed me both variants in the UI and "GECOS field" >> really looked weird. >> >> Martin>> > > +1 for removing the word 'field'. The phrase 'GECOS field' also exists in the > following files: > > install/ui/test/data/ipa_init_commands.json > install/ui/test/data/ipa_init_objects.json > install/ui/test/data/json_metadata.json > > So it should be fixed there as well. > Fixed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0436-1-Remove-word-field-from-GECOS-param-label.patch Type: text/x-patch Size: 4501 bytes Desc: not available URL: From akrivoka at redhat.com Tue Jul 23 11:12:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 23 Jul 2013 13:12:29 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51EE61D5.7050601@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ECD8D6.30400@redhat.com> <51ED50B9.4070101@redhat.com> <51EE61D5.7050601@redhat.com> Message-ID: <51EE651D.6010208@redhat.com> On 07/23/2013 12:58 PM, Petr Vobornik wrote: > On 07/22/2013 05:33 PM, Ana Krivokapic wrote: >> On 07/22/2013 09:01 AM, Martin Kosek wrote: >>> On 07/19/2013 11:19 PM, Dmitri Pal wrote: >>>> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>>>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>>>> Originally we wanted to do this change in >>>>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>>>> because of string freeze. >>>>>> >>>>>> I guess you can add field suffix to every field from /etc/password >>>>>> when you use it in a sentence but that doesn't necessary mean that >>>>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>>>> directory. The GECOS field value does not, really. >>>>> >>>>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>>>> in fields description/list either. IMO our use case is the same. >>>>> It says: >>>>> >>>>> GECOS This field (sometimes called the "comment field") >>>>> [...] >>>>> The gcos field in the password file was >>>>> [...] >>>>> >>>>>> Historically correct label would probably be 'GECOS identity' but >>>>>> that's not usable today as it's purpose is more general. >>>> Do we have tips in the UI? >>>> May be we should add them in future to provide extra information about >>>> meaning of the field or button. >>>> For now I think GECOS would probably be good enough. >>>> Adding "field" makes it more precise but looks weird. >>> +1 for just "GECOS". Petr showed me both variants in the UI and "GECOS field" >>> really looked weird. >>> >>> Martin>> > >> >> +1 for removing the word 'field'. The phrase 'GECOS field' also exists in the >> following files: >> >> install/ui/test/data/ipa_init_commands.json >> install/ui/test/data/ipa_init_objects.json >> install/ui/test/data/json_metadata.json >> >> So it should be fixed there as well. >> > > Fixed. ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Tue Jul 23 11:30:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Jul 2013 13:30:37 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51E91EB9.3000306@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> Message-ID: <51EE695D.1000206@redhat.com> On 07/19/2013 01:10 PM, Petr Vobornik wrote: > On 07/18/2013 05:29 PM, Jan Cholasta wrote: >> On 18.7.2013 17:26, Martin Kosek wrote: >>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>> Added patch which adds new hidden option no_members to suppress >>>>>> membership >>>>>> processing for commands of all objects that have member attributes. >>>>>> This can be >>>>>> used by the WebUI to prevent member lookups where they are not >>>>>> necessary (as we >>>>>> discussed off-line with Martin and Petr). >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> 1) Should the new option really have "exclude='webui'? I thought >>>>> that Web UI is >>>>> the main and only consumer of this option. >>>> >>>> The 'webui' context doesn't actually exist and the only meaning of >>>> this stanza >>>> is that the option is not shown in the output of the show_mappings >>>> command. >>>> >>>>> >>>>> 2) I would clearly state this is an internal option only, e.g. >>>>> >>>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>>> >>>> No other internal option has this kind of thing in its doc and nobody >>>> will see >>>> it anyway, so we might just leave it like that IMHO. >>> >>> OK. >>> >>>> >>>>> >>>>> 3) It would be nice to state that this option is mutually exclusive >>>>> with --all, >>>>> but given it is internal anyway and there is no central place to >>>>> define it, we >>>>> do not need to do that. >>>> >>>> The options are not really mutually exclusive at this point, they can be >>>> specified together, --all takes precedence. >>> >>> Well, they can be specified together, but the option is then NOOP >>> which could >>> confuse users which may have different expectations. Being explicit >>> helps. >> >> I agree. >> >>> But >>> as I said, in this case this is not a requirement. >> >> I agree as well :-) >> >> Honza >> > > Functional ACK for Honza's patch (didn't break Web UI test suite) > > Attaching Web UI patch. > > It: > 1) Removed --all from _find and _show commands used by search pages. All > displayed attributes should be already included in default attributes. > > 2) Removed search_all_attributes - Not needed since introduction of paging. > > 3) Added --no-members options to search _show commmands. ACK. Pushed both Petr's and Honza's patch to master and ipa-3-2. Martin From simo at redhat.com Tue Jul 23 12:15:50 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Jul 2013 08:15:50 -0400 Subject: [Freeipa-devel] [PATCH] 0109-0110 Support querying AD DC when establishing trust as HTTP/ipa.server principal In-Reply-To: <20130718153733.GX18587@redhat.com> References: <20130718153733.GX18587@redhat.com> Message-ID: <1374581750.15431.4.camel@willson.li.ssimo.org> On Thu, 2013-07-18 at 18:37 +0300, Alexander Bokovoy wrote: > Hi! > > Attached patches make possible to use HTTP/ipa.server at REALM to query AD > DC over LDAP immediately after trust is established. We need this to get > range discovery working prior to creating range for trusted domain. > > The patch 0109 makes KDC hostname cached on ipadb context to avoid > resolving own hostname multiple times. > > The patch 0110 depends on ulc_casemap patches by Nathaniel and makes > exception for HTTP/ipa.server at REALM when TGT is requested and MS-PAC is > asked for -- we force refreshing list of trusted domains here. > > More details are available in the commit logs. I do not think that changing reinit interval is the right thing to do. I would rather pass a boolean that tells reinit to check if we have any trust info, and if not unconditionally try to reinit immediately. I see that you treat the interval sort of like a boolean but then you just race hoping the previous reload w/o trust info happened more than 1 second earlier. I think and explicit "bool force_reload" flag would be much clearer. Otherwise ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Tue Jul 23 13:09:17 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Jul 2013 15:09:17 +0200 Subject: [Freeipa-devel] [PATCH] Two minor IPA KDB MS-PAC fixes Message-ID: <20130723130917.GX18515@hendrix.brq.redhat.com> clang found one branch with undefined variable return and one unused variable. -------------- next part -------------- >From 09962a9a40cd589c4694ecab4b4faa3c39e8a4a3 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Tue, 23 Jul 2013 15:07:39 +0200 Subject: [PATCH 1/2] IPA KDB MS-PAC: return ENOMEM if allocation fails --- daemons/ipa-kdb/ipa_kdb_mspac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 4ddf3e8662bb55bae36777bd95f62b4f7e60c154..12959a89308e800d01c6cbc81a9d0bb5239fd5d9 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1842,6 +1842,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_princ_component(context, ks_client_princ, 0)->length) == 0)) { ipactx = ipadb_get_context(context); if (!ipactx) { + kerr = ENOMEM; goto done; } if (ulc_casecmp(krb5_princ_component(context, ks_client_princ, 1)->data, -- 1.8.3.1 -------------- next part -------------- >From fcefc88a34f8c02f75ad48f484f00438634b9d0e Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Tue, 23 Jul 2013 15:07:52 +0200 Subject: [PATCH 2/2] IPA KDB MS-PAC: remove unused variable --- daemons/ipa-kdb/ipa_kdb_mspac.c | 1 - 1 file changed, 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 12959a89308e800d01c6cbc81a9d0bb5239fd5d9..87a74909602f45fff7b3820f60eca560daaa2642 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1930,7 +1930,6 @@ static char *get_server_netbios_name(struct ipadb_context *ipactx) { char hostname[MAXHOSTNAMELEN + 1]; /* NOTE: this is 64, too little ? */ char *p; - int ret; strncpy(hostname, ipactx->kdc_hostname, MAXHOSTNAMELEN); /* May miss termination */ -- 1.8.3.1 From abokovoy at redhat.com Tue Jul 23 13:11:58 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Jul 2013 16:11:58 +0300 Subject: [Freeipa-devel] [PATCH] 0109-0110 Support querying AD DC when establishing trust as HTTP/ipa.server principal In-Reply-To: <1374581750.15431.4.camel@willson.li.ssimo.org> References: <20130718153733.GX18587@redhat.com> <1374581750.15431.4.camel@willson.li.ssimo.org> Message-ID: <20130723131158.GI15859@redhat.com> On Tue, 23 Jul 2013, Simo Sorce wrote: >On Thu, 2013-07-18 at 18:37 +0300, Alexander Bokovoy wrote: >> Hi! >> >> Attached patches make possible to use HTTP/ipa.server at REALM to query AD >> DC over LDAP immediately after trust is established. We need this to get >> range discovery working prior to creating range for trusted domain. >> >> The patch 0109 makes KDC hostname cached on ipadb context to avoid >> resolving own hostname multiple times. >> >> The patch 0110 depends on ulc_casemap patches by Nathaniel and makes >> exception for HTTP/ipa.server at REALM when TGT is requested and MS-PAC is >> asked for -- we force refreshing list of trusted domains here. >> >> More details are available in the commit logs. > >I do not think that changing reinit interval is the right thing to do. > >I would rather pass a boolean that tells reinit to check if we have any >trust info, and if not unconditionally try to reinit immediately. > >I see that you treat the interval sort of like a boolean but then you >just race hoping the previous reload w/o trust info happened more than 1 >second earlier. > >I think and explicit "bool force_reload" flag would be much clearer. > >Otherwise ack. Attached is modified patch that uses 'bool force_reinit' (as function is called ipadb_reinit_mspac). I tested it together with updated Tomas patch 0076 which relies on these patches so I'm going to commit whole set together. -- / Alexander Bokovoy -------------- next part -------------- >From 620736888642102f32ad68f8a28a305488bcc401 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 18 Jul 2013 13:32:42 +0300 Subject: [PATCH 2/4] ipa-kdb: reinit mspac on HTTP TGT acquisition to aid trust-add case When trust is established, we also create idrange for the trusted domain. With FreeIPA 3.3 these ranges can have different types, and in order to detect which one is to create, we need to do lookup at AD LDAP server. Such lookup requires authenticated bind. We cannot bind as user because IPA framework operates under constrained delegation using the user's credentials and allowing HTTP/ipa.server at REALM to impersonate the user against trusted domain's services would require two major things: - first, as we don't really know exact AD LDAP server names (any AD DC can be used), constrained delegation would have to be defined against a wild-card - second, constrained delegation requires that target principal exists in IPA LDAP as DN. These two together limit use of user's ticket for the purpose of IPA framework looking up AD LDAP. Additionally, immediately after trust is established, issuing TGT with MS-PAC to HTTP/ipa.server at REALM may fail due to the fact that KDB driver did not yet refreshed its list of trusted domains -- we have limited refresh rate of 60 seconds by default. This patch makes possible to force re-initialization of trusted domains' view in KDB driver if we are asked for TGT for HTTP/ipa.server at REALM. We will need to improve refresh of trusted domains' view in KDB driver in future to notice changes in cn=etc,$SUFFIX tree automatically. This improvement is tracked in https://fedorahosted.org/freeipa/ticket/1302 and https://fedorahosted.org/freeipa/ticket/3626 Part of https://fedorahosted.org/freeipa/ticket/3649 --- daemons/ipa-kdb/ipa_kdb.c | 4 ++-- daemons/ipa-kdb/ipa_kdb.h | 2 +- daemons/ipa-kdb/ipa_kdb_mspac.c | 29 ++++++++++++++++++++++++++--- 3 files changed, 29 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 51b879c..5e4d047 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -393,8 +393,8 @@ int ipadb_get_connection(struct ipadb_context *ipactx) goto done; } - /* get adtrust options */ - ret = ipadb_reinit_mspac(ipactx); + /* get adtrust options using default refresh interval */ + ret = ipadb_reinit_mspac(ipactx, false); if (ret && ret != ENOENT) { /* TODO: log that there is an issue with adtrust settings */ } diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index a611bc2..f4d3555 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -250,7 +250,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_authdata **tgt_auth_data, krb5_authdata ***signed_auth_data); -krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx); +krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, bool force_reinit); void ipadb_mspac_struct_free(struct ipadb_mspac **mspac); diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index d6c4f9a..6ffab45 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -24,6 +24,7 @@ #include "ipa_mspac.h" #include #include +#include #include "util/time.h" #include "gen_ndr/ndr_krb5pac.h" @@ -1282,7 +1283,8 @@ static struct ipadb_adtrusts *get_domain_from_realm_update(krb5_context context, return NULL; } - kerr = ipadb_reinit_mspac(ipactx); + /* re-init MS-PAC info using default update interval */ + kerr = ipadb_reinit_mspac(ipactx, false); if (kerr != 0) { return NULL; } @@ -1805,8 +1807,10 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code kerr; krb5_pac pac = NULL; krb5_data pac_data; + struct ipadb_context *ipactx; bool with_pac; bool with_pad; + int result; /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf @@ -1831,6 +1835,22 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { + /* Be aggressive here: special case for discovering range type + * immediately after establishing the trust by IPA framework */ + if ((krb5_princ_size(context, ks_client_princ) == 2) && + (strncmp(krb5_princ_component(context, ks_client_princ, 0)->data, "HTTP", + krb5_princ_component(context, ks_client_princ, 0)->length) == 0)) { + ipactx = ipadb_get_context(context); + if (!ipactx) { + goto done; + } + if (ulc_casecmp(krb5_princ_component(context, ks_client_princ, 1)->data, + krb5_princ_component(context, ks_client_princ, 1)->length, + ipactx->kdc_hostname, strlen(ipactx->kdc_hostname), + NULL, NULL, &result) == 0) { + kerr = ipadb_reinit_mspac(ipactx, true); + } + } kerr = ipadb_get_pac(context, client, &pac); if (kerr != 0 && kerr != ENOENT) { @@ -2155,7 +2175,7 @@ done: return ret; } -krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) +krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, bool force_reinit) { char *dom_attrs[] = { "ipaNTFlatName", "ipaNTFallbackPrimaryGroup", @@ -2174,7 +2194,10 @@ krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx) * avoid heavy load on the directory server if there are lots of requests * from domains which we do not trust. */ now = time(NULL); - if (ipactx->mspac != NULL && now > ipactx->mspac->last_update && + + if (ipactx->mspac != NULL && + (force_reinit == false) && + (now > ipactx->mspac->last_update) && (now - ipactx->mspac->last_update) < 60) { return 0; } -- 1.8.3.1 From abokovoy at redhat.com Tue Jul 23 13:26:21 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Jul 2013 16:26:21 +0300 Subject: [Freeipa-devel] [PATCH] Two minor IPA KDB MS-PAC fixes In-Reply-To: <20130723130917.GX18515@hendrix.brq.redhat.com> References: <20130723130917.GX18515@hendrix.brq.redhat.com> Message-ID: <20130723132621.GJ15859@redhat.com> On Tue, 23 Jul 2013, Jakub Hrozek wrote: >clang found one branch with undefined variable return and one unused >variable. ACK. Pushed both to master together with my 0109-0111 and Tomas' 0076 as your patches are on top of mine. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Jul 23 13:28:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Jul 2013 16:28:00 +0300 Subject: [Freeipa-devel] [PATCH 0076] Use AD LDAP probing to create trusted domain ID range In-Reply-To: <677308821.2353676.1374574748159.JavaMail.root@redhat.com> References: <2056822.DtTZpzeFNt@thinkpad7.brq.redhat.com> <1977145.ymX7t44ZUj@thinkpad7.brq.redhat.com> <20130719161850.GD18587@redhat.com> <1268663087.2035674.1374496306141.JavaMail.root@redhat.com> <20130722131938.GB15859@redhat.com> <677308821.2353676.1374574748159.JavaMail.root@redhat.com> Message-ID: <20130723132800.GK15859@redhat.com> On Tue, 23 Jul 2013, Tomas Babej wrote: >This improved revision creates ranges of sizes that are multiples of default range size (200000). ACK, works fine. Pushed to master. -- / Alexander Bokovoy From pvoborni at redhat.com Tue Jul 23 13:28:28 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Jul 2013 15:28:28 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51EE2A93.10409@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ED27BC.2030005@redhat.com> <51EDC0E0.1050602@redhat.com> <51EE2A93.10409@redhat.com> Message-ID: <51EE84FC.1050102@redhat.com> On 07/23/2013 09:02 AM, Martin Kosek wrote: > On 07/23/2013 01:31 AM, Dmitri Pal wrote: >> On 07/22/2013 08:38 AM, Petr Vobornik wrote: >>> On 07/19/2013 11:19 PM, Dmitri Pal wrote: >>>> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>>>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: >>>>>> Disclaimer: I have no strong feelings in this matter, it just looks >>>>>> weird to me, so I'm OK with not doing it if it's general consensus. >>>>>> Originally we wanted to do this change in >>>>>> https://fedorahosted.org/freeipa/ticket/3569 but it was not done >>>>>> because of string freeze. >>>>>> >>>>>> I guess you can add field suffix to every field from /etc/password >>>>>> when you use it in a sentence but that doesn't necessary mean that >>>>> You can. But gid exists as a concept beyond /etc/passwd. So does home >>>>> directory. The GECOS field value does not, really. >>>>> >>>>>> it's its name. man 5 passwd doesn't use word 'field' next to GECOS >>>>>> in fields description/list either. IMO our use case is the same. >>>>> It says: >>>>> >>>>> GECOS This field (sometimes called the "comment field") >>>>> [...] >>>>> The gcos field in the password file was >>>>> [...] >>>>> >>>>>> Historically correct label would probably be 'GECOS identity' but >>>>>> that's not usable today as it's purpose is more general. >>> >>>> Do we have tips in the UI? >>>> May be we should add them in future to provide extra information about >>>> meaning of the field or button. >>> >>> We do, but UX is not the best. 'doc' defined in .py files is displayed >>> as a textbox tooltip. This feature is not apparent and for most of the >>> fields the tooltip is the same as label. >>> >>> There is an idea to display a question mark icon next to textboxes to >>> draw an attention to a presence of the doc text and provide it in a >>> tooltip. >>> >>> I like the way how it's done in Alchemy UI: >>> http://www.ui-alchemy.org/form You can notice there an additional >>> information (string length limitation, example...) when field is focused. >>> >>> I went through open tickets and found few which touches the topic: >>> - https://fedorahosted.org/freeipa/ticket/2912 [RFE] [Web UI] Use doc >>> as field's tooltip instead of label >>> * Seems to be already implemented. > > Then please close it and move it to the milestone where it was closed (if > possible). > >>> - https://fedorahosted.org/freeipa/ticket/2413 [RFE]: add in UI >>> examples of what is the requested field >>> - https://fedorahosted.org/freeipa/ticket/3661 [RFE] IPA Web UI: When >>> adding new reverse zone in DNS there could be an example of expected >>> address format >>> * Looks like duplicate of #2413 > > Right, please proceed with closing as duplicate then. I would prefer leaving > only ticket 2413 open instead of changing description of 2912 though. > > Martin Resolution: * #3661, #2413 closed. * New ticket https://fedorahosted.org/freeipa/ticket/3812 for the UX enhancement. > >>> >>> IMO we should close #2413 and maybe #2912 or change #2912 to cover the >>> above mentioned proposals (in case of agreement). >>> >>>> For now I think GECOS would probably be good enough. >>>> Adding "field" makes it more precise but looks weird. >>>> >>> >>> >> Sounds reasonable. >> >> > -- Petr Vobornik From pvoborni at redhat.com Tue Jul 23 13:34:33 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Jul 2013 15:34:33 +0200 Subject: [Freeipa-devel] [PATCH] 436 Remove word 'field' from GECOS param label In-Reply-To: <51EE651D.6010208@redhat.com> References: <51E926B9.4000108@redhat.com> <20130719122021.GI1972@redhat.com> <51E93C7D.5010600@redhat.com> <20130719132640.GL1972@redhat.com> <51E9AD6A.80104@redhat.com> <51ECD8D6.30400@redhat.com> <51ED50B9.4070101@redhat.com> <51EE61D5.7050601@redhat.com> <51EE651D.6010208@redhat.com> Message-ID: <51EE8669.6070108@redhat.com> On 07/23/2013 01:12 PM, Ana Krivokapic wrote: > On 07/23/2013 12:58 PM, Petr Vobornik wrote: >> On 07/22/2013 05:33 PM, Ana Krivokapic wrote: >>> On 07/22/2013 09:01 AM, Martin Kosek wrote: >>>> On 07/19/2013 11:19 PM, Dmitri Pal wrote: >>>>> On 07/19/2013 09:26 AM, Jan Pazdziora wrote: >>>>>> On Fri, Jul 19, 2013 at 03:17:49PM +0200, Petr Vobornik wrote: snip >>>>> For now I think GECOS would probably be good enough. >>>>> Adding "field" makes it more precise but looks weird. >>>> +1 for just "GECOS". Petr showed me both variants in the UI and "GECOS field" >>>> really looked weird. >>>> >>> >>> +1 for removing the word 'field'. The phrase 'GECOS field' also exists in the >>> following files: >>> >>> install/ui/test/data/ipa_init_commands.json >>> install/ui/test/data/ipa_init_objects.json >>> install/ui/test/data/json_metadata.json >>> >>> So it should be fixed there as well. >>> >> >> Fixed. > > ACK > Pushed to master. -- Petr Vobornik From pvoborni at redhat.com Tue Jul 23 13:35:07 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Jul 2013 15:35:07 +0200 Subject: [Freeipa-devel] [PATCH] 430 Break long words in notification area In-Reply-To: <51ED4D7D.7060708@redhat.com> References: <51E7CA4A.7000408@redhat.com> <51ED4D7D.7060708@redhat.com> Message-ID: <51EE868B.5030208@redhat.com> On 07/22/2013 05:19 PM, Ana Krivokapic wrote: > On 07/18/2013 12:58 PM, Petr Vobornik wrote: >> Long words (ie. service principal) breaks out of notification area. It doesn't >> look good. Patch adds word-wrap to break them to multiple pieces. >> >> Reproduction: modify a service in Web UI >> > > ACK > Pushed to master. -- Petr Vobornik From simo at redhat.com Tue Jul 23 14:31:58 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Jul 2013 10:31:58 -0400 Subject: [Freeipa-devel] [PATCH] 0109-0110 Support querying AD DC when establishing trust as HTTP/ipa.server principal In-Reply-To: <20130723131158.GI15859@redhat.com> References: <20130718153733.GX18587@redhat.com> <1374581750.15431.4.camel@willson.li.ssimo.org> <20130723131158.GI15859@redhat.com> Message-ID: <1374589918.15431.7.camel@willson.li.ssimo.org> On Tue, 2013-07-23 at 16:11 +0300, Alexander Bokovoy wrote: > On Tue, 23 Jul 2013, Simo Sorce wrote: > >On Thu, 2013-07-18 at 18:37 +0300, Alexander Bokovoy wrote: > >> Hi! > >> > >> Attached patches make possible to use HTTP/ipa.server at REALM to query AD > >> DC over LDAP immediately after trust is established. We need this to get > >> range discovery working prior to creating range for trusted domain. > >> > >> The patch 0109 makes KDC hostname cached on ipadb context to avoid > >> resolving own hostname multiple times. > >> > >> The patch 0110 depends on ulc_casemap patches by Nathaniel and makes > >> exception for HTTP/ipa.server at REALM when TGT is requested and MS-PAC is > >> asked for -- we force refreshing list of trusted domains here. > >> > >> More details are available in the commit logs. > > > >I do not think that changing reinit interval is the right thing to do. > > > >I would rather pass a boolean that tells reinit to check if we have any > >trust info, and if not unconditionally try to reinit immediately. > > > >I see that you treat the interval sort of like a boolean but then you > >just race hoping the previous reload w/o trust info happened more than 1 > >second earlier. > > > >I think and explicit "bool force_reload" flag would be much clearer. > > > >Otherwise ack. > Attached is modified patch that uses 'bool force_reinit' (as function is > called ipadb_reinit_mspac). > > I tested it together with updated Tomas patch 0076 which relies on these > patches so I'm going to commit whole set together. LGTM, please proceed. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Tue Jul 23 14:54:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Jul 2013 16:54:35 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51EE695D.1000206@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> <51EE695D.1000206@redhat.com> Message-ID: <51EE992B.4070109@redhat.com> On 07/23/2013 01:30 PM, Martin Kosek wrote: > On 07/19/2013 01:10 PM, Petr Vobornik wrote: >> On 07/18/2013 05:29 PM, Jan Cholasta wrote: >>> On 18.7.2013 17:26, Martin Kosek wrote: >>>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>>> Added patch which adds new hidden option no_members to suppress >>>>>>> membership >>>>>>> processing for commands of all objects that have member attributes. >>>>>>> This can be >>>>>>> used by the WebUI to prevent member lookups where they are not >>>>>>> necessary (as we >>>>>>> discussed off-line with Martin and Petr). >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> 1) Should the new option really have "exclude='webui'? I thought >>>>>> that Web UI is >>>>>> the main and only consumer of this option. >>>>> >>>>> The 'webui' context doesn't actually exist and the only meaning of >>>>> this stanza >>>>> is that the option is not shown in the output of the show_mappings >>>>> command. >>>>> >>>>>> >>>>>> 2) I would clearly state this is an internal option only, e.g. >>>>>> >>>>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>>>> >>>>> No other internal option has this kind of thing in its doc and nobody >>>>> will see >>>>> it anyway, so we might just leave it like that IMHO. >>>> >>>> OK. >>>> >>>>> >>>>>> >>>>>> 3) It would be nice to state that this option is mutually exclusive >>>>>> with --all, >>>>>> but given it is internal anyway and there is no central place to >>>>>> define it, we >>>>>> do not need to do that. >>>>> >>>>> The options are not really mutually exclusive at this point, they can be >>>>> specified together, --all takes precedence. >>>> >>>> Well, they can be specified together, but the option is then NOOP >>>> which could >>>> confuse users which may have different expectations. Being explicit >>>> helps. >>> >>> I agree. >>> >>>> But >>>> as I said, in this case this is not a requirement. >>> >>> I agree as well :-) >>> >>> Honza >>> >> >> Functional ACK for Honza's patch (didn't break Web UI test suite) >> >> Attaching Web UI patch. >> >> It: >> 1) Removed --all from _find and _show commands used by search pages. All >> displayed attributes should be already included in default attributes. >> >> 2) Removed search_all_attributes - Not needed since introduction of paging. >> >> 3) Added --no-members options to search _show commmands. > > ACK. Pushed both Petr's and Honza's patch to master and ipa-3-2. > > Martin These patches sometimes add the attribute "no_members" to groups, which results in 7 tests being broken like this: ====================================================================== FAIL: test_cli.TestCLIParsing.test_group_add ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/test_cmdline/test_cli.py", line 73, in test_group_add version=API_VERSION) File "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/test_cmdline/test_cli.py", line 24, in check_command util.assert_deepequal(kw_expected, kw_got) File "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/util.py", line 338, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. missing keys = [] extra keys = ['no_members'] expected = {'all': False, 'cn': u'tgroup1', 'raw': False, 'version': u'2.62', 'external': False, 'nonposix': False, 'description': u'Test group'} got = {'all': False, 'description': u'Test group', 'no_members': False, 'raw': False, 'version': u'2.62', 'external': False, 'nonposix': False, 'cn': u'tgroup1'} path = () -- Petr? From nalin at redhat.com Tue Jul 23 14:59:43 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 23 Jul 2013 10:59:43 -0400 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130723071547.GF15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> Message-ID: <20130723145943.GA26555@redhat.com> On Tue, Jul 23, 2013 at 10:15:47AM +0300, Alexander Bokovoy wrote: > On Tue, 23 Jul 2013, Nalin Dahyabhai wrote: > >Apologies for the delay. > Thanks for the review! > > One short comment -- PAM code is from PAM pass-through plugin from > 389-ds. That's the reason why its code doesn't follow slapi-nis way and > why it has that license. I tried to keep it mostly intact to share > changes but looking at git log it gets roughly two commits per year so > maybe it is better to rework it completely. That'd be my preference. Other than knowing how to map specific PAM error codes to LDAP-level errors, there doesn't seem to be a lot of magic that needs to be preserved in there. > I'll address other comments and will send updated version for the > review today. This was my first sizable SLAPI code so errors are > inevitable. No worries. I think there's already a lot in there that's right. I've been thinking about the patch some more, and I need to revise a couple of my comments. [snip] > >>+ slapi_entry_add_string(entry, > >>+ "uid", user_name); > > > >If is_uid is true, this is a numeric string. Intentional? Given that group entries are being constructed using group member information, which is always login names, I guess it isn't. [snip] > >>+ for (i=0; grp.gr_mem[i]; i++) { > >>+ slapi_entry_add_string(entry, "memberUid", > >>+ slapi_ch_smprintf("uid=%s,%s", grp.gr_mem[i], sdn)); > >>+ } > > > >The "memberUid" attribute doesn't typically contain DNs. Did you mean > >to use "member" here? Or to just use the user login name for the value? This probably wants to set "memberUid" to the grp.gr_mem element's value, because if we construct a "member" DN and expect the plugin's configured logic to dereference it and pull out the UID value, and the plugin attempts to read the entry with that DN by doing a search with scope=base to find the entry, I don't think it'll trigger the logic that would create that entry in the cache. That, and in compat trees we're generally in the business of unrolling group memberships anyway. Cheers, Nalin From pviktori at redhat.com Tue Jul 23 15:01:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Jul 2013 17:01:47 +0200 Subject: [Freeipa-devel] [PATCHES] 143-147 Improve performance with large groups In-Reply-To: <51EE992B.4070109@redhat.com> References: <51CC525D.60702@redhat.com> <51CC58E5.8070500@redhat.com> <51CC5AC0.1090702@redhat.com> <51CC5B92.5040905@redhat.com> <51CC617F.9090305@redhat.com> <20130708072254.GG3956@redhat.com> <20130711095827.GH18587@redhat.com> <51DE82E6.4020307@redhat.com> <20130711101552.GI18587@redhat.com> <51E3F643.1080909@redhat.com> <51E3FC84.7050407@redhat.com> <51E4138A.5060508@redhat.com> <51E80176.9050804@redhat.com> <51E804C1.2090804@redhat.com> <51E80823.6020605@redhat.com> <51E8091C.90109@redhat.com> <51E809E6.4040103@redhat.com> <51E91EB9.3000306@redhat.com> <51EE695D.1000206@redhat.com> <51EE992B.4070109@redhat.com> Message-ID: <51EE9ADB.7030701@redhat.com> On 07/23/2013 04:54 PM, Petr Viktorin wrote: > On 07/23/2013 01:30 PM, Martin Kosek wrote: >> On 07/19/2013 01:10 PM, Petr Vobornik wrote: >>> On 07/18/2013 05:29 PM, Jan Cholasta wrote: >>>> On 18.7.2013 17:26, Martin Kosek wrote: >>>>> On 07/18/2013 05:22 PM, Jan Cholasta wrote: >>>>>> On 18.7.2013 17:07, Martin Kosek wrote: >>>>>>> On 07/18/2013 04:53 PM, Jan Cholasta wrote: >>>>>>>> Added patch which adds new hidden option no_members to suppress >>>>>>>> membership >>>>>>>> processing for commands of all objects that have member attributes. >>>>>>>> This can be >>>>>>>> used by the WebUI to prevent member lookups where they are not >>>>>>>> necessary (as we >>>>>>>> discussed off-line with Martin and Petr). >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> 1) Should the new option really have "exclude='webui'? I thought >>>>>>> that Web UI is >>>>>>> the main and only consumer of this option. >>>>>> >>>>>> The 'webui' context doesn't actually exist and the only meaning of >>>>>> this stanza >>>>>> is that the option is not shown in the output of the show_mappings >>>>>> command. >>>>>> >>>>>>> >>>>>>> 2) I would clearly state this is an internal option only, e.g. >>>>>>> >>>>>>> + doc=_('INTERNAL: suppress processing of membership attributes.'), >>>>>> >>>>>> No other internal option has this kind of thing in its doc and nobody >>>>>> will see >>>>>> it anyway, so we might just leave it like that IMHO. >>>>> >>>>> OK. >>>>> >>>>>> >>>>>>> >>>>>>> 3) It would be nice to state that this option is mutually exclusive >>>>>>> with --all, >>>>>>> but given it is internal anyway and there is no central place to >>>>>>> define it, we >>>>>>> do not need to do that. >>>>>> >>>>>> The options are not really mutually exclusive at this point, they >>>>>> can be >>>>>> specified together, --all takes precedence. >>>>> >>>>> Well, they can be specified together, but the option is then NOOP >>>>> which could >>>>> confuse users which may have different expectations. Being explicit >>>>> helps. >>>> >>>> I agree. >>>> >>>>> But >>>>> as I said, in this case this is not a requirement. >>>> >>>> I agree as well :-) >>>> >>>> Honza >>>> >>> >>> Functional ACK for Honza's patch (didn't break Web UI test suite) >>> >>> Attaching Web UI patch. >>> >>> It: >>> 1) Removed --all from _find and _show commands used by search pages. All >>> displayed attributes should be already included in default attributes. >>> >>> 2) Removed search_all_attributes - Not needed since introduction of >>> paging. >>> >>> 3) Added --no-members options to search _show commmands. >> >> ACK. Pushed both Petr's and Honza's patch to master and ipa-3-2. >> >> Martin > > These patches sometimes add the attribute "no_members" to groups, which > results in 7 tests being broken like this: > > ====================================================================== > FAIL: test_cli.TestCLIParsing.test_group_add > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/test_cmdline/test_cli.py", > line 73, in test_group_add > version=API_VERSION) > File > "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/test_cmdline/test_cli.py", > line 24, in check_command > util.assert_deepequal(kw_expected, kw_got) > File > "/var/lib/jenkins/workspace/freeipa-unittests-f19-devel/ipatests/util.py", > line 338, in assert_deepequal > doc, sorted(missing), sorted(extra), expected, got, stack > AssertionError: assert_deepequal: dict keys mismatch. > > missing keys = [] > extra keys = ['no_members'] > expected = {'all': False, 'cn': u'tgroup1', 'raw': False, 'version': > u'2.62', 'external': False, 'nonposix': False, 'description': u'Test > group'} > got = {'all': False, 'description': u'Test group', 'no_members': > False, 'raw': False, 'version': u'2.62', 'external': False, 'nonposix': > False, 'cn': u'tgroup1'} > path = () > Correction: they don't add the attribute to output. It's just that the CLI tests need to be updated with the new option. -- Petr? From akrivoka at redhat.com Tue Jul 23 15:50:00 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 23 Jul 2013 17:50:00 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51E7D2EE.4050501@redhat.com> References: <51E7D2AD.7020600@redhat.com> <51E7D2EE.4050501@redhat.com> Message-ID: <51EEA628.3020707@redhat.com> On 07/18/2013 01:35 PM, Petr Vobornik wrote: > On 07/18/2013 01:34 PM, Petr Vobornik wrote: >> [PATCH] 431 Web UI integration tests: Add trust tests >> >> [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions >> >> [PATCH] 433 Web UI integration tests: Verify data after add and mod >> >> [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps >> >> Heavily inspired by code from xmlrpc tests. >> >> To obtain ranges, this patch also adds method to execute FreeIPA command >> through Web UI. >> It uses Web UI instead of ipalib so it doesn't need to care about >> authentication on a test-runner machine. >> >> All: https://fedorahosted.org/freeipa/ticket/3744 > > And now the patches... > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patch 431: - In case 'ipa-adtrust-install' has not been run on the system, but 'has_trusts' is configured in 'ui_test.conf', trust tests fail. I suggest checking for 'ipa-adtrust-install' with 'adtrust_is_enabled' command and then skipping tests if trusts are not enabled. Patch 432: - Docstrings for 'has_ca()' and 'has_dns()' state that 'FreeIPA server was installed *without* CA/DNS' when they shoud state *with*. Patch 433: - Please also add docstrings for newly added methods. - The long 'if' statement in 'validate_fields()' can be shortened by using the 'in' keyword instead of individual string comparisons. For example: elif ftype in ('textbox', 'password', 'combobox'): actual = self.get_field_value(key, parent, 'input') - IIUC, the code in validate_fields() compares lists irrespective of element order. If this is the case, it can be replaced by simply 'sorted(expected) == sorted(actual)'. - In 'basic_crud()', shouldn't validate_fields with 'add_v' be called right after 'add_record'? The way it is now, data only gets validated in case of data modification, but not after initial addition. Patch 434: - The "if 'ipasecondarybaserid' in idrange" block should be nested under the "if 'ipasecondarybaserid' in idrange" block, since it assumes that the 'base_rid' variable is set. - Please remove trailing semicolons. General comments (these comments are by no means a requirement, and they are not a reason for a NACK, just a "nice to have"): - Some methods have unused parameters (e.g. validate_fields, basic_crud) - Some methods define variables which shadow Python built-ins of the same name (e.g. type, all). This can be a problem if you later want to use the built-in. - It would be nice to make at least newly added code PEP8 compliant. The 'pep8' utility can be used to easily check any python file for PEP8 compliance: $ sudo yum install python-pep8 $ pep8 /path/to/script.py -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Jul 23 15:59:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Jul 2013 17:59:43 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51EEA628.3020707@redhat.com> References: <51E7D2AD.7020600@redhat.com> <51E7D2EE.4050501@redhat.com> <51EEA628.3020707@redhat.com> Message-ID: <51EEA86F.3040703@redhat.com> On 07/23/2013 05:50 PM, Ana Krivokapic wrote: > On 07/18/2013 01:35 PM, Petr Vobornik wrote: >> On 07/18/2013 01:34 PM, Petr Vobornik wrote: >>> [PATCH] 431 Web UI integration tests: Add trust tests >>> >>> [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions >>> >>> [PATCH] 433 Web UI integration tests: Verify data after add and mod >>> >>> [PATCH] 434 Web UI integration tests: Compute range sizes to avoid >>> overlaps >>> >>> Heavily inspired by code from xmlrpc tests. >>> >>> To obtain ranges, this patch also adds method to execute FreeIPA command >>> through Web UI. >>> It uses Web UI instead of ipalib so it doesn't need to care about >>> authentication on a test-runner machine. >>> >>> All: https://fedorahosted.org/freeipa/ticket/3744 >> >> And now the patches... >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Patch 431: > - In case 'ipa-adtrust-install' has not been run on the system, but > 'has_trusts' is configured in 'ui_test.conf', trust tests fail. I > suggest checking for 'ipa-adtrust-install' with 'adtrust_is_enabled' > command and then skipping tests if trusts are not enabled. > > Patch 432: > - Docstrings for 'has_ca()' and 'has_dns()' state that 'FreeIPA server > was installed *without* CA/DNS' when they shoud state *with*. > > Patch 433: > - Please also add docstrings for newly added methods. > - The long 'if' statement in 'validate_fields()' can be shortened by > using the 'in' keyword instead of individual string comparisons. For > example: > elif ftype in ('textbox', 'password', 'combobox'): > actual = self.get_field_value(key, parent, 'input') > - IIUC, the code in validate_fields() compares lists irrespective of > element order. If this is the case, it can be replaced by simply > 'sorted(expected) == sorted(actual)'. > - In 'basic_crud()', shouldn't validate_fields with 'add_v' be called > right after 'add_record'? The way it is now, data only gets validated in > case of data modification, but not after initial addition. > > Patch 434: > - The "if 'ipasecondarybaserid' in idrange" block should be nested under > the "if 'ipasecondarybaserid' in idrange" block, since it assumes that > the 'base_rid' variable is set. > - Please remove trailing semicolons. > > > General comments (these comments are by no means a requirement, and they > are not a reason for a NACK, just a "nice to have"): > - Some methods have unused parameters (e.g. validate_fields, basic_crud) > - Some methods define variables which shadow Python built-ins of the > same name (e.g. type, all). This can be a problem if you later want to > use the built-in. > - It would be nice to make at least newly added code PEP8 compliant. The > 'pep8' utility can be used to easily check any python file for PEP8 > compliance: > $ sudo yum install python-pep8 > $ pep8 /path/to/script.py It can also check only your changes: git diff -U0 origin/master.. | pep8 --diff -- Petr? From pvoborni at redhat.com Tue Jul 23 16:09:13 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Jul 2013 18:09:13 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51ED45CB.7080604@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> <51ED45CB.7080604@redhat.com> Message-ID: <51EEAAA9.2020001@redhat.com> On 07/22/2013 04:46 PM, Ana Krivokapic wrote: > On 07/18/2013 09:47 AM, Petr Vobornik wrote: >> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >>> >> >> Hello, >> >> 1) IMO we should not create attribute which is just a negation of another. >> >> 2) We should add set_enabled method to base widget. Existing set_enabled >> methods should use it and maintain widget output consistent with the attribute >> (ie. one should not directly set the attr and should use set_enabled instead). >> The method should be also callable when content is not yet created. >> get_enabled methods might become unnecessary - one can get the state form >> 'enabled' attribute. >> > > The attached updated patch implements the following changes: > > 1) set_enabled method has been added to the base widget class. > 2) get_enabled/is_enabled methods have been removed. > 3) Widget classes that inherit from the base widget class override the > set_enabled method where necessary. > 4) Using 'enabled: true/false' in the widget definition should now work > correctly for all types of widgets. > > Thanks. 1. set_enabled method in input_widget uses `that.input`. Input widget is a base class which doesn't set the property and therefore we can't be certain that the descendant will set it. Also it may break when you call set_enabled(val) before create() . We should test for `that.input` presence. Same content-created test should be perform on other places: widget.js:1017,1147,2006 2. The changes in option_widget_base break disabling if user doesn't have write-rights. (can be reproduced when navigated (by manual change of url) to service in self-service. Note the differences between read_only, writable and enabled: * read_only - reflects metadata * writable - reflects ACL * enabled - context specific read_only and writable don't offer edit interface (label instead of textbox). Enabled controls disabled state of textbox. For some widgets the result might be the same (radios, checkboxes). option_widget_base.set_enabled should be changed. The mixin overwrites the original method and therefore doesn't set 'enabled' property. 3. multiple_choice_section.set_enabled should be renamed. It's related to individual choices and not the widget itself. And then new set_enabled should be added which would call the old one for each choice. 4. widget.js:3870 - not sure if it's needed but if so, one should also change `action_clicked` method. -- Petr Vobornik From jcholast at redhat.com Tue Jul 23 16:26:20 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Jul 2013 18:26:20 +0200 Subject: [Freeipa-devel] [PATCH] 161 Use configured dogtag LDAP port instead of default one when renewing certs In-Reply-To: <1374507656.32040.268.camel@willson.li.ssimo.org> References: <51ED5176.4060605@redhat.com> <1374507656.32040.268.camel@willson.li.ssimo.org> Message-ID: <51EEAEAC.2080905@redhat.com> On 22.7.2013 17:40, Simo Sorce wrote: > On Mon, 2013-07-22 at 17:36 +0200, Jan Cholasta wrote: >> if nickname == 'subsystemCert cert-pki-ca': >> - update_people_entry('pkidbuser', cert) >> + update_people_entry(dogtag_uri, 'pkidbuser', cert) >> >> > This is probably wrong, there is no pkidbuser in old instances. > > My subsystemCert has a subject of "CN=CA Subsystem,O=REALM" and this > cert is associated to an object named: > uid=CA--9443,ou=people,o=ipaca > > I think you need to search the db to find the right object(s) to update. Right. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-161.1-Fix-certificate-renewal-scripts-to-work-with-separat.patch Type: text/x-patch Size: 5811 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 24 08:12:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Jul 2013 10:12:43 +0200 Subject: [Freeipa-devel] [PATCHES] 149-151 Ask for PKCS#12 password interactively In-Reply-To: <51E3B981.3010207@redhat.com> References: <51DC02C3.8040507@redhat.com> <51DEFEC6.3040006@redhat.com> <51DF9C88.8050401@redhat.com> <38174590.7AT5dsIgTR@thinkpad7.brq.redhat.com> <51E3B981.3010207@redhat.com> Message-ID: <51EF8C7B.30308@redhat.com> On 07/15/2013 10:57 AM, Jan Cholasta wrote: > On 12.7.2013 10:19, Tomas Babej wrote: >> Just a nitpick: >> >> + # If any of the PKCS#12 options are selected, all are required. >> >> + pkcs12_req = (options.dirsrv_pkcs12, options.http_pkcs12) >> >> + pkcs12_opt = (options.pkinit_pkcs12,) >> >> + if any(pkcs12_req + pkcs12_opt) and not all(pkcs12_req): >> >> parser.error("All PKCS#12 options are required if any are used.") >> >> This error message is somewhat misleading, since --pkinit-pkcs12 options >> is not required. > > Fixed. > > Updated patches attached. > > Honza > The updated error message looks OK. ACK, pushed all 3 patches to master, ipa-3-2. Martin From tbabej at redhat.com Wed Jul 24 10:39:07 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Jul 2013 12:39:07 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount Message-ID: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> Hi, this fixes the https://fedorahosted.org/freeipa/ticket/3811 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0079-Change-shebang-to-absolute-path-in-ipa-client-automo.patch Type: text/x-patch Size: 798 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 24 10:40:27 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Jul 2013 12:40:27 +0200 Subject: [Freeipa-devel] [PATCH 0080] Move requirement for keyutils to freeipa-python package Message-ID: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> Hi, There was already a dependency in server package, however, the correct place for such dependency is in freeipa-python, since the relevant code using keyutils resides there. Both freeipa-server and freeipa-client require freeipa-python. https://fedorahosted.org/freeipa/ticket/3808 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0080-Move-requirement-for-keyutils-to-freeipa-python-pack.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Jul 24 10:43:49 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 24 Jul 2013 12:43:49 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> Message-ID: <20130724104349.GJ31508@redhat.com> On Wed, Jul 24, 2013 at 12:39:07PM +0200, Tomas Babej wrote: > Hi, > > this fixes the > > https://fedorahosted.org/freeipa/ticket/3811 > > Tomas > >From ed9014c9db13247dbf062af58f21ea583c476300 Mon Sep 17 00:00:00 2001 > From: Tomas Babej > Date: Tue, 23 Jul 2013 17:11:59 +0200 > Subject: [PATCH] Change shebang to absolute path in ipa-client-automount > > https://fedorahosted.org/freeipa/ticket/3811 > --- > ipa-client/ipa-install/ipa-client-automount | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount > index 346b474fef12ad814eedae5cc98380709eac38ff..8328976adb4d8949bdd400ff9d764b31dd85e5c3 100755 > --- a/ipa-client/ipa-install/ipa-client-automount > +++ b/ipa-client/ipa-install/ipa-client-automount Running git grep shows install/tools/ipa-compliance:#!/usr/bin/env python -- shouldn't it be changed as well? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From pviktori at redhat.com Wed Jul 24 10:52:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Jul 2013 12:52:31 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <20130724104349.GJ31508@redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> <20130724104349.GJ31508@redhat.com> Message-ID: <51EFB1EF.3070700@redhat.com> On 07/24/2013 12:43 PM, Jan Pazdziora wrote: > On Wed, Jul 24, 2013 at 12:39:07PM +0200, Tomas Babej wrote: >> Hi, >> >> this fixes the >> >> https://fedorahosted.org/freeipa/ticket/3811 >> >> Tomas > >> >From ed9014c9db13247dbf062af58f21ea583c476300 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Tue, 23 Jul 2013 17:11:59 +0200 >> Subject: [PATCH] Change shebang to absolute path in ipa-client-automount >> >> https://fedorahosted.org/freeipa/ticket/3811 >> --- >> ipa-client/ipa-install/ipa-client-automount | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount >> index 346b474fef12ad814eedae5cc98380709eac38ff..8328976adb4d8949bdd400ff9d764b31dd85e5c3 100755 >> --- a/ipa-client/ipa-install/ipa-client-automount >> +++ b/ipa-client/ipa-install/ipa-client-automount > > Running git grep shows > > install/tools/ipa-compliance:#!/usr/bin/env python > > -- shouldn't it be changed as well? > That tool was removed recently. Update your repo :) -- Petr? From tbabej at redhat.com Wed Jul 24 10:53:13 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Jul 2013 12:53:13 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <20130724104349.GJ31508@redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> <20130724104349.GJ31508@redhat.com> Message-ID: <1626402.YLkRtlIzS3@thinkpad7.brq.redhat.com> On Wednesday 24 of July 2013 12:43:49 Jan Pazdziora wrote: > On Wed, Jul 24, 2013 at 12:39:07PM +0200, Tomas Babej wrote: > > Hi, > > > > this fixes the > > > > https://fedorahosted.org/freeipa/ticket/3811 > > > > Tomas > > > >From ed9014c9db13247dbf062af58f21ea583c476300 Mon Sep 17 00:00:00 2001 > > From: Tomas Babej > > Date: Tue, 23 Jul 2013 17:11:59 +0200 > > Subject: [PATCH] Change shebang to absolute path in ipa-client-automount > > > > https://fedorahosted.org/freeipa/ticket/3811 > > --- > > ipa-client/ipa-install/ipa-client-automount | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount > > index 346b474fef12ad814eedae5cc98380709eac38ff..8328976adb4d8949bdd400ff9d764b31dd85e5c3 100755 > > --- a/ipa-client/ipa-install/ipa-client-automount > > +++ b/ipa-client/ipa-install/ipa-client-automount > > Running git grep shows > > install/tools/ipa-compliance:#!/usr/bin/env python > > -- shouldn't it be changed as well? > It seems that you don't have updated repository. [tbabej at thinkpad7 freeipa]$ git grep /usr/bin/env ipa-client/ipa-install/ipa-client-automount:#!/usr/bin/env python The ipa-compliance script has been removed recently. It is no longer in either master or ipa-3-2 branch. See Martin's commit 77ae4da70632e17b6be09e9ad71fc353b3bad96e. Tomas From mkosek at redhat.com Wed Jul 24 11:06:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Jul 2013 13:06:19 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> Message-ID: <51EFB52B.6080400@redhat.com> On 07/24/2013 12:39 PM, Tomas Babej wrote: > Hi, > > this fixes the > > https://fedorahosted.org/freeipa/ticket/3811 > > Tomas Shouldn't we also add '-E' parameter like we do with in other install tools' shebang? Martin From jcholast at redhat.com Wed Jul 24 11:19:29 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Jul 2013 13:19:29 +0200 Subject: [Freeipa-devel] [PATCH 0080] Move requirement for keyutils to freeipa-python package In-Reply-To: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> References: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> Message-ID: <51EFB841.5060205@redhat.com> Hi, On 24.7.2013 12:40, Tomas Babej wrote: > Hi, > > There was already a dependency in server package, however, > the correct place for such dependency is in freeipa-python, > since the relevant code using keyutils resides there. > > Both freeipa-server and freeipa-client require freeipa-python. > > https://fedorahosted.org/freeipa/ticket/3808 > > Tomas > Please add a changelog entry. Honza -- Jan Cholasta From lslebodn at redhat.com Wed Jul 24 11:47:40 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 24 Jul 2013 13:47:40 +0200 Subject: [Freeipa-devel] [PATCHES] Fix C compiler warnings Message-ID: <20130724114739.GA3331@mail.corp.redhat.com> ehlo, Three patches are attached. PATCH 1: fixes warning: passing argument from incompatible pointer type another posiible solution is to cast "(void *(*) (void *))" function pointer at function call pthread_create. PATCH 2: Remove unused variable PATCH 3: warning: variable was set, but it was not used. failcnt_interval = slapi_entry_attr_get_uint(policy_entry, "krbPwdFailureCountInterval"); ^^^^^^ Variable failcnt_interval is not used after this line. If this variable should be realy unused, then I can squash 3rd patch to 2nd. else "PATCH 3" only remove warrning and does not fix problem. LS -------------- next part -------------- >From a186f016a6bbfec60cceacde82cf505ecef1b646 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 23 Jul 2013 00:37:32 +0200 Subject: [PATCH 1/3] Use right function prototype for thread function warning: passing argument from incompatible pointer type --- daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h | 3 ++- daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h index ae0b06f..7b0c2aa 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap.h @@ -98,7 +98,8 @@ struct ipa_cldap_req { struct kvp_list kvps; }; -void *ipa_cldap_worker(struct ipa_cldap_ctx *ctx); +/*void *ipa_cldap_worker(struct ipa_cldap_ctx *ctx);*/ +void *ipa_cldap_worker(void *arg); int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, struct ipa_cldap_req *req, diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c index 37de786..df7cc11 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_worker.c @@ -314,11 +314,12 @@ static struct ipa_cldap_req *ipa_cldap_recv_dgram(struct ipa_cldap_ctx *ctx) return req; } -void *ipa_cldap_worker(struct ipa_cldap_ctx *ctx) +void *ipa_cldap_worker(void *arg) { struct ipa_cldap_req *req; struct pollfd fds[2]; bool stop = false; + struct ipa_cldap_ctx *ctx = (struct ipa_cldap_ctx *) arg; int ret; while (!stop) { -- 1.8.3.1 -------------- next part -------------- >From c85ab04e5346d6c180fc7a0fac802a3bf05b2b39 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 23 Jul 2013 00:42:33 +0200 Subject: [PATCH 2/3] Remove unused variable --- daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c | 1 - 1 file changed, 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c index 0b3b841..6b5ae04 100644 --- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c +++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c @@ -393,7 +393,6 @@ static int ipalockout_postop(Slapi_PBlock *pb) Slapi_Entry *target_entry = NULL; Slapi_Entry *policy_entry = NULL; Slapi_DN *sdn = NULL; - Slapi_DN *pdn = NULL; Slapi_PBlock *pbtm = NULL; Slapi_Mods *smods = NULL; Slapi_Value *objectclass = NULL; -- 1.8.3.1 -------------- next part -------------- >From eff291b99a44e3cb107835bd7d90ef7574cdeb14 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 23 Jul 2013 00:43:07 +0200 Subject: [PATCH 3/3] Remove unused variable Variable was set, but it was not used. --- daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c index 6b5ae04..9e903aa 100644 --- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c +++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c @@ -668,7 +668,6 @@ static int ipalockout_preop(Slapi_PBlock *pb) int ret = LDAP_SUCCESS; unsigned long failedcount = 0; time_t time_now; - unsigned int failcnt_interval = 0; unsigned int max_fail = 0; unsigned int lockout_duration = 0; time_t last_failed = 0; @@ -737,7 +736,6 @@ static int ipalockout_preop(Slapi_PBlock *pb) failedcount = slapi_entry_attr_get_ulong(target_entry, "krbLoginFailedCount"); time_now = time(NULL); - failcnt_interval = slapi_entry_attr_get_uint(policy_entry, "krbPwdFailureCountInterval"); lockout_duration = slapi_entry_attr_get_uint(policy_entry, "krbPwdLockoutDuration"); lastfail = slapi_entry_attr_get_charptr(target_entry, "krbLastFailedAuth"); -- 1.8.3.1 From tbabej at redhat.com Wed Jul 24 11:52:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Jul 2013 13:52:10 +0200 Subject: [Freeipa-devel] [PATCH 0080] Move requirement for keyutils to freeipa-python package In-Reply-To: <51EFB841.5060205@redhat.com> References: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> <51EFB841.5060205@redhat.com> Message-ID: <5285531.OSHDOsXz6G@thinkpad7.brq.redhat.com> On Wednesday 24 of July 2013 13:19:29 Jan Cholasta wrote: > Hi, > > On 24.7.2013 12:40, Tomas Babej wrote: > > Hi, > > > > There was already a dependency in server package, however, > > the correct place for such dependency is in freeipa-python, > > since the relevant code using keyutils resides there. > > > > Both freeipa-server and freeipa-client require freeipa-python. > > > > https://fedorahosted.org/freeipa/ticket/3808 > > > > Tomas > > > > Please add a changelog entry. > > Honza > > -- > Jan Cholasta Added. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0080-2-Move-requirement-for-keyutils-to-freeipa-python-pack.patch Type: text/x-patch Size: 1590 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 24 11:56:44 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Jul 2013 13:56:44 +0200 Subject: [Freeipa-devel] [PATCH 0080] Move requirement for keyutils to freeipa-python package In-Reply-To: <5285531.OSHDOsXz6G@thinkpad7.brq.redhat.com> References: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> <51EFB841.5060205@redhat.com> <5285531.OSHDOsXz6G@thinkpad7.brq.redhat.com> Message-ID: <51EFC0FC.1090404@redhat.com> On 24.7.2013 13:52, Tomas Babej wrote: > On Wednesday 24 of July 2013 13:19:29 Jan Cholasta wrote: >> Hi, >> >> On 24.7.2013 12:40, Tomas Babej wrote: >>> Hi, >>> >>> There was already a dependency in server package, however, >>> the correct place for such dependency is in freeipa-python, >>> since the relevant code using keyutils resides there. >>> >>> Both freeipa-server and freeipa-client require freeipa-python. >>> >>> https://fedorahosted.org/freeipa/ticket/3808 >>> >>> Tomas >>> >> >> Please add a changelog entry. >> >> Honza >> >> -- >> Jan Cholasta > > Added. > > Tomas > ACK. -- Jan Cholasta From jpazdziora at redhat.com Wed Jul 24 12:08:17 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 24 Jul 2013 14:08:17 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <51EFB1EF.3070700@redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> <20130724104349.GJ31508@redhat.com> <51EFB1EF.3070700@redhat.com> Message-ID: <20130724120817.GL31508@redhat.com> On Wed, Jul 24, 2013 at 12:52:31PM +0200, Petr Viktorin wrote: > > That tool was removed recently. Update your repo :) Ah, I had some uncommitted change so git pull did not do what I meant it to do (and I ignored the warning it gave me). Sorry about the noise. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From jcholast at redhat.com Wed Jul 24 12:39:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Jul 2013 14:39:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51E691F0.5080001@redhat.com> References: <51E565FE.8060202@redhat.com> <51E691F0.5080001@redhat.com> Message-ID: <51EFCB1E.10004@redhat.com> On 17.7.2013 14:45, Petr Viktorin wrote: > On 07/16/2013 05:25 PM, Petr Viktorin wrote: >> This exposes tasks such as installation, uninstallation, clean-up should >> be available as CLI commands so they're available for non-Python tests. >> >> https://fedorahosted.org/freeipa/ticket/3721 >> >> It also allows tests to install IPA in a specific topology by setting >> the `topology` attribute to 'star', 'line', 'tree', etc. (so far only >> 'star' or none was supported). >> >> The first patches contain some refactoring/enhancements needed to make >> this possible. >> > > I found a bug in patch 0246 and a typo in 0249. This update fixes them. > Patch 245: Since you use tar -J, I think it might make sense to add tar and xz to freeipa-tests requires. Otherwise it looks good to me. Honza -- Jan Cholasta From pviktori at redhat.com Wed Jul 24 13:46:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Jul 2013 15:46:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51EFCB1E.10004@redhat.com> References: <51E565FE.8060202@redhat.com> <51E691F0.5080001@redhat.com> <51EFCB1E.10004@redhat.com> Message-ID: <51EFDAC6.60306@redhat.com> On 07/24/2013 02:39 PM, Jan Cholasta wrote: > On 17.7.2013 14:45, Petr Viktorin wrote: >> On 07/16/2013 05:25 PM, Petr Viktorin wrote: >>> This exposes tasks such as installation, uninstallation, clean-up should >>> be available as CLI commands so they're available for non-Python tests. >>> >>> https://fedorahosted.org/freeipa/ticket/3721 >>> >>> It also allows tests to install IPA in a specific topology by setting >>> the `topology` attribute to 'star', 'line', 'tree', etc. (so far only >>> 'star' or none was supported). >>> >>> The first patches contain some refactoring/enhancements needed to make >>> this possible. >>> >> >> I found a bug in patch 0246 and a typo in 0249. This update fixes them. >> > > Patch 245: > > Since you use tar -J, I think it might make sense to add tar and xz to > freeipa-tests requires. Thanks for the catch. That patch just moves the code around, it doesn't introduce the dependencies. Here's a separate patch to change the spec file. > Otherwise it looks good to me. Thanks for the review -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0254.2-Add-tar-and-xz-dependencies-to-the-freeipa-tests-pac.patch Type: text/x-patch Size: 1183 bytes Desc: not available URL: From akrivoka at redhat.com Wed Jul 24 13:52:12 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 24 Jul 2013 15:52:12 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51EEAAA9.2020001@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> <51ED45CB.7080604@redhat.com> <51EEAAA9.2020001@redhat.com> Message-ID: <51EFDC0C.3040606@redhat.com> On 07/23/2013 06:09 PM, Petr Vobornik wrote: > On 07/22/2013 04:46 PM, Ana Krivokapic wrote: >> On 07/18/2013 09:47 AM, Petr Vobornik wrote: >>> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >>>> >>> >>> Hello, >>> >>> 1) IMO we should not create attribute which is just a negation of another. >>> >>> 2) We should add set_enabled method to base widget. Existing set_enabled >>> methods should use it and maintain widget output consistent with the attribute >>> (ie. one should not directly set the attr and should use set_enabled instead). >>> The method should be also callable when content is not yet created. >>> get_enabled methods might become unnecessary - one can get the state form >>> 'enabled' attribute. >>> >> >> The attached updated patch implements the following changes: >> >> 1) set_enabled method has been added to the base widget class. >> 2) get_enabled/is_enabled methods have been removed. >> 3) Widget classes that inherit from the base widget class override the >> set_enabled method where necessary. >> 4) Using 'enabled: true/false' in the widget definition should now work >> correctly for all types of widgets. >> >> > > Thanks. > > 1. set_enabled method in input_widget uses `that.input`. Input widget is a > base class which doesn't set the property and therefore we can't be certain > that the descendant will set it. Also it may break when you call > set_enabled(val) before create() . > > We should test for `that.input` presence. > > Same content-created test should be perform on other places: > widget.js:1017,1147,2006 > > 2. The changes in option_widget_base break disabling if user doesn't have > write-rights. (can be reproduced when navigated (by manual change of url) to > service in self-service. > > Note the differences between read_only, writable and enabled: > * read_only - reflects metadata > * writable - reflects ACL > * enabled - context specific > > read_only and writable don't offer edit interface (label instead of textbox). > Enabled controls disabled state of textbox. For some widgets the result might > be the same (radios, checkboxes). > > option_widget_base.set_enabled should be changed. The mixin overwrites the > original method and therefore doesn't set 'enabled' property. > > 3. multiple_choice_section.set_enabled should be renamed. It's related to > individual choices and not the widget itself. And then new set_enabled should > be added which would call the old one for each choice. > > 4. widget.js:3870 - not sure if it's needed but if so, one should also change > `action_clicked` method. > All fixed. Updated patch attached. Thanks for the review. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0047-03-Honor-enabled-option-for-widgets.patch Type: text/x-patch Size: 14130 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 24 15:13:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Jul 2013 17:13:46 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.3.0 Beta 1 Message-ID: <51EFEF2A.2000304@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.0 Beta 1. It can be downloaded from http://www.freeipa.org/page/Downloads. As this is a Beta release and Fedora 19 is now stable, there is no public Fedora build at this time. Please note, that you can help us test the new release in tomorrow's FreeIPA 3.3 Fedora 19 Test Day! See: https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients == Highlights in 3.3 beta 1 == === New features for 3.3 === * Active Directory integration: ** Support of externally defined POSIX attributes for Active Directory trusted domains ** Automatic discovery of Active Directory identity mapping configuration ** Support of trusted domain users for legacy clients ** Identity mapping for AD users can now be delegated * Performance improvements in processing large number of users and groups * Automated integration testing infrastructure * ipa-advise utility is added to generate client setup advice based on an IPA master configuration * FreeIPA-specific SELinux policies has been merged to the main SELinux policy in Fedora 19 * SSSD 1.11 is required === Active Directory integration === Starting with FreeIPA 3.3, it is possible to define identity ranges for a trusted Active Directory domain that rely on POSIX attributes provided by AD DC instead of generating them out of corresponding security identifiers. This functionality requires Services for Unix (SFU) or Server for NIS enabled on Active Directory side and is provided mostly to aid with migration to SID-based mapping. In order to support externally defined POSIX attributes, identity ranges have been extended to support new range types: * AD trust with SID-based mapping: 'ipa-ad-trust' (default) * SFU support: 'ipa-ad-trust-posix' 'ipa-ad-trust-posix' range type is activated when range discovery finds out SFU is in use by Active Directory domain. To override automatic detection, --range-type=ipa-ad-trust can be specified to 'ipa trust-add' command. FreeIPA 3.3 requires SSSD 1.11 on the IPA master in order to support externally defined POSIX attributes in AD. More details: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD FreeIPA 3.3 provides a new way to enable legacy clients to support trusted domain users. A compatibility tree, provided by slapi-nis, can now be configured to look up trusted domain users and handle authentication for them. This functionality relies on SSSD 1.11 and an experimental patch for slapi-nis. One can enable legacy clients support by running ipa-adtrust-install and answering positively to the corresponding question. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts Finally, SSSD 1.11 is used to query identity information about trusted domains' users from within IPA framework, including SID to name and name to SID resolution. In addition to speed improvements, FreeIPA 3.3 allows to manage mappings for trusted domains' users without requiring elevated privileges of 'trust admins'. === Performance improvements === When acting on large datasets, FreeIPA now reduces number of potential read roundtrips required to update user and group information. When scaled to thousands of users and groups, this shortens the time required by certain operations tenfold. === Automated testing infrastructure === The FreeIPA team has been providing self-testing code for a long time. The FreeIPA 3.3 test suite includes a framework for integration tests that verify functionality such as replication across several machines. Tests can be run manually, or by test automation servers such as Jenkins or Beaker. Development builds now create a freeipa-tests RPM containing the test suite and related tools. However, as the focus is on testing development code, this package will not be released to Fedora yet. More details: http://www.freeipa.org/page/V3/Integration_testing Additionally, it is now possible to run Web UI tests through the test suite. More details: http://www.freeipa.org/page/Web_UI_Integration_Tests === IPA advise tool === FreeIPA 3.3 introduces new framework to generate recipes of configuration based on how IPA master is configured. These recipes can be taken to the target client systems and used there to configure them for a specific task. We expect to expand use of 'ipa-advise' tool to cover at least configuration of legacy systems in subsequent releases. Contributions are always welcome to grow capabilities of 'ipa-advise' tool to other areas. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement === SELinux policy === SELinux policies specific to FreeIPA have been merged back to the main SELinux policy package in Fedora 19. Starting with FreeIPA 3.2.2 (available in Fedora 19 updates) SELinux policy is no londer provided by freeipa-selinux package and the package is removed in favor of selinux-policy package. === SSSD 1.11 is required === FreeIPA 3.3 depends on SSSD 1.11 for cross-realm trusts with Active Directory. In particular, FreeIPA 3.3 depends on a new operational mode of SSSD called 'ipa_server_mode'. Thus, SSSD 1.11 is required for FreeIPA 3.3. More details: https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. === Other FreeIPA servers and clients === An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the performance improvements requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.2.0 == === Alexander Bokovoy (8): === * Fix cldap parser to work with a single equality filter (NtVer=...) * Make sure domain_name is also set when processing INP_NAME requests * Fix extdom plugin to provide unqualified name in response as sssd expects * Generate syntethic MS-PAC for all services running on IPA master * ipa-adtrust-install: configure compatibility tree to serve trusted domain users * ipa-kdb: cache KDC hostname on startup * ipa-kdb: reinit mspac on HTTP TGT acquisition to aid trust-add case * ipaserver/dcerpc: attempt to resolve SIDs through SSSD first === Ana Krivokapic (21): === * Prompt for nameserver IP address in dnszone-add * Do not display success message on failure in web UI * Ignore files generated by build * Deprecate options --dom-sid and --dom-name in idrange-mod * Prevent error when running IPA commands with su/sudo * Fix displaying of success message * Fix location of service.crt in .gitignore * Improve handling of options in ipa-client-install * Fail when adding a trust with a different range * Do not display traceback to user * Require rid-base and secondary-rid-base in idrange-add after ipa-adtrust-install * Fix bug in adtrustinstance * Use correct DS instance in ipactl status * Avoid systemd service deadlock during shutdown * Make sure replication works after DM password is changed * Use --ignore-dependencies only when necessary * Properly handle non-existent cert files * Add 'ipa_server_mode' option to SSSD configuration * Bump version of sssd in spec file * Use admin at REALM when testing if SSSD is ready * Fix internal error in idrange-add === Diane Trout (1): === * Fix log format not a string literal. === Jakub Hrozek (3): === * Remove unused variable * IPA KDB MS-PAC: return ENOMEM if allocation fails * IPA KDB MS-PAC: remove unused variable === Jan Cholasta (21): === * Use the correct PKCS#12 file for HTTP server. * Remove stray error condition in ipa-server-install. * Handle exceptions gracefully when verifying PKCS#12 files. * Skip empty lines when parsing pk12util output. * Do not allow installing CA replicas in CA-less setup. * Do not track DS certificate in CA-less setup. * Fix CA-less check in ipa-replica-install and ipa-ca-install. * Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns. * Enable SASL mapping fallback. * Skip cert issuer validation in service and host commands in CA-less install. * Check trust chain length in CA-less install. * Use LDAP search instead of *group_show to check if a group exists. * Use LDAP search instead of *group_show to check for a group objectclass. * Use LDAP modify operation directly to add/remove group members. * Add missing substring indices for attributes managed by the referint plugin. * Add missing equality index for ipaUniqueId. * Run gpg-agent explicitly when encrypting/decrypting files. * Add new hidden command option to suppress processing of membership attributes. * Ask for PKCS#12 password interactively in ipa-server-install. * Ask for PKCS#12 password interactively in ipa-replica-prepare. * Print newline after receiving EOF in installutils.read_password. === Lukas Slebodnik (1): === * Use pkg-config to detect cmocka === Martin Kosek (11): === * Set KRB5CCNAME so that dirsrv can work with newer krb5-server * Handle DIR type CCACHEs in test_cmdline properly * Avoid exporting KRB5_KTNAME in dirsrv env * Remove redundant u'' character * Drop SELinux subpackage * Drop redundant directory /var/cache/ipa/sessions * Remove entitlement support * Run server upgrade and restart in posttrans * Require new selinux-policy replacing old server-selinux subpackage * Bump minimum SSSD version * Become 3.3.0 Beta 1 === Nathaniel McCallum (10): === * Add ipaUserAuthType and ipaUserAuthTypeClass * Add IPA OTP schema and ACLs * ipa-kdb: Add OTP support * Add the krb5/FreeIPA RADIUS companion daemon * Remove unnecessary prefixes from ipa-pwd-extop files * Add OTP support to ipa-pwd-extop * Fix client install exception if /etc/ssh is missing * Permit reads to ipatokenRadiusProxyUser objects * Fix for small syntax error in OTP schema * Use libunistring ulc_casecmp() on unicode strings === Petr Spacek (1): === * ipa-client-install: Add 'debug' and 'show' statements to nsupdate commands === Petr Viktorin (21): === * Remove leading zero from IPA_NUM_VERSION * Relax getkeytab test to allow additional messages on stderr * Remove code to install Dogtag 9 * Flush stream after writing service messages * Make an ipa-tests package * Add ipa-run-tests command * Add Nose plugin for BeakerLib integration * Add a plugin for test ordering * Add a framework for integration test configuration * Add a framework for integration testing * Introduce a class for remote commands * Collect logs from tests * Show logs in failed tests * tests: Allow public keys for authentication to the remote machines * tests: Configure/unconfigure remote hosts * Host class improvements * Use dosctrings in BeakerLib phase descriptions * Make BeakerLib logging less verbose * BeakerLib plugin: Log http links in test docstrings * Integration test config: Make it possible to specify host IP * ipa-client: Use "ipa" as the package name for i18n === Petr Vobornik (18): === * Fix: HBAC Test tab is missing * Move spec modifications from facet factories to pre_ops * Unite and move facet pre_ops to related modules * Web UI: move ./_base/metadata_provider.js to ./metadata.js * Regression fix: missing control buttons in nested search facets * Make ssbrowser.html work in IE 10 * Fix regression: missing facet tab group labels * Regression fix: rule table with ext. member support doesn't offer any items * Fix default value selection in radio widget * Do not redirect to https in /ipa/ui on non-HTML files * Create Firefox configuration extension on CA-less install * Disable checkboxes and radios for readonly attributes * Better automated test support * Fix container element in adder dialogs * Upstream Web UI tests * Web UI search optimization * Break long words in notification area * Remove word 'field' from GECOS param label === Rob Crittenden (4): === * Bump version for development branch to 3.2.99 * Return the correct Content-type on negotiated XML-RPC requests. * Add Camellia ciphers to allowed list. * Hide sensitive attributes in LDAP updater logging and output === Simo Sorce (2): === * CLDAP: Fix domain handling in netlogon requests * CLDAP: Return empty reply on non-fatal errors === Sumit Bose (5): === * Fix format string typo * Fix type of printf argument * Add PAC to master host TGTs * extdom: replace winbind calls with POSIX/SSSD calls * Remove winbind client configure check === Tomas Babej (22): === * Remove redundancy from hbactest help text * Do not translate trust type and direction with --raw in trust_show and trust-find * Support multiple local domain ranges with RID base set * Do not allow removal of ID range of an active trust * Use private ccache in ipa install tools * Remove redundant check for env.interactive * Add prompt_param method to avoid code duplication * Incorporate interactive prompts in idrange-add * Do not check userPassword with 7-bit plugin * Manage ipa-otpd.socket by IPA * Add ipaRangeType attribute to LDAP Schema * Add update plugin to fill in ipaRangeType attribute * Extend idrange commands to support new range origin types * PEP8 fixes in idrange.py * Remove hardcoded values from idrange plugin tests * Return ipaRangeType as a list in idrange commands * Do not redirect ipa/crl to HTTPS * Add --range-type option that forces range type of the trusted domain * Add libsss_nss_idmap-devel to BuildRequires * Change group ownership of CRL publish directory * Provide ipa-advise tool * Use AD LDAP probing to create trusted domain ID range From pviktori at redhat.com Wed Jul 24 15:20:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 24 Jul 2013 17:20:59 +0200 Subject: [Freeipa-devel] [PATCH 0080] Move requirement for keyutils to freeipa-python package In-Reply-To: <51EFC0FC.1090404@redhat.com> References: <1756488.yRBg2EnO5B@thinkpad7.brq.redhat.com> <51EFB841.5060205@redhat.com> <5285531.OSHDOsXz6G@thinkpad7.brq.redhat.com> <51EFC0FC.1090404@redhat.com> Message-ID: <51EFF0DB.3090301@redhat.com> On 07/24/2013 01:56 PM, Jan Cholasta wrote: > On 24.7.2013 13:52, Tomas Babej wrote: >> On Wednesday 24 of July 2013 13:19:29 Jan Cholasta wrote: >>> Hi, >>> >>> On 24.7.2013 12:40, Tomas Babej wrote: >>>> Hi, >>>> >>>> There was already a dependency in server package, however, >>>> the correct place for such dependency is in freeipa-python, >>>> since the relevant code using keyutils resides there. >>>> >>>> Both freeipa-server and freeipa-client require freeipa-python. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3808 >>>> >>>> Tomas >>>> >>> >>> Please add a changelog entry. >>> >>> Honza >>> >>> -- >>> Jan Cholasta >> >> Added. >> >> Tomas >> > > ACK. > Rebased changelog and pushed to master and ipa-3-2. master: d094481ea6c8e04aff36414c569673a380a7863a ipa-3-2: 756deb013755d04b4ae0b14019beb23447b3e175 -- Petr? From mkosek at redhat.com Wed Jul 24 15:27:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Jul 2013 17:27:40 +0200 Subject: [Freeipa-devel] [Freeipa-users] FreeIPA AD Trust improvements, Fedora 19 Test Day, July 25th In-Reply-To: <51E9B5FF.7020306@redhat.com> References: <51E9B5FF.7020306@redhat.com> Message-ID: <51EFF26C.5000402@redhat.com> Please note that the FreeIPA Fedora 19 Test Day is happening tomorrow! Thanks in advance to all volunteers helping us test the new Active Directory Trust features. The FreeIPA Team On 07/19/2013 11:56 PM, Dmitri Pal wrote: > Hello, > > The FreeIPA team is happy to welcome you to a Fedora Test Day that is > being held on Thursday, July 25th. > > We would like to invite you to take part in testing of the upcoming FreeIPA 3.3 > release containing 2 major improvements for easier deployment of FreeIPA Active > Directory Trust feature to existing environments: > > 1) Use POSIX attributes defined in Active Directory [1] > > With previous FreeIPA releases, users coming from Active Directory to FreeIPA > managed machines were always assigned POSIX attributes (UID and GID) by > algorithmic mapping. > > However, in some deployments, Active Directory users and groups already have > defined custom POSIX attribute values (UID and GID), which may then be > leveraged on Linux machines via other 3rd party Active Directory integration > solutions. Administrator may choose to keep the values to not disrupt file > ownerships. > > With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use these > attributes when Active Directory user authenticates to Linux machines. > > > 2) Expose POSIX data on legacy systems without recent SSSD > > Administrators may have a deployment of machines which cannot use the recent > SSSD with Active Directory Trust support but would still like to be able to > authenticate with Active Directory user to these machines. This may affect for > example older Linux machines, UNIX machines. > > With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree which > will contain identities of the Active Directory users to the legacy systems. > These systems may then leverage standard LDAP authentication in this tree > allowing selected Active Directory users to authenticate. > > > To read more about the Test Day and suggested tests, see the following link: > > https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients > > Thank you for your help and participation! > > The FreeIPA team > > [1] http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD > [2] http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > [IdM | IPA] FAQs: https://url.corp.redhat.com/idm-faq > Identity Management SME Team on Docspace > https://url.corp.redhat.com/sme-idm > Search the archives: post-office.corp.redhat.com/mailman/listinfo/idm-tech > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From pvoborni at redhat.com Wed Jul 24 15:33:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Jul 2013 17:33:16 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51EEA628.3020707@redhat.com> References: <51E7D2AD.7020600@redhat.com> <51E7D2EE.4050501@redhat.com> <51EEA628.3020707@redhat.com> Message-ID: <51EFF3BC.1050909@redhat.com> On 07/23/2013 05:50 PM, Ana Krivokapic wrote: > On 07/18/2013 01:35 PM, Petr Vobornik wrote: >> On 07/18/2013 01:34 PM, Petr Vobornik wrote: >>> [PATCH] 431 Web UI integration tests: Add trust tests >>> >>> [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions >>> >>> [PATCH] 433 Web UI integration tests: Verify data after add and mod >>> >>> [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps >>> >>> Heavily inspired by code from xmlrpc tests. >>> >>> To obtain ranges, this patch also adds method to execute FreeIPA command >>> through Web UI. >>> It uses Web UI instead of ipalib so it doesn't need to care about >>> authentication on a test-runner machine. >>> >>> All: https://fedorahosted.org/freeipa/ticket/3744 >> >> And now the patches... >> Thanks for the review. > Patch 431: > - In case 'ipa-adtrust-install' has not been run on the system, but 'has_trusts' > is configured in 'ui_test.conf', trust tests fail. I suggest checking for > 'ipa-adtrust-install' with 'adtrust_is_enabled' command and then skipping tests > if trusts are not enabled. IMO it's correct behavior - you want to test the feature, but server is misconfigured - fail. > > Patch 432: > - Docstrings for 'has_ca()' and 'has_dns()' state that 'FreeIPA server was > installed *without* CA/DNS' when they shoud state *with*. > > Patch 433: > - Please also add docstrings for newly added methods. > - The long 'if' statement in 'validate_fields()' can be shortened by using the > 'in' keyword instead of individual string comparisons. For example: > elif ftype in ('textbox', 'password', 'combobox'): > actual = self.get_field_value(key, parent, 'input') > - IIUC, the code in validate_fields() compares lists irrespective of element > order. If this is the case, it can be replaced by simply 'sorted(expected) == > sorted(actual)'. > - In 'basic_crud()', shouldn't validate_fields with 'add_v' be called right > after 'add_record'? The way it is now, data only gets validated in case of data > modification, but not after initial addition. > > Patch 434: > - The "if 'ipasecondarybaserid' in idrange" block should be nested under the "if > 'ipasecondarybaserid' in idrange" block, since it assumes that the 'base_rid' > variable is set. > - Please remove trailing semicolons. Fixed > > > General comments (these comments are by no means a requirement, and they are not > a reason for a NACK, just a "nice to have"): > - Some methods have unused parameters (e.g. validate_fields, basic_crud) > - Some methods define variables which shadow Python built-ins of the same name New patch #438. > (e.g. type, all). This can be a problem if you later want to use the built-in. > - It would be nice to make at least newly added code PEP8 compliant. The 'pep8' > utility can be used to easily check any python file for PEP8 compliance: > $ sudo yum install python-pep8 > $ pep8 /path/to/script.py > Attaching new patch #437 which fixes PEP8 errors (except long lines). Most of the work was done automatically by autopep8 tool. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0431-1-Web-UI-integration-tests-Add-trust-tests.patch Type: text/x-patch Size: 7886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0432-1-Web-UI-integration-tests-Add-ui_driver-method-descri.patch Type: text/x-patch Size: 10503 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0433-1-Web-UI-integration-tests-Verify-data-after-add-and-m.patch Type: text/x-patch Size: 6804 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0434-1-Web-UI-integration-tests-Compute-range-sizes-to-avoi.patch Type: text/x-patch Size: 4701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0437-Web-UI-integration-tests-PEP8-fixes.patch Type: text/x-patch Size: 45071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0438-Web-UI-integration-tests-Code-quality-fixes.patch Type: text/x-patch Size: 9132 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 24 20:18:01 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Jul 2013 22:18:01 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry Message-ID: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> Hi, When converting the result obtained by python-ldap library, we need to skip unresolved referral entries, since they cannot be converted. https://fedorahosted.org/freeipa/ticket/3814 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0081-Skip-referrals-when-converting-LDAP-result-to-LDAPEn.patch Type: text/x-patch Size: 1168 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 25 06:48:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Jul 2013 08:48:49 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> Message-ID: <51F0CA51.3080604@redhat.com> On 24.7.2013 22:18, Tomas Babej wrote: > Hi, > > When converting the result obtained by python-ldap library, > we need to skip unresolved referral entries, since they cannot > be converted. > > https://fedorahosted.org/freeipa/ticket/3814 I'm not sure if a simple 'skip it' approach is the right one. Shouldn't it print/log a warning at least? Do you know all implications? Are you sure that this will not break something else silently? (BTW isn't the right approach to fix python-ldap? Or is it a quirk in AD?) -- Petr^2 Spacek From abokovoy at redhat.com Thu Jul 25 07:03:55 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Jul 2013 10:03:55 +0300 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F0CA51.3080604@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CA51.3080604@redhat.com> Message-ID: <20130725070355.GS15859@redhat.com> On Thu, 25 Jul 2013, Petr Spacek wrote: >On 24.7.2013 22:18, Tomas Babej wrote: >>Hi, >> >>When converting the result obtained by python-ldap library, >>we need to skip unresolved referral entries, since they cannot >>be converted. >> >>https://fedorahosted.org/freeipa/ticket/3814 > >I'm not sure if a simple 'skip it' approach is the right one. >Shouldn't it print/log a warning at least? Do you know all >implications? Are you sure that this will not break something else >silently? > >(BTW isn't the right approach to fix python-ldap? Or is it a quirk in AD?) AD DC often answers with proper result and then several referrals to other internal resources to complement the search if you are asking for wide-open search (default). We are not interested in these referrals for various reasons, including the fact that we are looking at the authoritative DC and it has all the needed info. At best, we could define an option that forces us doing referral chasing to fetch remaining results but this is not something really needed right now. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jul 25 07:11:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Jul 2013 09:11:06 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <20130725070355.GS15859@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CA51.3080604@redhat.com> <20130725070355.GS15859@redhat.com> Message-ID: <51F0CF8A.8030000@redhat.com> On 25.7.2013 09:03, Alexander Bokovoy wrote: > On Thu, 25 Jul 2013, Petr Spacek wrote: >> On 24.7.2013 22:18, Tomas Babej wrote: >>> Hi, >>> >>> When converting the result obtained by python-ldap library, >>> we need to skip unresolved referral entries, since they cannot >>> be converted. >>> >>> https://fedorahosted.org/freeipa/ticket/3814 >> >> I'm not sure if a simple 'skip it' approach is the right one. Shouldn't it >> print/log a warning at least? Do you know all implications? Are you sure >> that this will not break something else silently? >> >> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in AD?) > AD DC often answers with proper result and then several referrals to > other internal resources to complement the search if you are asking for > wide-open search (default). We are not interested in these referrals for > various reasons, including the fact that we are looking at the > authoritative DC and it has all the needed info. > > At best, we could define an option that forces us doing referral chasing > to fetch remaining results but this is not something really needed right > now. I understand that we don't need referrals now, but the question is 'Could it break something? Silently? In the future?'. E.g. the option 'follow referrals' (defaulting to False) is IMHO much much better. The point is that we don't need to implement referral chasing right now, just thrown an exception if somebody tries to switch 'follow referrals' option to True. IMHO this will prevent surprises in the future, because it is absolutely clear that referrals are not followed. -- Petr^2 Spacek From abokovoy at redhat.com Thu Jul 25 07:28:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 25 Jul 2013 10:28:05 +0300 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F0CF8A.8030000@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CA51.3080604@redhat.com> <20130725070355.GS15859@redhat.com> <51F0CF8A.8030000@redhat.com> Message-ID: <20130725072805.GT15859@redhat.com> On Thu, 25 Jul 2013, Petr Spacek wrote: >On 25.7.2013 09:03, Alexander Bokovoy wrote: >>On Thu, 25 Jul 2013, Petr Spacek wrote: >>>On 24.7.2013 22:18, Tomas Babej wrote: >>>>Hi, >>>> >>>>When converting the result obtained by python-ldap library, >>>>we need to skip unresolved referral entries, since they cannot >>>>be converted. >>>> >>>>https://fedorahosted.org/freeipa/ticket/3814 >>> >>>I'm not sure if a simple 'skip it' approach is the right one. Shouldn't it >>>print/log a warning at least? Do you know all implications? Are you sure >>>that this will not break something else silently? >>> >>>(BTW isn't the right approach to fix python-ldap? Or is it a quirk in AD?) >>AD DC often answers with proper result and then several referrals to >>other internal resources to complement the search if you are asking for >>wide-open search (default). We are not interested in these referrals for >>various reasons, including the fact that we are looking at the >>authoritative DC and it has all the needed info. >> >>At best, we could define an option that forces us doing referral chasing >>to fetch remaining results but this is not something really needed right >>now. > >I understand that we don't need referrals now, but the question is >'Could it break something? Silently? In the future?'. Not in the codepath for AD. We disabled referrals chasing in SSSD when talking to AD as well. There is currently one place where referrals are actively used in IPA deployment and it is Schema Compatibility plugin which issues referral for an authenticated bind to the main LDAP tree. However, it seems to be broken as majority of OpenLDAP installs have defaults to referral chasing switched off. >E.g. the option 'follow referrals' (defaulting to False) is IMHO much much better. Agreed. Actually, since we have access to the connection object, upper layer code can set referral handling manually via ldap_set_option(). This means we can check at this place on whether the connection has referral chasing disabled (ldap_get_option(conn, LDAP_OPT_REFERRALS, &value) in C) and issue exception here. >The point is that we don't need to implement referral chasing right >now, just thrown an exception if somebody tries to switch 'follow >referrals' option to True. IMHO this will prevent surprises in the >future, because it is absolutely clear that referrals are not >followed. Yes, definitely, though I'd prefer to sense the option from existing LDAP connection. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jul 25 07:30:22 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Jul 2013 09:30:22 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F0CF8A.8030000@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CA51.3080604@redhat.com> <20130725070355.GS15859@redhat.com> <51F0CF8A.8030000@redhat.com> Message-ID: <51F0D40E.705@redhat.com> On 25.7.2013 09:11, Petr Spacek wrote: > On 25.7.2013 09:03, Alexander Bokovoy wrote: >> On Thu, 25 Jul 2013, Petr Spacek wrote: >>> On 24.7.2013 22:18, Tomas Babej wrote: >>>> Hi, >>>> >>>> When converting the result obtained by python-ldap library, >>>> we need to skip unresolved referral entries, since they cannot >>>> be converted. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3814 >>> >>> I'm not sure if a simple 'skip it' approach is the right one. >>> Shouldn't it >>> print/log a warning at least? Do you know all implications? Are you sure >>> that this will not break something else silently? >>> >>> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in >>> AD?) >> AD DC often answers with proper result and then several referrals to >> other internal resources to complement the search if you are asking for >> wide-open search (default). We are not interested in these referrals for >> various reasons, including the fact that we are looking at the >> authoritative DC and it has all the needed info. >> >> At best, we could define an option that forces us doing referral chasing >> to fetch remaining results but this is not something really needed right >> now. > > I understand that we don't need referrals now, but the question is > 'Could it break something? Silently? In the future?'. > > E.g. the option 'follow referrals' (defaulting to False) is IMHO much > much better. > > The point is that we don't need to implement referral chasing right now, > just thrown an exception if somebody tries to switch 'follow referrals' > option to True. IMHO this will prevent surprises in the future, because > it is absolutely clear that referrals are not followed. > IMO a comment is good enough. I don't think adding options that aren't used anywhere is a good thing to do. Honza -- Jan Cholasta From pspacek at redhat.com Thu Jul 25 07:48:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Jul 2013 09:48:47 +0200 Subject: [Freeipa-devel] bind-dyndb-ldap refactoring - alpha code available for testers Message-ID: <51F0D85F.6020508@redhat.com> Hello list, bind-dyndb-ldap is undergoing heavy re-factoring as first step towards DNSSEC support. Proof-of-concept code is available from my personal github repo: https://github.com/spacekpe/bind-dyndb-ldap.git Branch 'syncrepl' contains fork of bind-dyndb-ldap v3.5 with persistent search replaced by RFC 4533. (It implicates that this code will not work with current stable version of 389 DS. I use OpenLDAP at the moment.) See commit messages to read about current limitations. Branches with DNSSEC bits etc. will appear in the near future (hopefully). Patches/pull requests are more than welcome :-) -- Petr^2 Spacek From pviktori at redhat.com Thu Jul 25 10:23:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Jul 2013 12:23:34 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51EFDAC6.60306@redhat.com> References: <51E565FE.8060202@redhat.com> <51E691F0.5080001@redhat.com> <51EFCB1E.10004@redhat.com> <51EFDAC6.60306@redhat.com> Message-ID: <51F0FCA6.7040407@redhat.com> On 07/24/2013 03:46 PM, Petr Viktorin wrote: > On 07/24/2013 02:39 PM, Jan Cholasta wrote: >> On 17.7.2013 14:45, Petr Viktorin wrote: >>> On 07/16/2013 05:25 PM, Petr Viktorin wrote: >>>> This exposes tasks such as installation, uninstallation, clean-up >>>> should >>>> be available as CLI commands so they're available for non-Python tests. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3721 >>>> >>>> It also allows tests to install IPA in a specific topology by setting >>>> the `topology` attribute to 'star', 'line', 'tree', etc. (so far only >>>> 'star' or none was supported). >>>> >>>> The first patches contain some refactoring/enhancements needed to make >>>> this possible. >>>> >>> >>> I found a bug in patch 0246 and a typo in 0249. This update fixes them. >>> >> >> Patch 245: >> >> Since you use tar -J, I think it might make sense to add tar and xz to >> freeipa-tests requires. > > Thanks for the catch. That patch just moves the code around, it doesn't > introduce the dependencies. > Here's a separate patch to change the spec file. Rebased to current master. >> Otherwise it looks good to me. > > Thanks for the review > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0254.3-Add-tar-and-xz-dependencies-to-the-freeipa-tests-pac.patch Type: text/x-patch Size: 1174 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 25 10:28:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Jul 2013 12:28:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51F0FCA6.7040407@redhat.com> References: <51E565FE.8060202@redhat.com> <51E691F0.5080001@redhat.com> <51EFCB1E.10004@redhat.com> <51EFDAC6.60306@redhat.com> <51F0FCA6.7040407@redhat.com> Message-ID: <51F0FDC0.80608@redhat.com> On 25.7.2013 12:23, Petr Viktorin wrote: > On 07/24/2013 03:46 PM, Petr Viktorin wrote: >> On 07/24/2013 02:39 PM, Jan Cholasta wrote: >>> On 17.7.2013 14:45, Petr Viktorin wrote: >>>> On 07/16/2013 05:25 PM, Petr Viktorin wrote: >>>>> This exposes tasks such as installation, uninstallation, clean-up >>>>> should >>>>> be available as CLI commands so they're available for non-Python >>>>> tests. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3721 >>>>> >>>>> It also allows tests to install IPA in a specific topology by setting >>>>> the `topology` attribute to 'star', 'line', 'tree', etc. (so far only >>>>> 'star' or none was supported). >>>>> >>>>> The first patches contain some refactoring/enhancements needed to make >>>>> this possible. >>>>> >>>> >>>> I found a bug in patch 0246 and a typo in 0249. This update fixes them. >>>> >>> >>> Patch 245: >>> >>> Since you use tar -J, I think it might make sense to add tar and xz to >>> freeipa-tests requires. >> >> Thanks for the catch. That patch just moves the code around, it doesn't >> introduce the dependencies. >> Here's a separate patch to change the spec file. > > Rebased to current master. OK, thanks! > >>> Otherwise it looks good to me. >> >> Thanks for the review >> ACK. Honza -- Jan Cholasta From pviktori at redhat.com Thu Jul 25 10:39:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Jul 2013 12:39:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0245-0250 Add the ipa-test-task-tool In-Reply-To: <51F0FDC0.80608@redhat.com> References: <51E565FE.8060202@redhat.com> <51E691F0.5080001@redhat.com> <51EFCB1E.10004@redhat.com> <51EFDAC6.60306@redhat.com> <51F0FCA6.7040407@redhat.com> <51F0FDC0.80608@redhat.com> Message-ID: <51F10055.9090500@redhat.com> On 07/25/2013 12:28 PM, Jan Cholasta wrote: > On 25.7.2013 12:23, Petr Viktorin wrote: >> On 07/24/2013 03:46 PM, Petr Viktorin wrote: >>> On 07/24/2013 02:39 PM, Jan Cholasta wrote: >>>> On 17.7.2013 14:45, Petr Viktorin wrote: >>>>> On 07/16/2013 05:25 PM, Petr Viktorin wrote: >>>>>> This exposes tasks such as installation, uninstallation, clean-up >>>>>> should >>>>>> be available as CLI commands so they're available for non-Python >>>>>> tests. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3721 >>>>>> >>>>>> It also allows tests to install IPA in a specific topology by setting >>>>>> the `topology` attribute to 'star', 'line', 'tree', etc. (so far only >>>>>> 'star' or none was supported). >>>>>> >>>>>> The first patches contain some refactoring/enhancements needed to >>>>>> make >>>>>> this possible. >>>>>> >>>>> >>>>> I found a bug in patch 0246 and a typo in 0249. This update fixes >>>>> them. >>>>> >>>> >>>> Patch 245: >>>> >>>> Since you use tar -J, I think it might make sense to add tar and xz to >>>> freeipa-tests requires. >>> >>> Thanks for the catch. That patch just moves the code around, it doesn't >>> introduce the dependencies. >>> Here's a separate patch to change the spec file. >> >> Rebased to current master. > > OK, thanks! > >> >>>> Otherwise it looks good to me. >>> >>> Thanks for the review >>> > > ACK. > > Honza > Pushed to master: e38816bdaf2280e283df6c2746897c37fa3bbb92 -- Petr? From pviktori at redhat.com Thu Jul 25 10:44:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Jul 2013 12:44:06 +0200 Subject: [Freeipa-devel] [PATCHES] 0251-0252 Wait for replication to finish in test_simple_replication In-Reply-To: <51E7D09D.6020109@redhat.com> References: <51E7C0A3.4020808@redhat.com> <51E7D09D.6020109@redhat.com> Message-ID: <51F10176.6000506@redhat.com> On 07/18/2013 01:25 PM, Jan Cholasta wrote: > On 18.7.2013 12:17, Petr Viktorin wrote: >> Please apply on top of my patches 0245-0250 (or I can rebase if >> necessary). >> >> These patches are continuing with >> https://fedorahosted.org/freeipa/ticket/3621, Automated integration >> testing >> >> Before checking if an entry is replicated, we need to wait until >> replication is complete. >> One way to do this is polling replication agreements until all updates >> are complete (or an error occurs). I checked with Rich Megginson that >> this strategy should work. >> >> Patch 0252 implements this. > > This fixes test_integration.py for me, ACK. > >> >> Patch 0251 is a one-liner fixing a default argument of >> LDAPClient.get_entries. > > ACK. > > Honza Thanks! Pushed to master: 2f80855e156fe5966ee33d486aa25f49637dd3e0 -- Petr? From mkosek at redhat.com Thu Jul 25 11:23:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Jul 2013 13:23:02 +0200 Subject: [Freeipa-devel] [PATCHES] Fix C compiler warnings In-Reply-To: <20130724114739.GA3331@mail.corp.redhat.com> References: <20130724114739.GA3331@mail.corp.redhat.com> Message-ID: <51F10A96.4060304@redhat.com> On 07/24/2013 01:47 PM, Lukas Slebodnik wrote: > ehlo, > > Three patches are attached. > PATCH 1: fixes warning: passing argument from incompatible pointer type > another posiible solution is to cast "(void *(*) (void *))" function pointer > at function call pthread_create. > PATCH 2: Remove unused variable > PATCH 3: warning: variable was set, but it was not used. > failcnt_interval = slapi_entry_attr_get_uint(policy_entry, "krbPwdFailureCountInterval"); > ^^^^^^ > Variable failcnt_interval is not used after this line. > If this variable should be realy unused, > then I can squash 3rd patch to 2nd. > else "PATCH 3" only remove warrning and does not fix problem. > > LS > Thanks, ACK. Pushed to master. Martin From pvoborni at redhat.com Thu Jul 25 11:49:15 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Jul 2013 13:49:15 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51EFDC0C.3040606@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> <51ED45CB.7080604@redhat.com> <51EEAAA9.2020001@redhat.com> <51EFDC0C.3040606@redhat.com> Message-ID: <51F110BB.3090105@redhat.com> On 07/24/2013 03:52 PM, Ana Krivokapic wrote: > On 07/23/2013 06:09 PM, Petr Vobornik wrote: >> On 07/22/2013 04:46 PM, Ana Krivokapic wrote: >>> On 07/18/2013 09:47 AM, Petr Vobornik wrote: >>>> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >>>>> >>>> >>>> Hello, >>>> >>>> 1) IMO we should not create attribute which is just a negation of another. >>>> >>>> 2) We should add set_enabled method to base widget. Existing set_enabled >>>> methods should use it and maintain widget output consistent with the attribute >>>> (ie. one should not directly set the attr and should use set_enabled instead). >>>> The method should be also callable when content is not yet created. >>>> get_enabled methods might become unnecessary - one can get the state form >>>> 'enabled' attribute. >>>> >>> >>> The attached updated patch implements the following changes: >>> >>> 1) set_enabled method has been added to the base widget class. >>> 2) get_enabled/is_enabled methods have been removed. >>> 3) Widget classes that inherit from the base widget class override the >>> set_enabled method where necessary. >>> 4) Using 'enabled: true/false' in the widget definition should now work >>> correctly for all types of widgets. >>> >>> >> >> Thanks. >> >> 1. set_enabled method in input_widget uses `that.input`. Input widget is a >> base class which doesn't set the property and therefore we can't be certain >> that the descendant will set it. Also it may break when you call >> set_enabled(val) before create() . >> >> We should test for `that.input` presence. >> >> Same content-created test should be perform on other places: >> widget.js:1017,1147,2006 >> >> 2. The changes in option_widget_base break disabling if user doesn't have >> write-rights. (can be reproduced when navigated (by manual change of url) to >> service in self-service. >> >> Note the differences between read_only, writable and enabled: >> * read_only - reflects metadata >> * writable - reflects ACL >> * enabled - context specific >> >> read_only and writable don't offer edit interface (label instead of textbox). >> Enabled controls disabled state of textbox. For some widgets the result might >> be the same (radios, checkboxes). >> >> option_widget_base.set_enabled should be changed. The mixin overwrites the >> original method and therefore doesn't set 'enabled' property. >> >> 3. multiple_choice_section.set_enabled should be renamed. It's related to >> individual choices and not the widget itself. And then new set_enabled should >> be added which would call the old one for each choice. >> >> 4. widget.js:3870 - not sure if it's needed but if so, one should also change >> `action_clicked` method. >> > > All fixed. Updated patch attached. > > Thanks for the review. > 1. Following code is incorrect (line 2030): var input = $('input[name="'+that.name+'"]', that.table); if (input) { input.prop('disabled', !enabled); } It will perform document wide search, when that.table is not set, and find all inputs with that.name. The test should be: if (that.table) { $('input[name="'+that.name+'"]', that.table).prop('disabled', !enabled); } 2. There are issues with option_widget_base. This widget is really a beast. a) There is an existing issue - that.container is not set - which revealed itself in this patch. The result is that nested options are not enabled. Attaching a fix. b) I have doubts about option_widget_base changes on line ~1023. It will most-likely work for our cases, but has unwanted behavior. It will set enabled to false if read_only or writable is false. So enabled will remain false even when writable/read_only changes back to true. It won't probably happen, but it might if user would somehow obtain new rights during Web UI lifetime. It may be better if original set_enabled method would be renamed and it would only reflect the desired state in UI. Proposed changes are also in attached diff. I'm thinking about developing a testing page with various widgets where one could test how they behave with various setting. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: set_enabled.diff Type: text/x-patch Size: 3476 bytes Desc: not available URL: From tbabej at redhat.com Thu Jul 25 13:24:18 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 25 Jul 2013 15:24:18 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <51EFB52B.6080400@redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> <51EFB52B.6080400@redhat.com> Message-ID: <1832180.75eSamFC5H@thinkpad7.brq.redhat.com> On Wednesday 24 of July 2013 13:06:19 Martin Kosek wrote: > On 07/24/2013 12:39 PM, Tomas Babej wrote: > > Hi, > > > > this fixes the > > > > https://fedorahosted.org/freeipa/ticket/3811 > > > > Tomas > > Shouldn't we also add '-E' parameter like we do with in other install tools' > shebang? > > Martin I added the flag. Please note that there is inconsistency in usage of the user-defined Python variables. About half of the scripts use the -E parameter. Even if we restrict ourselves to the 'install' tools, there are exceptions, like ipa-adtrust-install. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0079-2-Change-shebang-to-absolute-path-in-ipa-client-automo.patch Type: text/x-patch Size: 801 bytes Desc: not available URL: From mkosek at redhat.com Thu Jul 25 13:29:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Jul 2013 15:29:33 +0200 Subject: [Freeipa-devel] [PATCH 0079] Change shebang to absolute path in ipa-client-automount In-Reply-To: <1832180.75eSamFC5H@thinkpad7.brq.redhat.com> References: <3253108.1Emm3X1Esx@thinkpad7.brq.redhat.com> <51EFB52B.6080400@redhat.com> <1832180.75eSamFC5H@thinkpad7.brq.redhat.com> Message-ID: <51F1283D.4040801@redhat.com> On 07/25/2013 03:24 PM, Tomas Babej wrote: > On Wednesday 24 of July 2013 13:06:19 Martin Kosek wrote: >> On 07/24/2013 12:39 PM, Tomas Babej wrote: >>> Hi, >>> >>> this fixes the >>> >>> https://fedorahosted.org/freeipa/ticket/3811 >>> >>> Tomas >> >> Shouldn't we also add '-E' parameter like we do with in other install tools' >> shebang? >> >> Martin > > I added the flag. > > Please note that there is inconsistency in usage of the user-defined Python variables. > > About half of the scripts use the -E parameter. Even if we restrict ourselves to > the 'install' tools, there are exceptions, like ipa-adtrust-install. Right, we fill fix those too if the need arises. > > Tomas > ACK. Pushed to master, ipa-3-2. Martin From tbabej at redhat.com Thu Jul 25 13:39:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 25 Jul 2013 15:39:59 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F0D40E.705@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CF8A.8030000@redhat.com> <51F0D40E.705@redhat.com> Message-ID: <3535696.ENRAFr1IKS@thinkpad7.brq.redhat.com> On Thursday 25 of July 2013 09:30:22 Jan Cholasta wrote: > On 25.7.2013 09:11, Petr Spacek wrote: > > On 25.7.2013 09:03, Alexander Bokovoy wrote: > >> On Thu, 25 Jul 2013, Petr Spacek wrote: > >>> On 24.7.2013 22:18, Tomas Babej wrote: > >>>> Hi, > >>>> > >>>> When converting the result obtained by python-ldap library, > >>>> we need to skip unresolved referral entries, since they cannot > >>>> be converted. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3814 > >>> > >>> I'm not sure if a simple 'skip it' approach is the right one. > >>> Shouldn't it > >>> print/log a warning at least? Do you know all implications? Are you sure > >>> that this will not break something else silently? > >>> > >>> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in > >>> AD?) > >> AD DC often answers with proper result and then several referrals to > >> other internal resources to complement the search if you are asking for > >> wide-open search (default). We are not interested in these referrals for > >> various reasons, including the fact that we are looking at the > >> authoritative DC and it has all the needed info. > >> > >> At best, we could define an option that forces us doing referral chasing > >> to fetch remaining results but this is not something really needed right > >> now. > > > > I understand that we don't need referrals now, but the question is > > 'Could it break something? Silently? In the future?'. > > > > E.g. the option 'follow referrals' (defaulting to False) is IMHO much > > much better. > > > > The point is that we don't need to implement referral chasing right now, > > just thrown an exception if somebody tries to switch 'follow referrals' > > option to True. IMHO this will prevent surprises in the future, because > > it is absolutely clear that referrals are not followed. > > > > IMO a comment is good enough. I don't think adding options that aren't > used anywhere is a good thing to do. > > Honza > > -- > Jan Cholasta I considered adding an options for that, but decided against it in the end since it would have to bubble down through many layers, while, as Honza says, not being used anywhere. To make sure that this change does not cause problems, I think we agree to scream at DEBUG level to the log if the referral entry is ignored, and at WARNING level if the referral resolution is turned on in underlying library on the connection level. Tomas From jhrozek at redhat.com Thu Jul 25 13:53:23 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 25 Jul 2013 15:53:23 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <3535696.ENRAFr1IKS@thinkpad7.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <51F0CF8A.8030000@redhat.com> <51F0D40E.705@redhat.com> <3535696.ENRAFr1IKS@thinkpad7.brq.redhat.com> Message-ID: <20130725135323.GP20927@hendrix.brq.redhat.com> On Thu, Jul 25, 2013 at 03:39:59PM +0200, Tomas Babej wrote: > On Thursday 25 of July 2013 09:30:22 Jan Cholasta wrote: > > On 25.7.2013 09:11, Petr Spacek wrote: > > > On 25.7.2013 09:03, Alexander Bokovoy wrote: > > >> On Thu, 25 Jul 2013, Petr Spacek wrote: > > >>> On 24.7.2013 22:18, Tomas Babej wrote: > > >>>> Hi, > > >>>> > > >>>> When converting the result obtained by python-ldap library, > > >>>> we need to skip unresolved referral entries, since they cannot > > >>>> be converted. > > >>>> > > >>>> https://fedorahosted.org/freeipa/ticket/3814 > > >>> > > >>> I'm not sure if a simple 'skip it' approach is the right one. > > >>> Shouldn't it > > >>> print/log a warning at least? Do you know all implications? Are you sure > > >>> that this will not break something else silently? > > >>> > > >>> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in > > >>> AD?) > > >> AD DC often answers with proper result and then several referrals to > > >> other internal resources to complement the search if you are asking for > > >> wide-open search (default). We are not interested in these referrals for > > >> various reasons, including the fact that we are looking at the > > >> authoritative DC and it has all the needed info. > > >> > > >> At best, we could define an option that forces us doing referral chasing > > >> to fetch remaining results but this is not something really needed right > > >> now. > > > > > > I understand that we don't need referrals now, but the question is > > > 'Could it break something? Silently? In the future?'. > > > > > > E.g. the option 'follow referrals' (defaulting to False) is IMHO much > > > much better. > > > > > > The point is that we don't need to implement referral chasing right now, > > > just thrown an exception if somebody tries to switch 'follow referrals' > > > option to True. IMHO this will prevent surprises in the future, because > > > it is absolutely clear that referrals are not followed. > > > > > > > IMO a comment is good enough. I don't think adding options that aren't > > used anywhere is a good thing to do. > > > > Honza > > > > -- > > Jan Cholasta > > I considered adding an options for that, but decided against it in the end > since it would have to bubble down through many layers, while, as Honza says, > not being used anywhere. > > To make sure that this change does not cause problems, I think we agree to > scream at DEBUG level to the log if the referral entry is ignored, and > at WARNING level if the referral resolution is turned on in underlying library > on the connection level. > > Tomas For what it's worth, the SSSD ignores referrals completely when talking to AD. So disabling or ignoring referrals is the right thing to do here. From akrivoka at redhat.com Thu Jul 25 20:18:18 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 25 Jul 2013 22:18:18 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51EFF3BC.1050909@redhat.com> References: <51E7D2AD.7020600@redhat.com> <51E7D2EE.4050501@redhat.com> <51EEA628.3020707@redhat.com> <51EFF3BC.1050909@redhat.com> Message-ID: <51F1880A.3090802@redhat.com> On 07/24/2013 05:33 PM, Petr Vobornik wrote: > On 07/23/2013 05:50 PM, Ana Krivokapic wrote: >> On 07/18/2013 01:35 PM, Petr Vobornik wrote: >>> On 07/18/2013 01:34 PM, Petr Vobornik wrote: >>>> [PATCH] 431 Web UI integration tests: Add trust tests >>>> >>>> [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions >>>> >>>> [PATCH] 433 Web UI integration tests: Verify data after add and mod >>>> >>>> [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps >>>> >>>> Heavily inspired by code from xmlrpc tests. >>>> >>>> To obtain ranges, this patch also adds method to execute FreeIPA command >>>> through Web UI. >>>> It uses Web UI instead of ipalib so it doesn't need to care about >>>> authentication on a test-runner machine. >>>> >>>> All: https://fedorahosted.org/freeipa/ticket/3744 >>> >>> And now the patches... >>> > > > Thanks for the review. > >> Patch 431: >> - In case 'ipa-adtrust-install' has not been run on the system, but 'has_trusts' >> is configured in 'ui_test.conf', trust tests fail. I suggest checking for >> 'ipa-adtrust-install' with 'adtrust_is_enabled' command and then skipping tests >> if trusts are not enabled. > > IMO it's correct behavior - you want to test the feature, but server is > misconfigured - fail. OK, agreed. > >> >> Patch 432: >> - Docstrings for 'has_ca()' and 'has_dns()' state that 'FreeIPA server was >> installed *without* CA/DNS' when they shoud state *with*. >> >> Patch 433: >> - Please also add docstrings for newly added methods. >> - The long 'if' statement in 'validate_fields()' can be shortened by using the >> 'in' keyword instead of individual string comparisons. For example: >> elif ftype in ('textbox', 'password', 'combobox'): >> actual = self.get_field_value(key, parent, 'input') >> - IIUC, the code in validate_fields() compares lists irrespective of element >> order. If this is the case, it can be replaced by simply 'sorted(expected) == >> sorted(actual)'. >> - In 'basic_crud()', shouldn't validate_fields with 'add_v' be called right >> after 'add_record'? The way it is now, data only gets validated in case of data >> modification, but not after initial addition. >> >> Patch 434: >> - The "if 'ipasecondarybaserid' in idrange" block should be nested under the "if >> 'ipasecondarybaserid' in idrange" block, since it assumes that the 'base_rid' >> variable is set. >> - Please remove trailing semicolons. > > Fixed > >> >> >> General comments (these comments are by no means a requirement, and they are not >> a reason for a NACK, just a "nice to have"): >> - Some methods have unused parameters (e.g. validate_fields, basic_crud) >> - Some methods define variables which shadow Python built-ins of the same name > > New patch #438. > >> (e.g. type, all). This can be a problem if you later want to use the built-in. >> - It would be nice to make at least newly added code PEP8 compliant. The 'pep8' >> utility can be used to easily check any python file for PEP8 compliance: >> $ sudo yum install python-pep8 >> $ pep8 /path/to/script.py >> > > Attaching new patch #437 which fixes PEP8 errors (except long lines). Most of > the work was done automatically by autopep8 tool. Thanks for the fixes. ACK on all 6 patches. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Fri Jul 26 09:03:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 11:03:49 +0200 Subject: [Freeipa-devel] [PATCH] 415 Free NSS objects in --external-ca scenario Message-ID: <51F23B75.7090604@redhat.com> In external CA installation, ipa-server-install leaked NSS objects which caused an installation crash later when a subsequent call of NSSConnection tried to free them. Properly freeing the NSS objects avoid this crash. https://fedorahosted.org/freeipa/ticket/3773 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-415-free-nss-objects-in-external-ca-scenario.patch Type: text/x-patch Size: 1729 bytes Desc: not available URL: From tbabej at redhat.com Fri Jul 26 09:07:05 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Jul 2013 11:07:05 +0200 Subject: [Freeipa-devel] [PATCH 0082] Use case-insensitive dict for trusted domain info Message-ID: <7974382.AtMgSypeFm@thinkpad7.brq.redhat.com> Hi, In DomainValidator, we store a dictionary containing information for trusted domains. This is a case-sensitive dictionary keyed by the domain name. We need to use case-insensitive dictionary since domain names are generally case-insensitive. https://fedorahosted.org/freeipa/ticket/3816 Tomas From tbabej at redhat.com Fri Jul 26 09:15:30 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Jul 2013 11:15:30 +0200 Subject: [Freeipa-devel] [PATCH 0082] Use case-insensitive dict for trusted domain info In-Reply-To: <7974382.AtMgSypeFm@thinkpad7.brq.redhat.com> References: <7974382.AtMgSypeFm@thinkpad7.brq.redhat.com> Message-ID: <2136025.0jqZbo4hvD@thinkpad7.brq.redhat.com> On Friday 26 of July 2013 11:07:05 Tomas Babej wrote: > Hi, > > In DomainValidator, we store a dictionary containing information > for trusted domains. This is a case-sensitive dictionary keyed by > the domain name. > > We need to use case-insensitive dictionary since domain names > are generally case-insensitive. > > https://fedorahosted.org/freeipa/ticket/3816 > > Tomas > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Yes, I know. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0082-Use-case-insensitive-dict-for-trusted-domain-info.patch Type: text/x-patch Size: 3831 bytes Desc: not available URL: From tbabej at redhat.com Fri Jul 26 09:29:21 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Jul 2013 11:29:21 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <20130725135323.GP20927@hendrix.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <3535696.ENRAFr1IKS@thinkpad7.brq.redhat.com> <20130725135323.GP20927@hendrix.brq.redhat.com> Message-ID: <2788094.p2uboLLB4i@thinkpad7.brq.redhat.com> On Thursday 25 of July 2013 15:53:23 Jakub Hrozek wrote: > On Thu, Jul 25, 2013 at 03:39:59PM +0200, Tomas Babej wrote: > > On Thursday 25 of July 2013 09:30:22 Jan Cholasta wrote: > > > On 25.7.2013 09:11, Petr Spacek wrote: > > > > On 25.7.2013 09:03, Alexander Bokovoy wrote: > > > >> On Thu, 25 Jul 2013, Petr Spacek wrote: > > > >>> On 24.7.2013 22:18, Tomas Babej wrote: > > > >>>> Hi, > > > >>>> > > > >>>> When converting the result obtained by python-ldap library, > > > >>>> we need to skip unresolved referral entries, since they cannot > > > >>>> be converted. > > > >>>> > > > >>>> https://fedorahosted.org/freeipa/ticket/3814 > > > >>> > > > >>> I'm not sure if a simple 'skip it' approach is the right one. > > > >>> Shouldn't it > > > >>> print/log a warning at least? Do you know all implications? Are you sure > > > >>> that this will not break something else silently? > > > >>> > > > >>> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in > > > >>> AD?) > > > >> AD DC often answers with proper result and then several referrals to > > > >> other internal resources to complement the search if you are asking for > > > >> wide-open search (default). We are not interested in these referrals for > > > >> various reasons, including the fact that we are looking at the > > > >> authoritative DC and it has all the needed info. > > > >> > > > >> At best, we could define an option that forces us doing referral chasing > > > >> to fetch remaining results but this is not something really needed right > > > >> now. > > > > > > > > I understand that we don't need referrals now, but the question is > > > > 'Could it break something? Silently? In the future?'. > > > > > > > > E.g. the option 'follow referrals' (defaulting to False) is IMHO much > > > > much better. > > > > > > > > The point is that we don't need to implement referral chasing right now, > > > > just thrown an exception if somebody tries to switch 'follow referrals' > > > > option to True. IMHO this will prevent surprises in the future, because > > > > it is absolutely clear that referrals are not followed. > > > > > > > > > > IMO a comment is good enough. I don't think adding options that aren't > > > used anywhere is a good thing to do. > > > > > > Honza > > > > > > -- > > > Jan Cholasta > > > > I considered adding an options for that, but decided against it in the end > > since it would have to bubble down through many layers, while, as Honza says, > > not being used anywhere. > > > > To make sure that this change does not cause problems, I think we agree to > > scream at DEBUG level to the log if the referral entry is ignored, and > > at WARNING level if the referral resolution is turned on in underlying library > > on the connection level. > > > > Tomas > > For what it's worth, the SSSD ignores referrals completely when talking > to AD. So disabling or ignoring referrals is the right thing to do here. After some investigation I decided the correct approach here is to scream at the debug level only, when referral is being ignored. We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying connection simply because even if referral chasing is turned on (and therefore we should not get any referrals from python-ldap, since they should have been resolved), queries for AD can return referrals (AD returns them often as a way to provide additional information AFAIU). This can also happen if we are not able to authenticate to the referred server, or resolve the LDAP uri. In case ignoring referrals ever breaks something, we can find the information in the log at the debug level. Doing otherwise would be unnecessarily spamming the log now. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0081-2-Skip-referrals-when-converting-LDAP-result-to-LDAPEn.patch Type: text/x-patch Size: 1416 bytes Desc: not available URL: From jcholast at redhat.com Fri Jul 26 09:50:11 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Jul 2013 11:50:11 +0200 Subject: [Freeipa-devel] [PATCH] 415 Free NSS objects in --external-ca scenario In-Reply-To: <51F23B75.7090604@redhat.com> References: <51F23B75.7090604@redhat.com> Message-ID: <51F24653.4070908@redhat.com> On 26.7.2013 11:03, Martin Kosek wrote: > In external CA installation, ipa-server-install leaked NSS objects > which caused an installation crash later when a subsequent call of > NSSConnection tried to free them. > > Properly freeing the NSS objects avoid this crash. > > https://fedorahosted.org/freeipa/ticket/3773 > ACK. Honza -- Jan Cholasta From jcholast at redhat.com Fri Jul 26 10:16:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Jul 2013 12:16:42 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <2788094.p2uboLLB4i@thinkpad7.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <3535696.ENRAFr1IKS@thinkpad7.brq.redhat.com> <20130725135323.GP20927@hendrix.brq.redhat.com> <2788094.p2uboLLB4i@thinkpad7.brq.redhat.com> Message-ID: <51F24C8A.8040706@redhat.com> On 26.7.2013 11:29, Tomas Babej wrote: > After some investigation I decided the correct approach here is to > scream at the debug level only, when referral is being ignored. > > We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying > connection simply because even if referral chasing is turned on (and therefore > we should not get any referrals from python-ldap, since they should have been > resolved), queries for AD can return referrals (AD returns them often as a way to > provide additional information AFAIU). This can also happen if we are not able > to authenticate to the referred server, or resolve the LDAP uri. > > In case ignoring referrals ever breaks something, we can find the information > in the log at the debug level. Doing otherwise would be unnecessarily spamming > the log now. > > Updated patch attached. Nitpick: I would prefer a shorter message without unnecessary implementation details - something like "Ignoring referral entry {ref}". Also use str(original_attrs) as ref. Honza -- Jan Cholasta From tbabej at redhat.com Fri Jul 26 10:23:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Jul 2013 12:23:52 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F24C8A.8040706@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <2788094.p2uboLLB4i@thinkpad7.brq.redhat.com> <51F24C8A.8040706@redhat.com> Message-ID: <1697905.u9IalWXYx0@thinkpad7.brq.redhat.com> On Friday 26 of July 2013 12:16:42 Jan Cholasta wrote: > On 26.7.2013 11:29, Tomas Babej wrote: > > After some investigation I decided the correct approach here is to > > scream at the debug level only, when referral is being ignored. > > > > We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying > > connection simply because even if referral chasing is turned on (and therefore > > we should not get any referrals from python-ldap, since they should have been > > resolved), queries for AD can return referrals (AD returns them often as a way to > > provide additional information AFAIU). This can also happen if we are not able > > to authenticate to the referred server, or resolve the LDAP uri. > > > > In case ignoring referrals ever breaks something, we can find the information > > in the log at the debug level. Doing otherwise would be unnecessarily spamming > > the log now. > > > > Updated patch attached. > > Nitpick: I would prefer a shorter message without unnecessary > implementation details - something like "Ignoring referral entry {ref}". > Also use str(original_attrs) as ref. > > Honza > > -- > Jan Cholasta Agreed, fixed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0081-3-Skip-referrals-when-converting-LDAP-result-to-LDAPEn.patch Type: text/x-patch Size: 1335 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 26 10:54:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 12:54:05 +0200 Subject: [Freeipa-devel] [PATCH] 415 Free NSS objects in --external-ca scenario In-Reply-To: <51F24653.4070908@redhat.com> References: <51F23B75.7090604@redhat.com> <51F24653.4070908@redhat.com> Message-ID: <51F2554D.6060407@redhat.com> On 07/26/2013 11:50 AM, Jan Cholasta wrote: > On 26.7.2013 11:03, Martin Kosek wrote: >> In external CA installation, ipa-server-install leaked NSS objects >> which caused an installation crash later when a subsequent call of >> NSSConnection tried to free them. >> >> Properly freeing the NSS objects avoid this crash. >> >> https://fedorahosted.org/freeipa/ticket/3773 >> > > ACK. > > Honza > Pushed to master, ipa-3-2 (I just updated Requires to 10.0.4 which fixes the pki-ca issue). Martin From mkosek at redhat.com Fri Jul 26 11:03:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 13:03:25 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <1697905.u9IalWXYx0@thinkpad7.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <2788094.p2uboLLB4i@thinkpad7.brq.redhat.com> <51F24C8A.8040706@redhat.com> <1697905.u9IalWXYx0@thinkpad7.brq.redhat.com> Message-ID: <51F2577D.8030906@redhat.com> On 07/26/2013 12:23 PM, Tomas Babej wrote: > On Friday 26 of July 2013 12:16:42 Jan Cholasta wrote: >> On 26.7.2013 11:29, Tomas Babej wrote: >>> After some investigation I decided the correct approach here is to >>> scream at the debug level only, when referral is being ignored. >>> >>> We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying >>> connection simply because even if referral chasing is turned on (and therefore >>> we should not get any referrals from python-ldap, since they should have been >>> resolved), queries for AD can return referrals (AD returns them often as a way to >>> provide additional information AFAIU). This can also happen if we are not able >>> to authenticate to the referred server, or resolve the LDAP uri. >>> >>> In case ignoring referrals ever breaks something, we can find the information >>> in the log at the debug level. Doing otherwise would be unnecessarily spamming >>> the log now. >>> >>> Updated patch attached. >> >> Nitpick: I would prefer a shorter message without unnecessary >> implementation details - something like "Ignoring referral entry {ref}". >> Also use str(original_attrs) as ref. >> >> Honza >> >> -- >> Jan Cholasta > > Agreed, fixed. > > Tomas > Looks OK. Another nitpick: why do you use formatting with .format()? It makes the formatting inconsistent with rest of the code base. I would prefer: + log_msg = 'Referral entry ignored: %s' % str(original_attrs) Martin From akrivoka at redhat.com Fri Jul 26 11:18:00 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Jul 2013 13:18:00 +0200 Subject: [Freeipa-devel] [PATCH 0078] Refactor the interactive prompt logic in idrange_add In-Reply-To: <52847480.ImKuNIMyXu@thinkpad7.brq.redhat.com> References: <3110373.bFp2SkEW4Y@thinkpad7.brq.redhat.com> <52847480.ImKuNIMyXu@thinkpad7.brq.redhat.com> Message-ID: <51F25AE8.20402@redhat.com> On 07/16/2013 05:13 PM, Tomas Babej wrote: > > On Tuesday 16 of July 2013 17:11:46 Tomas Babej wrote: > > > Hi, > > > > > > Make the interactive prompts interpret the following logic: > > > > > > - AD range (dom-sid/dom-name set): > > > require RID base if not set > > > > > > - local range(dom-sid/dom-name not set): > > > a) server with adtrust support: > > > require both RID base and secondary RID base > > > b) server without adtrust support: > > > if any of RID base, secondary RID base set, > > > require both of them > > > > > > https://fedorahosted.org/freeipa/ticket/3786 > > > > > > Tomas > > > > Too quick once again. > > > > Tomas > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Jul 26 11:19:38 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Jul 2013 13:19:38 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <51F2577D.8030906@redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <1697905.u9IalWXYx0@thinkpad7.brq.redhat.com> <51F2577D.8030906@redhat.com> Message-ID: <1512095.jFs3n2RWTL@thinkpad7.brq.redhat.com> On Friday 26 of July 2013 13:03:25 Martin Kosek wrote: > On 07/26/2013 12:23 PM, Tomas Babej wrote: > > On Friday 26 of July 2013 12:16:42 Jan Cholasta wrote: > >> On 26.7.2013 11:29, Tomas Babej wrote: > >>> After some investigation I decided the correct approach here is to > >>> scream at the debug level only, when referral is being ignored. > >>> > >>> We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying > >>> connection simply because even if referral chasing is turned on (and therefore > >>> we should not get any referrals from python-ldap, since they should have been > >>> resolved), queries for AD can return referrals (AD returns them often as a way to > >>> provide additional information AFAIU). This can also happen if we are not able > >>> to authenticate to the referred server, or resolve the LDAP uri. > >>> > >>> In case ignoring referrals ever breaks something, we can find the information > >>> in the log at the debug level. Doing otherwise would be unnecessarily spamming > >>> the log now. > >>> > >>> Updated patch attached. > >> > >> Nitpick: I would prefer a shorter message without unnecessary > >> implementation details - something like "Ignoring referral entry {ref}". > >> Also use str(original_attrs) as ref. > >> > >> Honza > >> > >> -- > >> Jan Cholasta > > > > Agreed, fixed. > > > > Tomas > > > > Looks OK. Another nitpick: why do you use formatting with .format()? It makes > the formatting inconsistent with rest of the code base. > Simply because python documentation recommends using .format(): http://docs.python.org/3.4/library/stdtypes.html#printf-style-string-formatting At some point it was even considered that % would be removed: http://docs.python.org/release/3.1.5/library/stdtypes.html#old-string-formatting-operations > I would prefer: > > + log_msg = 'Referral entry ignored: %s' % str(original_attrs) > > > Martin I have no strong opinions about this. Do we want to impose a restriction on using the new string formatters available in Python since 2.5? Tomas From pvoborni at redhat.com Fri Jul 26 11:38:39 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Jul 2013 13:38:39 +0200 Subject: [Freeipa-devel] [PATCH] 431-434 Web UI integration tests continuation In-Reply-To: <51F1880A.3090802@redhat.com> References: <51E7D2AD.7020600@redhat.com> <51E7D2EE.4050501@redhat.com> <51EEA628.3020707@redhat.com> <51EFF3BC.1050909@redhat.com> <51F1880A.3090802@redhat.com> Message-ID: <51F25FBF.2060301@redhat.com> On 07/25/2013 10:18 PM, Ana Krivokapic wrote: > On 07/24/2013 05:33 PM, Petr Vobornik wrote: >> On 07/23/2013 05:50 PM, Ana Krivokapic wrote: >>> On 07/18/2013 01:35 PM, Petr Vobornik wrote: >>>> On 07/18/2013 01:34 PM, Petr Vobornik wrote: >>>>> [PATCH] 431 Web UI integration tests: Add trust tests >>>>> >>>>> [PATCH] 432 Web UI integration tests: Add ui_driver method descriptions >>>>> >>>>> [PATCH] 433 Web UI integration tests: Verify data after add and mod >>>>> >>>>> [PATCH] 434 Web UI integration tests: Compute range sizes to avoid overlaps snip >>> - Some methods have unused parameters (e.g. validate_fields, basic_crud) >>> - Some methods define variables which shadow Python built-ins of the same name >> >> New patch #438. snip >> >> Attaching new patch #437 which fixes PEP8 errors (except long lines). Most of >> the work was done automatically by autopep8 tool. > > Thanks for the fixes. ACK on all 6 patches. > Pushed to master. -- Petr Vobornik From mkosek at redhat.com Fri Jul 26 11:39:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 13:39:01 +0200 Subject: [Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry In-Reply-To: <1512095.jFs3n2RWTL@thinkpad7.brq.redhat.com> References: <2340732.6lxHRhKoy8@thinkpad7.brq.redhat.com> <1697905.u9IalWXYx0@thinkpad7.brq.redhat.com> <51F2577D.8030906@redhat.com> <1512095.jFs3n2RWTL@thinkpad7.brq.redhat.com> Message-ID: <51F25FD5.3000900@redhat.com> On 07/26/2013 01:19 PM, Tomas Babej wrote: > On Friday 26 of July 2013 13:03:25 Martin Kosek wrote: >> On 07/26/2013 12:23 PM, Tomas Babej wrote: >>> On Friday 26 of July 2013 12:16:42 Jan Cholasta wrote: >>>> On 26.7.2013 11:29, Tomas Babej wrote: >>>>> After some investigation I decided the correct approach here is to >>>>> scream at the debug level only, when referral is being ignored. >>>>> >>>>> We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying >>>>> connection simply because even if referral chasing is turned on (and therefore >>>>> we should not get any referrals from python-ldap, since they should have been >>>>> resolved), queries for AD can return referrals (AD returns them often as a way to >>>>> provide additional information AFAIU). This can also happen if we are not able >>>>> to authenticate to the referred server, or resolve the LDAP uri. >>>>> >>>>> In case ignoring referrals ever breaks something, we can find the information >>>>> in the log at the debug level. Doing otherwise would be unnecessarily spamming >>>>> the log now. >>>>> >>>>> Updated patch attached. >>>> >>>> Nitpick: I would prefer a shorter message without unnecessary >>>> implementation details - something like "Ignoring referral entry {ref}". >>>> Also use str(original_attrs) as ref. >>>> >>>> Honza >>>> >>>> -- >>>> Jan Cholasta >>> >>> Agreed, fixed. >>> >>> Tomas >>> >> >> Looks OK. Another nitpick: why do you use formatting with .format()? It makes >> the formatting inconsistent with rest of the code base. >> > > Simply because python documentation recommends using .format(): > > http://docs.python.org/3.4/library/stdtypes.html#printf-style-string-formatting > > At some point it was even considered that % would be removed: > > http://docs.python.org/release/3.1.5/library/stdtypes.html#old-string-formatting-operations > >> I would prefer: >> >> + log_msg = 'Referral entry ignored: %s' % str(original_attrs) >> >>> Martin > > I have no strong opinions about this. Do we want to impose a restriction on using the new > string formatters available in Python since 2.5? > > Tomas > We do not need to impose a restriction. I was just thinking about this - I have no strong opinions about it either. Also discussed with Petr3, he is fine with using format function. So ACK. Pushed to master. Martin From mkosek at redhat.com Fri Jul 26 11:43:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 13:43:23 +0200 Subject: [Freeipa-devel] [PATCH] 416 Use valid LDAP search base in migration plugin Message-ID: <51F260DB.4090404@redhat.com> One find_entry_by_attr call did not set a search base leading to LDAP search call with zero search base. This leads to false negative results from LDAP. ---- Pushed to master, ipa-3-2 as a one-liner. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-416-use-valid-ldap-search-base-in-migration-plugin.patch Type: text/x-patch Size: 1185 bytes Desc: not available URL: From akrivoka at redhat.com Fri Jul 26 11:56:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Jul 2013 13:56:53 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51F110BB.3090105@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> <51ED45CB.7080604@redhat.com> <51EEAAA9.2020001@redhat.com> <51EFDC0C.3040606@redhat.com> <51F110BB.3090105@redhat.com> Message-ID: <51F26405.8030907@redhat.com> On 07/25/2013 01:49 PM, Petr Vobornik wrote: > On 07/24/2013 03:52 PM, Ana Krivokapic wrote: >> On 07/23/2013 06:09 PM, Petr Vobornik wrote: >>> On 07/22/2013 04:46 PM, Ana Krivokapic wrote: >>>> On 07/18/2013 09:47 AM, Petr Vobornik wrote: >>>>> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >>>>>> >>>>> >>>>> Hello, >>>>> >>>>> 1) IMO we should not create attribute which is just a negation of another. >>>>> >>>>> 2) We should add set_enabled method to base widget. Existing set_enabled >>>>> methods should use it and maintain widget output consistent with the >>>>> attribute >>>>> (ie. one should not directly set the attr and should use set_enabled >>>>> instead). >>>>> The method should be also callable when content is not yet created. >>>>> get_enabled methods might become unnecessary - one can get the state form >>>>> 'enabled' attribute. >>>>> >>>> >>>> The attached updated patch implements the following changes: >>>> >>>> 1) set_enabled method has been added to the base widget class. >>>> 2) get_enabled/is_enabled methods have been removed. >>>> 3) Widget classes that inherit from the base widget class override the >>>> set_enabled method where necessary. >>>> 4) Using 'enabled: true/false' in the widget definition should now work >>>> correctly for all types of widgets. >>>> >>>> >>> >>> Thanks. >>> >>> 1. set_enabled method in input_widget uses `that.input`. Input widget is a >>> base class which doesn't set the property and therefore we can't be certain >>> that the descendant will set it. Also it may break when you call >>> set_enabled(val) before create() . >>> >>> We should test for `that.input` presence. >>> >>> Same content-created test should be perform on other places: >>> widget.js:1017,1147,2006 >>> >>> 2. The changes in option_widget_base break disabling if user doesn't have >>> write-rights. (can be reproduced when navigated (by manual change of url) to >>> service in self-service. >>> >>> Note the differences between read_only, writable and enabled: >>> * read_only - reflects metadata >>> * writable - reflects ACL >>> * enabled - context specific >>> >>> read_only and writable don't offer edit interface (label instead of textbox). >>> Enabled controls disabled state of textbox. For some widgets the result might >>> be the same (radios, checkboxes). >>> >>> option_widget_base.set_enabled should be changed. The mixin overwrites the >>> original method and therefore doesn't set 'enabled' property. >>> >>> 3. multiple_choice_section.set_enabled should be renamed. It's related to >>> individual choices and not the widget itself. And then new set_enabled should >>> be added which would call the old one for each choice. >>> >>> 4. widget.js:3870 - not sure if it's needed but if so, one should also change >>> `action_clicked` method. >>> >> >> All fixed. Updated patch attached. >> >> Thanks for the review. >> > > 1. Following code is incorrect (line 2030): > > var input = $('input[name="'+that.name+'"]', that.table); > if (input) { > input.prop('disabled', !enabled); > } > > It will perform document wide search, when that.table is not set, and find all > inputs with that.name. The test should be: > > if (that.table) { > $('input[name="'+that.name+'"]', that.table).prop('disabled', > !enabled); Fixed. > } > > 2. There are issues with option_widget_base. This widget is really a beast. > > a) There is an existing issue - that.container is not set - which revealed > itself in this patch. The result is that nested options are not enabled. > Attaching a fix. > > b) I have doubts about option_widget_base changes on line ~1023. It will > most-likely work for our cases, but has unwanted behavior. It will set enabled > to false if read_only or writable is false. So enabled will remain false even > when writable/read_only changes back to true. It won't probably happen, but it > might if user would somehow obtain new rights during Web UI lifetime. > > It may be better if original set_enabled method would be renamed and it would > only reflect the desired state in UI. > > Proposed changes are also in attached diff. Agreed, changes squashed to the patch. > > > I'm thinking about developing a testing page with various widgets where one > could test how they behave with various setting. > Good idea, I opened a ticket: https://fedorahosted.org/freeipa/ticket/3818 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0047-04-Honor-enabled-option-for-widgets.patch Type: text/x-patch Size: 16256 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 26 11:59:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 13:59:50 +0200 Subject: [Freeipa-devel] [PATCH 0078] Refactor the interactive prompt logic in idrange_add In-Reply-To: <51F25AE8.20402@redhat.com> References: <3110373.bFp2SkEW4Y@thinkpad7.brq.redhat.com> <52847480.ImKuNIMyXu@thinkpad7.brq.redhat.com> <51F25AE8.20402@redhat.com> Message-ID: <51F264B6.2010706@redhat.com> On 07/26/2013 01:18 PM, Ana Krivokapic wrote: > On 07/16/2013 05:13 PM, Tomas Babej wrote: >> >> On Tuesday 16 of July 2013 17:11:46 Tomas Babej wrote: >> >>> Hi, >> >>> >> >>> Make the interactive prompts interpret the following logic: >> >>> >> >>> - AD range (dom-sid/dom-name set): >> >>> require RID base if not set >> >>> >> >>> - local range(dom-sid/dom-name not set): >> >>> a) server with adtrust support: >> >>> require both RID base and secondary RID base >> >>> b) server without adtrust support: >> >>> if any of RID base, secondary RID base set, >> >>> require both of them >> >>> >> >>> https://fedorahosted.org/freeipa/ticket/3786 >> >>> >> >>> Tomas >> >> >> >> Too quick once again. >> >> >> >> Tomas >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to master. Martin From pvoborni at redhat.com Fri Jul 26 12:32:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Jul 2013 14:32:16 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> Message-ID: <51F26C50.1050804@redhat.com> On 07/17/2013 01:47 PM, Tomas Babej wrote: >> I will release version 3.5 before end of this week. I have some small fixes >> ready so it is worth to release it now. >> >> To summarize the discussion - please remove following options from >> configuration file and LDAP schema: >> cache_ttl >> psearch (attribute idnsPersistentSearch in idnsConfigObject) >> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >> >> -- >> Petr^2 Spacek > > I have a patch ready, but it can't be tested until 3.5 is out. > > Tomas > ACK for Web UI changes. -- Petr Vobornik From rmeggins at redhat.com Fri Jul 26 14:04:49 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 26 Jul 2013 08:04:49 -0600 Subject: [Freeipa-devel] [PATCH] 416 Use valid LDAP search base in migration plugin In-Reply-To: <51F260DB.4090404@redhat.com> References: <51F260DB.4090404@redhat.com> Message-ID: <51F28201.3080808@redhat.com> On 07/26/2013 05:43 AM, Martin Kosek wrote: > One find_entry_by_attr call did not set a search base leading to > LDAP search call with zero search base. This leads to false negative > results from LDAP. > > ---- > > Pushed to master, ipa-3-2 as a one-liner. Does the migrate code correctly handle the search return? Before it was working fine when it got the err=32 - it just assumed the user did not already exist. With the correct search base, the search will return err=0, and will return no search entries, which migration should assume means the user does not already exist. > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Jul 26 14:37:17 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Jul 2013 16:37:17 +0200 Subject: [Freeipa-devel] [PATCH] 0047 Honor 'enabled' option for widgets In-Reply-To: <51F26405.8030907@redhat.com> References: <51E6EDFD.8060103@redhat.com> <51E79D84.7010304@redhat.com> <51ED45CB.7080604@redhat.com> <51EEAAA9.2020001@redhat.com> <51EFDC0C.3040606@redhat.com> <51F110BB.3090105@redhat.com> <51F26405.8030907@redhat.com> Message-ID: <51F2899D.8080904@redhat.com> On 07/26/2013 01:56 PM, Ana Krivokapic wrote: > On 07/25/2013 01:49 PM, Petr Vobornik wrote: >> On 07/24/2013 03:52 PM, Ana Krivokapic wrote: >>> On 07/23/2013 06:09 PM, Petr Vobornik wrote: >>>> On 07/22/2013 04:46 PM, Ana Krivokapic wrote: >>>>> On 07/18/2013 09:47 AM, Petr Vobornik wrote: >>>>>> On 07/17/2013 09:18 PM, Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3793. >>>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> 1) IMO we should not create attribute which is just a negation of another. >>>>>> >>>>>> 2) We should add set_enabled method to base widget. Existing set_enabled >>>>>> methods should use it and maintain widget output consistent with the >>>>>> attribute >>>>>> (ie. one should not directly set the attr and should use set_enabled >>>>>> instead). >>>>>> The method should be also callable when content is not yet created. >>>>>> get_enabled methods might become unnecessary - one can get the state form >>>>>> 'enabled' attribute. >>>>>> >>>>> >>>>> The attached updated patch implements the following changes: >>>>> >>>>> 1) set_enabled method has been added to the base widget class. >>>>> 2) get_enabled/is_enabled methods have been removed. >>>>> 3) Widget classes that inherit from the base widget class override the >>>>> set_enabled method where necessary. >>>>> 4) Using 'enabled: true/false' in the widget definition should now work >>>>> correctly for all types of widgets. >>>>> >>>>> >>>> >>>> Thanks. >>>> >>>> 1. set_enabled method in input_widget uses `that.input`. Input widget is a >>>> base class which doesn't set the property and therefore we can't be certain >>>> that the descendant will set it. Also it may break when you call >>>> set_enabled(val) before create() . >>>> >>>> We should test for `that.input` presence. >>>> >>>> Same content-created test should be perform on other places: >>>> widget.js:1017,1147,2006 >>>> >>>> 2. The changes in option_widget_base break disabling if user doesn't have >>>> write-rights. (can be reproduced when navigated (by manual change of url) to >>>> service in self-service. >>>> >>>> Note the differences between read_only, writable and enabled: >>>> * read_only - reflects metadata >>>> * writable - reflects ACL >>>> * enabled - context specific >>>> >>>> read_only and writable don't offer edit interface (label instead of textbox). >>>> Enabled controls disabled state of textbox. For some widgets the result might >>>> be the same (radios, checkboxes). >>>> >>>> option_widget_base.set_enabled should be changed. The mixin overwrites the >>>> original method and therefore doesn't set 'enabled' property. >>>> >>>> 3. multiple_choice_section.set_enabled should be renamed. It's related to >>>> individual choices and not the widget itself. And then new set_enabled should >>>> be added which would call the old one for each choice. >>>> >>>> 4. widget.js:3870 - not sure if it's needed but if so, one should also change >>>> `action_clicked` method. >>>> >>> >>> All fixed. Updated patch attached. >>> >>> Thanks for the review. >>> >> >> 1. Following code is incorrect (line 2030): >> >> var input = $('input[name="'+that.name+'"]', that.table); >> if (input) { >> input.prop('disabled', !enabled); >> } >> >> It will perform document wide search, when that.table is not set, and find all >> inputs with that.name. The test should be: >> >> if (that.table) { >> $('input[name="'+that.name+'"]', that.table).prop('disabled', >> !enabled); > > Fixed. > >> } >> >> 2. There are issues with option_widget_base. This widget is really a beast. >> >> a) There is an existing issue - that.container is not set - which revealed >> itself in this patch. The result is that nested options are not enabled. >> Attaching a fix. >> >> b) I have doubts about option_widget_base changes on line ~1023. It will >> most-likely work for our cases, but has unwanted behavior. It will set enabled >> to false if read_only or writable is false. So enabled will remain false even >> when writable/read_only changes back to true. It won't probably happen, but it >> might if user would somehow obtain new rights during Web UI lifetime. >> >> It may be better if original set_enabled method would be renamed and it would >> only reflect the desired state in UI. >> >> Proposed changes are also in attached diff. > > Agreed, changes squashed to the patch. > >> >> >> I'm thinking about developing a testing page with various widgets where one >> could test how they behave with various setting. >> > > Good idea, I opened a ticket: https://fedorahosted.org/freeipa/ticket/3818 > ACK and pushed to master. -- Petr Vobornik From mkosek at redhat.com Fri Jul 26 15:28:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Jul 2013 17:28:25 +0200 Subject: [Freeipa-devel] [PATCH] 416 Use valid LDAP search base in migration plugin In-Reply-To: <51F28201.3080808@redhat.com> References: <51F260DB.4090404@redhat.com> <51F28201.3080808@redhat.com> Message-ID: <51F29599.2090009@redhat.com> On 07/26/2013 04:04 PM, Rich Megginson wrote: > On 07/26/2013 05:43 AM, Martin Kosek wrote: >> One find_entry_by_attr call did not set a search base leading to >> LDAP search call with zero search base. This leads to false negative >> results from LDAP. >> >> ---- >> >> Pushed to master, ipa-3-2 as a one-liner. > > Does the migrate code correctly handle the search return? Before it was > working fine when it got the err=32 - it just assumed the user did not already > exist. With the correct search base, the search will return err=0, and will > return no search entries, which migration should assume means the user does not > already exist. > Thanks for double-checking this Rich. But our LDAP library raised exception when LDAP returns no entry, I double checked this particular call I changed: >>> conn.find_entry_by_attr('krbprincipalname', 'admin at EXAMPLE.COM', 'krbprincipalaux', [''], DN(api.env.container_user, api.env.basedn)) LDAPEntry(ipapython.dn.DN('uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'), {}) >>> conn.find_entry_by_attr('krbprincipalname', 'doesnotexist at EXAMPLE.COM', 'krbprincipalaux', [''], DN(api.env.container_user, api.env.basedn)) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1299, in find_entry_by_attr (entries, truncated) = self.find_entries(filter, attrs_list, base_dn) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1248, in find_entries raise errors.NotFound(reason='no such entry') ipalib.errors.NotFound: no such entry So the change should work correctly. Martin From pviktori at redhat.com Fri Jul 26 15:47:26 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Jul 2013 17:47:26 +0200 Subject: [Freeipa-devel] [PATCH] 0255 Add the new no_member option to CLI tests Message-ID: <51F29A0E.2030408@redhat.com> Hello, This adds the new no_members option to the CLI parsing tests. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0255-Add-the-new-no_member-option-to-CLI-tests.patch Type: text/x-patch Size: 2487 bytes Desc: not available URL: From akrivoka at redhat.com Fri Jul 26 15:54:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Jul 2013 17:54:35 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI In-Reply-To: <51E685B1.4080401@redhat.com> References: <51E578E5.40806@redhat.com> <51E685B1.4080401@redhat.com> Message-ID: <51F29BBB.4050705@redhat.com> On 07/17/2013 01:53 PM, Petr Vobornik wrote: > On 07/16/2013 06:46 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. >> > > Hello, > > Thanks for the patch, some comments: > > 1) idrange.js:183 I would avoid modifying widget html output in form methods. > In this case you can simply add `layout: 'vertical'` to 'iparangetype' field > definition. > > 2) idrange.js:187 Can be replaced by adding `enabled: false` to > 'ipanttrusteddomainsid' field definition > > 3) I would rather see the switching logic encapsulated in a policy object than > in a dialog. The main reason is to avoid using init() call in the factory. > Most code other than method definitions in factory methods create mess in > inheritance chain. Long term plan is to remove most of these calls. In this > case, you can define public init method in the policy which will be > automatically called after dialog instantiation. > > 4) IIUIC 'ipabaserid' have to be set together with 'ipanttrusteddomainsid' -> > 'ipabaserid' should be made required when is_ad_trust is true. > > 5) As I read plugins/idrange.py:487-530, the logic for enabling/making > required 'ipabaserid' and 'ipasecondarybaserid' is quite more complex than > implemented. > > IIUIC 'ipasecondarybaserid' should be required and enabled only when > 'ipabaserid' is set. Additionally, both should be required and enabled if > adtrust_is_enabled (in UI: `IPA.trust_enabled`). All fixed, updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0045-02-Expose-ipaRangeType-in-Web-UI.patch Type: text/x-patch Size: 10030 bytes Desc: not available URL: From rmeggins at redhat.com Fri Jul 26 15:54:02 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 26 Jul 2013 09:54:02 -0600 Subject: [Freeipa-devel] [PATCH] 416 Use valid LDAP search base in migration plugin In-Reply-To: <51F29599.2090009@redhat.com> References: <51F260DB.4090404@redhat.com> <51F28201.3080808@redhat.com> <51F29599.2090009@redhat.com> Message-ID: <51F29B9A.5060800@redhat.com> On 07/26/2013 09:28 AM, Martin Kosek wrote: > On 07/26/2013 04:04 PM, Rich Megginson wrote: >> On 07/26/2013 05:43 AM, Martin Kosek wrote: >>> One find_entry_by_attr call did not set a search base leading to >>> LDAP search call with zero search base. This leads to false negative >>> results from LDAP. >>> >>> ---- >>> >>> Pushed to master, ipa-3-2 as a one-liner. >> Does the migrate code correctly handle the search return? Before it was >> working fine when it got the err=32 - it just assumed the user did not already >> exist. With the correct search base, the search will return err=0, and will >> return no search entries, which migration should assume means the user does not >> already exist. >> > Thanks for double-checking this Rich. But our LDAP library raised exception > when LDAP returns no entry, I double checked this particular call I changed: > >>>> conn.find_entry_by_attr('krbprincipalname', 'admin at EXAMPLE.COM', > 'krbprincipalaux', [''], DN(api.env.container_user, api.env.basedn)) > LDAPEntry(ipapython.dn.DN('uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'), > {}) > >>>> conn.find_entry_by_attr('krbprincipalname', 'doesnotexist at EXAMPLE.COM', > 'krbprincipalaux', [''], DN(api.env.container_user, api.env.basedn)) > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1299, in > find_entry_by_attr > (entries, truncated) = self.find_entries(filter, attrs_list, base_dn) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1248, in > find_entries > raise errors.NotFound(reason='no such entry') > ipalib.errors.NotFound: no such entry > > So the change should work correctly. > > Martin ok - ack From npmccallum at redhat.com Fri Jul 26 16:01:12 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 26 Jul 2013 12:01:12 -0400 (EDT) Subject: [Freeipa-devel] OTP CLI Proposal In-Reply-To: <1282701844.5924359.1374854370121.JavaMail.root@redhat.com> Message-ID: <467943142.5925141.1374854472988.JavaMail.root@redhat.com> I have added a proposal for an authentication management CLI to the wiki. It currently includes the ability to manage authentication methods, RADIUS servers and OTP tokens. Please review! http://www.freeipa.org/page/V3/OTP#CLI Nathaniel From akrivoka at redhat.com Fri Jul 26 17:13:56 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Jul 2013 19:13:56 +0200 Subject: [Freeipa-devel] [PATCH] 0255 Add the new no_member option to CLI tests In-Reply-To: <51F29A0E.2030408@redhat.com> References: <51F29A0E.2030408@redhat.com> Message-ID: <51F2AE54.3030400@redhat.com> On 07/26/2013 05:47 PM, Petr Viktorin wrote: > Hello, > This adds the new no_members option to the CLI parsing tests. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Jul 26 18:12:42 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 26 Jul 2013 14:12:42 -0400 Subject: [Freeipa-devel] Announcing the release of Dogtag 10.0.4 Message-ID: <1374862362.2341.74.camel@aleeredhat.laptop> The Dogtag team is proud to announce the fourth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.4-1 pki-ra-10.0.4-1 pki-tps-10.0.4-1 dogtag-pki-10.0.4-1 dogtag-pki-theme-10.0.4-1 pki-console-10.0.4-1 == Highlights since Dogtag 10.0.3 == * Enhanced pkispawn to provide automatic backup and restore mechanism for files modified during the upgrade process. * Improved the summary information at the end of pkispawn to include, among other things, the location of the agent PKCS #12 file. * Fixes to pkispawn and the installation servlets to fix cloning. * Fix to pkispawn to correctly overwrite the pki_issuing_ca when configuring with an external CA. This resolves an issue reported by IPA in BZ #986901. * Numerous fixes to resolve build issues on F19 and RHEL. == Detailed Changes since Dogtag 10.0.3 == akoneru (1): #645 Display the admin p12 file location in the installation summary alee (6): #680 Missing apache-commons-cli dependency #665 cloning is broken for second instance in shared subsystems BZ #973224 - resteasy-base must be split into subpackages -- Add build dependency on systemd to fix build failures on f19. -- Modify pkispawn to handle case where no subsystem certs are generated -- Modify java-tools startup scripts to use correct JNI path awnuk (1): BZ #961522 - Allow key to be exported. cfu (1): BZ #971561 - server-side key generation causes NullPointerException if a parameter is not supplied by the caller (TPS) edewata (6) #582 Man page for pki-upgrade #583 Automatic backup and rollback on upgrade BZ #986901 - Fix confguration issues with external CA. BZ #985111 - token authentication problem on rhel -- Removing JNI_JAR_DIR from /etc/pki/pki.conf. -- Fixed library paths for RHEL. mharmsen (2): BZ #986506 - exclude pki-kra, pki-ocsp and pki-tks from rhel BZ #975939 - RHCS 8.1: "END CERTIFICATE" tag is not on it's own line From dpal at redhat.com Fri Jul 26 23:55:07 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 26 Jul 2013 19:55:07 -0400 Subject: [Freeipa-devel] OTP CLI Proposal In-Reply-To: <467943142.5925141.1374854472988.JavaMail.root@redhat.com> References: <467943142.5925141.1374854472988.JavaMail.root@redhat.com> Message-ID: <51F30C5B.60101@redhat.com> On 07/26/2013 12:01 PM, Nathaniel McCallum wrote: > I have added a proposal for an authentication management CLI to the wiki. It currently includes the ability to manage authentication methods, RADIUS servers and OTP tokens. Please review! > > http://www.freeipa.org/page/V3/OTP#CLI > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel May be use auth-policy instead of auth? "These commands may be run by the admin or by the user. When run by a user, the user should only be able to view, search or modify their own tokens. Admins, however, may perform any action on any user's tokens. " User probably should not be able to modify everything at least in future there should be a way to prevent user from modifying his token and any attribute. IMO it is a policy decision per deployment. Need more thought in future. Probably fine as is for now. Please note that though. May be worth a separate RFE ticket. Again for now probably admins should be able to modify any token however in future we probably want to be able to reduce it only to admins that have a specific role. For example out of 10 admins for IPA only 2 that have token management responsibilities should be able to manage tokens. The use of the command line arguments is close to our current CLI but might not 100% comply to all rules. But this part is way beyond my understanding however our CLI gurus should probably review and chime. What is the ID for the token in the otp-mod or otp-del command ? It is usually serial number. Do you have something else in mind? You are missing the concept of show command for link and otp. Show command shows current values of the specific entry while 'find' helps you to find the entry. Why base32 encoding for the random data and base 64? What should be the lenght limitations for the data to type in and be accepted? Are we going to reject data with low entropy? What is the use case for export? Does it dump the key in clear? Is this a security risk? Can you please fix the formatting so that the commands are more readable? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Mon Jul 29 08:04:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Jul 2013 10:04:14 +0200 Subject: [Freeipa-devel] [PATCH] 0255 Add the new no_member option to CLI tests In-Reply-To: <51F2AE54.3030400@redhat.com> References: <51F29A0E.2030408@redhat.com> <51F2AE54.3030400@redhat.com> Message-ID: <51F621FE.7010404@redhat.com> On 07/26/2013 07:13 PM, Ana Krivokapic wrote: > On 07/26/2013 05:47 PM, Petr Viktorin wrote: >> Hello, >> This adds the new no_members option to the CLI parsing tests. >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Thank you! Pushed to master: 381f22af2525abfe0c314e9f9d5b359770beb36b -- Petr? From pvoborni at redhat.com Mon Jul 29 08:08:10 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 29 Jul 2013 10:08:10 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI In-Reply-To: <51F29BBB.4050705@redhat.com> References: <51E578E5.40806@redhat.com> <51E685B1.4080401@redhat.com> <51F29BBB.4050705@redhat.com> Message-ID: <51F622EA.6040802@redhat.com> On 07/26/2013 05:54 PM, Ana Krivokapic wrote: > On 07/17/2013 01:53 PM, Petr Vobornik wrote: >> On 07/16/2013 06:46 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. >>> >> >> Hello, >> >> Thanks for the patch, some comments: >> >> 1) idrange.js:183 I would avoid modifying widget html output in form methods. >> In this case you can simply add `layout: 'vertical'` to 'iparangetype' field >> definition. >> >> 2) idrange.js:187 Can be replaced by adding `enabled: false` to >> 'ipanttrusteddomainsid' field definition >> >> 3) I would rather see the switching logic encapsulated in a policy object than >> in a dialog. The main reason is to avoid using init() call in the factory. >> Most code other than method definitions in factory methods create mess in >> inheritance chain. Long term plan is to remove most of these calls. In this >> case, you can define public init method in the policy which will be >> automatically called after dialog instantiation. >> >> 4) IIUIC 'ipabaserid' have to be set together with 'ipanttrusteddomainsid' -> >> 'ipabaserid' should be made required when is_ad_trust is true. >> >> 5) As I read plugins/idrange.py:487-530, the logic for enabling/making >> required 'ipabaserid' and 'ipasecondarybaserid' is quite more complex than >> implemented. >> >> IIUIC 'ipasecondarybaserid' should be required and enabled only when >> 'ipabaserid' is set. Additionally, both should be required and enabled if >> adtrust_is_enabled (in UI: `IPA.trust_enabled`). > > All fixed, updated patch attached. > Hello, thanks for the fix. 1. a little issue: There is invalid state when you open the dialog, change type to 'AD domain', close dialog and open it again. Fields are reseted, so 'iparangetype' is defaulted to 'local domain' but all other have the state from 'AD Domain'. Possible fix (init method): type_f.widget.updated.attach(that.on_input_change); -- Petr Vobornik From pviktori at redhat.com Mon Jul 29 08:20:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Jul 2013 10:20:13 +0200 Subject: [Freeipa-devel] OTP CLI Proposal In-Reply-To: <51F30C5B.60101@redhat.com> References: <467943142.5925141.1374854472988.JavaMail.root@redhat.com> <51F30C5B.60101@redhat.com> Message-ID: <51F625BD.6000302@redhat.com> On 07/27/2013 01:55 AM, Dmitri Pal wrote: > On 07/26/2013 12:01 PM, Nathaniel McCallum wrote: >> I have added a proposal for an authentication management CLI to the wiki. It currently includes the ability to manage authentication methods, RADIUS servers and OTP tokens. Please review! >> >> http://www.freeipa.org/page/V3/OTP#CLI >> >> Nathaniel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > May be use auth-policy instead of auth? > > "These commands may be run by the admin or by the user. When run by a > user, the user should only be able to view, search or modify their own > tokens. Admins, however, may perform any action on any user's tokens. " > User probably should not be able to modify everything at least in future > there should be a way to prevent user from modifying his token and any > attribute. IMO it is a policy decision per deployment. Need more thought > in future. Probably fine as is for now. Please note that though. May be > worth a separate RFE ticket. > Again for now probably admins should be able to modify any token however > in future we probably want to be able to reduce it only to admins that > have a specific role. For example out of 10 admins for IPA only 2 that > have token management responsibilities should be able to manage tokens. > > The use of the command line arguments is close to our current CLI but > might not 100% comply to all rules. But this part is way beyond my > understanding however our CLI gurus should probably review and chime. I'm not aware of any formal rules, but to be more consistent with the rest of the CLI: There should be auth-show and auth-find to query the information. For better or worse, `auth` should use a --method argument that sets the named methods and clears any others: auth-mod [--user=LOGIN] [--method=method] e.g. `auth-mod --method=m1 --method=m2` would add methods m1 and m2 and remove all others. The plan is to add options like `--add-method` & `--del-method` later (see https://fedorahosted.org/freeipa/ticket/3054). I'd also think about `auth-mod [--user=LOGIN | --global]`, i.e. requiring an explicit flag for modifying the global settings (without either --user or --global, the command would prompt interactively). The radius-link command looks overloaded, IPA generally splits functionality into several commands: radius-link-add LOGIN [--cn=CN] [--username=STR] radius-link-mod LOGIN [--cn=CN] [--username=STR] radius-link-show LOGIN radius-link-find ... radius-link-del LOGIN Also, we use lowercase option names; otp-{add,find,mod,export} should use `--not-before` & `--not-after`. > What is the ID for the token in the otp-mod or otp-del command ? It is > usually serial number. Do you have something else in mind? > > You are missing the concept of show command for link and otp. Show > command shows current values of the specific entry while 'find' helps > you to find the entry. > > Why base32 encoding for the random data and base 64? What should be the > lenght limitations for the data to type in and be accepted? Are we going > to reject data with low entropy? > > > What is the use case for export? Does it dump the key in clear? Is this > a security risk? > > Can you please fix the formatting so that the commands are more readable? > -- Petr? From akrivoka at redhat.com Mon Jul 29 08:31:57 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 29 Jul 2013 10:31:57 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI In-Reply-To: <51F622EA.6040802@redhat.com> References: <51E578E5.40806@redhat.com> <51E685B1.4080401@redhat.com> <51F29BBB.4050705@redhat.com> <51F622EA.6040802@redhat.com> Message-ID: <51F6287D.8080602@redhat.com> On 07/29/2013 10:08 AM, Petr Vobornik wrote: > On 07/26/2013 05:54 PM, Ana Krivokapic wrote: >> On 07/17/2013 01:53 PM, Petr Vobornik wrote: >>> On 07/16/2013 06:46 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. >>>> >>> >>> Hello, >>> >>> Thanks for the patch, some comments: >>> >>> 1) idrange.js:183 I would avoid modifying widget html output in form methods. >>> In this case you can simply add `layout: 'vertical'` to 'iparangetype' field >>> definition. >>> >>> 2) idrange.js:187 Can be replaced by adding `enabled: false` to >>> 'ipanttrusteddomainsid' field definition >>> >>> 3) I would rather see the switching logic encapsulated in a policy object than >>> in a dialog. The main reason is to avoid using init() call in the factory. >>> Most code other than method definitions in factory methods create mess in >>> inheritance chain. Long term plan is to remove most of these calls. In this >>> case, you can define public init method in the policy which will be >>> automatically called after dialog instantiation. >>> >>> 4) IIUIC 'ipabaserid' have to be set together with 'ipanttrusteddomainsid' -> >>> 'ipabaserid' should be made required when is_ad_trust is true. >>> >>> 5) As I read plugins/idrange.py:487-530, the logic for enabling/making >>> required 'ipabaserid' and 'ipasecondarybaserid' is quite more complex than >>> implemented. >>> >>> IIUIC 'ipasecondarybaserid' should be required and enabled only when >>> 'ipabaserid' is set. Additionally, both should be required and enabled if >>> adtrust_is_enabled (in UI: `IPA.trust_enabled`). >> >> All fixed, updated patch attached. >> > Hello, > > thanks for the fix. > > 1. a little issue: There is invalid state when you open the dialog, change > type to 'AD domain', close dialog and open it again. Fields are reseted, so > 'iparangetype' is defaulted to 'local domain' but all other have the state > from 'AD Domain'. Possible fix (init method): > type_f.widget.updated.attach(that.on_input_change); Thanks for the catch. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0045-03-Expose-ipaRangeType-in-Web-UI.patch Type: text/x-patch Size: 10091 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jul 29 08:42:07 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 29 Jul 2013 10:42:07 +0200 Subject: [Freeipa-devel] [PATCH] 0045 Expose ipaRangeType in Web UI In-Reply-To: <51F6287D.8080602@redhat.com> References: <51E578E5.40806@redhat.com> <51E685B1.4080401@redhat.com> <51F29BBB.4050705@redhat.com> <51F622EA.6040802@redhat.com> <51F6287D.8080602@redhat.com> Message-ID: <51F62ADF.3010403@redhat.com> On 07/29/2013 10:31 AM, Ana Krivokapic wrote: > On 07/29/2013 10:08 AM, Petr Vobornik wrote: >> On 07/26/2013 05:54 PM, Ana Krivokapic wrote: >>> On 07/17/2013 01:53 PM, Petr Vobornik wrote: >>>> On 07/16/2013 06:46 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3759. >>>>> >>>> >>>> Hello, >>>> >>>> Thanks for the patch, some comments: >>>> >>>> 1) idrange.js:183 I would avoid modifying widget html output in form methods. >>>> In this case you can simply add `layout: 'vertical'` to 'iparangetype' field >>>> definition. >>>> >>>> 2) idrange.js:187 Can be replaced by adding `enabled: false` to >>>> 'ipanttrusteddomainsid' field definition >>>> >>>> 3) I would rather see the switching logic encapsulated in a policy object than >>>> in a dialog. The main reason is to avoid using init() call in the factory. >>>> Most code other than method definitions in factory methods create mess in >>>> inheritance chain. Long term plan is to remove most of these calls. In this >>>> case, you can define public init method in the policy which will be >>>> automatically called after dialog instantiation. >>>> >>>> 4) IIUIC 'ipabaserid' have to be set together with 'ipanttrusteddomainsid' -> >>>> 'ipabaserid' should be made required when is_ad_trust is true. >>>> >>>> 5) As I read plugins/idrange.py:487-530, the logic for enabling/making >>>> required 'ipabaserid' and 'ipasecondarybaserid' is quite more complex than >>>> implemented. >>>> >>>> IIUIC 'ipasecondarybaserid' should be required and enabled only when >>>> 'ipabaserid' is set. Additionally, both should be required and enabled if >>>> adtrust_is_enabled (in UI: `IPA.trust_enabled`). >>> >>> All fixed, updated patch attached. >>> >> Hello, >> >> thanks for the fix. >> >> 1. a little issue: There is invalid state when you open the dialog, change >> type to 'AD domain', close dialog and open it again. Fields are reseted, so >> 'iparangetype' is defaulted to 'local domain' but all other have the state >> from 'AD Domain'. Possible fix (init method): >> type_f.widget.updated.attach(that.on_input_change); > > > Thanks for the catch. Updated patch attached. > ACK and pushed to master. -- Petr Vobornik From akrivoka at redhat.com Mon Jul 29 08:57:30 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 29 Jul 2013 10:57:30 +0200 Subject: [Freeipa-devel] [PATCH] 428 Hide delete button in multivalued widget if attr is not writable In-Reply-To: <51E7BF57.6060802@redhat.com> References: <51E7BF57.6060802@redhat.com> Message-ID: <51F62E7A.5090405@redhat.com> On 07/18/2013 12:11 PM, Petr Vobornik wrote: > Hide delete button in multivalued widget if attr is not writable > > https://fedorahosted.org/freeipa/ticket/3799 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Mon Jul 29 09:15:12 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 29 Jul 2013 11:15:12 +0200 Subject: [Freeipa-devel] [PATCH] 429 Make ssh_widget not-editable if attr is readonly In-Reply-To: <51E7BFAB.2000809@redhat.com> References: <51E7BFAB.2000809@redhat.com> Message-ID: <51F632A0.4020002@redhat.com> On 07/18/2013 12:12 PM, Petr Vobornik wrote: > Make ssh_widget not-editable if attr is readonly > > Depends on patch pvoborni-428. > > https://fedorahosted.org/freeipa/ticket/3800 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This patch needs a rebase. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Jul 29 09:45:17 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 29 Jul 2013 11:45:17 +0200 Subject: [Freeipa-devel] [PATCH] 429 Make ssh_widget not-editable if attr is readonly In-Reply-To: <51F632A0.4020002@redhat.com> References: <51E7BFAB.2000809@redhat.com> <51F632A0.4020002@redhat.com> Message-ID: <51F639AD.3060007@redhat.com> On 07/29/2013 11:15 AM, Ana Krivokapic wrote: > On 07/18/2013 12:12 PM, Petr Vobornik wrote: >> Make ssh_widget not-editable if attr is readonly >> >> Depends on patch pvoborni-428. >> >> https://fedorahosted.org/freeipa/ticket/3800 >> >> > > This patch needs a rebase. > Rebased version attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0429-1-Make-ssh_widget-not-editable-if-attr-is-readonly.patch Type: text/x-patch Size: 2420 bytes Desc: not available URL: From akrivoka at redhat.com Mon Jul 29 12:21:36 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 29 Jul 2013 14:21:36 +0200 Subject: [Freeipa-devel] [PATCH] 429 Make ssh_widget not-editable if attr is readonly In-Reply-To: <51F639AD.3060007@redhat.com> References: <51E7BFAB.2000809@redhat.com> <51F632A0.4020002@redhat.com> <51F639AD.3060007@redhat.com> Message-ID: <51F65E50.10906@redhat.com> On 07/29/2013 11:45 AM, Petr Vobornik wrote: > dialog.textarea = $('