From dkupka at redhat.com Mon Nov 3 09:28:38 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 03 Nov 2014 10:28:38 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <545207FA.1040407@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> <54511472.5010004@redhat.com> <545207FA.1040407@redhat.com> Message-ID: <54574AC6.9040005@redhat.com> On 10/30/2014 10:42 AM, Martin Basti wrote: > On 29/10/14 17:23, David Kupka wrote: >> On 10/29/2014 02:34 PM, David Kupka wrote: >>> On 10/24/2014 03:05 PM, David Kupka wrote: >>>> On 10/24/2014 01:06 PM, David Kupka wrote: >>>>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>>>> On 24/10/14 09:51, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>>>> NACK >>>>>> >>>>>> 1) >>>>>> Why is there line with 'DS System User?' The comment should depend on >>>>>> service. >>>>>> >>>>>> + args = [ >>>>>> + paths.USERADD, >>>>>> + '-g', group, >>>>>> + '-c', 'DS System User', >>>>>> + '-d', homedir, >>>>>> + '-s', shell, >>>>>> + '-M', '-r', name, >>>>>> + ] >>>>> >>>>> This was part of the original code and I didn't notice it. Nice catch, >>>>> thanks. >>>>> >>>>>> >>>>>> 2) >>>>>> code create_system_user is duplicated between base and redhat tasks >>>>>> with >>>>>> platform dependent changes. >>>>>> IMO it would be better to have one method to create user, with >>>>>> keyword >>>>>> arguments. And then platform dependent method which will call >>>>>> method to >>>>>> create user with appropriate arguments (or with default arguments) >>>>>> >>>>> >>>>> You're right it was ugly. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> I shouldn't break SOLID principles. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Using super is probably better that explicit naming of parent class. >>> Let user (developer) override UID/GID and hope that he knows why ... >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> > > > In your former patch you had pki homedir path VAR_LIB_PKI_DIR : > > + if name == 'pkiuser': > + uid = 17 > + gid = 17 > + homedir = paths.VAR_LIB_PKI_DIR > + shell = paths.NOLOGIN > + comment = 'CA System User' > > in last patch you change it back to: > > homedir=paths.VAR_LIB, > > so what is the correct path? > The setup package (soft static allocation) claims that pkiuser should use '/usr/share/pki' as home directory. Since pkiuser has /sbin/nologin set as a login shell it's unable to login and does't need home directory at all. We could use '--system' option of useradd utility to skip home directory creation or change to proposed value or just leave the old value and all will result in no change in behavior. I'm not sure if the '--system' option is available universally. IIRC it used to be Red Hat-like-systems specific extension. -- David Kupka From mbasti at redhat.com Mon Nov 3 09:32:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 03 Nov 2014 10:32:22 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <54574AC6.9040005@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> <54511472.5010004@redhat.com> <545207FA.1040407@redhat.com> <54574AC6.9040005@redhat.com> Message-ID: <54574BA6.304@redhat.com> On 03/11/14 10:28, David Kupka wrote: > On 10/30/2014 10:42 AM, Martin Basti wrote: >> On 29/10/14 17:23, David Kupka wrote: >>> On 10/29/2014 02:34 PM, David Kupka wrote: >>>> On 10/24/2014 03:05 PM, David Kupka wrote: >>>>> On 10/24/2014 01:06 PM, David Kupka wrote: >>>>>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>>>>> On 24/10/14 09:51, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>>>>> NACK >>>>>>> >>>>>>> 1) >>>>>>> Why is there line with 'DS System User?' The comment should >>>>>>> depend on >>>>>>> service. >>>>>>> >>>>>>> + args = [ >>>>>>> + paths.USERADD, >>>>>>> + '-g', group, >>>>>>> + '-c', 'DS System User', >>>>>>> + '-d', homedir, >>>>>>> + '-s', shell, >>>>>>> + '-M', '-r', name, >>>>>>> + ] >>>>>> >>>>>> This was part of the original code and I didn't notice it. Nice >>>>>> catch, >>>>>> thanks. >>>>>> >>>>>>> >>>>>>> 2) >>>>>>> code create_system_user is duplicated between base and redhat tasks >>>>>>> with >>>>>>> platform dependent changes. >>>>>>> IMO it would be better to have one method to create user, with >>>>>>> keyword >>>>>>> arguments. And then platform dependent method which will call >>>>>>> method to >>>>>>> create user with appropriate arguments (or with default arguments) >>>>>>> >>>>>> >>>>>> You're right it was ugly. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> I shouldn't break SOLID principles. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Using super is probably better that explicit naming of parent class. >>>> Let user (developer) override UID/GID and hope that he knows why ... >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >> >> >> In your former patch you had pki homedir path VAR_LIB_PKI_DIR : >> >> + if name == 'pkiuser': >> + uid = 17 >> + gid = 17 >> + homedir = paths.VAR_LIB_PKI_DIR >> + shell = paths.NOLOGIN >> + comment = 'CA System User' >> >> in last patch you change it back to: >> >> homedir=paths.VAR_LIB, >> >> so what is the correct path? >> > > The setup package (soft static allocation) claims that pkiuser should > use '/usr/share/pki' as home directory. Since pkiuser has > /sbin/nologin set as a login shell it's unable to login and does't > need home directory at all. > We could use '--system' option of useradd utility to skip home > directory creation or change to proposed value or just leave the old > value and all will result in no change in behavior. > I'm not sure if the '--system' option is available universally. IIRC > it used to be Red Hat-like-systems specific extension. > If there is no reason to change homedir, don't do it. I will continue with reviewing then. Martin^2 -- Martin Basti From mbasti at redhat.com Mon Nov 3 09:58:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 03 Nov 2014 10:58:48 +0100 Subject: [Freeipa-devel] Question how memberof plugin works In-Reply-To: <5453C15D.5080208@redhat.com> References: <5453B0BB.9060409@redhat.com> <5453B947.7060901@redhat.com> <5453C15D.5080208@redhat.com> Message-ID: <545751D8.9050806@redhat.com> On 31/10/14 18:05, Ludwig Krispenz wrote: > > On 10/31/2014 05:31 PM, Petr Vobornik wrote: >> On 31.10.2014 16:54, Martin Basti wrote: >>> Hello list, >>> >>> I ran upgrade (related steps listed in order): >>> >>> ipa-ldap-updater --upgrade >>> - applying update files (including 55-pbacmemberof.update) >>> - updating ACI (new permissions created, added to existing privilege) >>> ipa-upgradeconfig >>> - setting up new service (which uses privilege with new permission) >>> >>> At the end I was expecting, the privilege will missing the new >>> permission (memberOf attribute), but I tested it in lab, and membership >>> was OK. >>> >>> How the memberof plugin works? >> >> I know of >> http://directory.fedoraproject.org/docs/389ds/design/memberof-plugin.html >> If there is other source, I would like to see it as well. > I don't know of another doc, but the mechanism of memberof is quit simple: > > In the plugin config you define one or more groupattr and a > memberofattr, eg > |memberofgroupattr: member > memberofgroupattr: uniqueMember > memberofattr: memberOf > > then for any occurrence of the groupattr a value for the memberofattr in the referenced entry will be created, eg: > > ||dn: cn=group,dc=example > member: cn=user,dc=example > > will trigger the addition of the memberofattr to the referenced entry cn=users > > dn: cn=user,dc=example > objectclass: inetUser > memberOf: cn=group,dc=example| > > This happens for any add/delete of a |memberofgroupattr or when the > memberof fixup task is run. > > You have to make sure that the entry which you expect the memberof has > an objectclass allowing the memberof attribute, > > | >> >>> >>> We had similar issue with new DNS installation, where meberOf >>> attributes >>> was missing, if DNS was installed later. But I cant reproduce this >>> behavior during upgrade. (Fix was use 55-pbacmemberof.update as last >>> step of bind service installation) >> >> Was fixed by a fixup task call in: >> >> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=895f350ebf5f002a8ba5aff3d521640b12aa3cde >> >> >>> >>> PS: we had a case where user had broken DNS privileges and >>> 55-pbacmemberof.update helps. But he had multiple errors and it >>> could be >>> cascade effect. >>> > Thank you for explanation Ludwig. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Nov 3 12:17:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:17:12 +0100 Subject: [Freeipa-devel] [PATCH 0249-0250] Propagate DNS updates & changes from LDAP to signed version of the zone In-Reply-To: <5357E758.2050309@redhat.com> References: <5357E758.2050309@redhat.com> Message-ID: <54577248.7030906@redhat.com> On 23.4.2014 18:16, Petr Spacek wrote: > Hello, > > this patch set enables DNS updates to secure zones and also propagates changes > made in LDAP to secure zones. > > NSEC3 doesn't work for some reason so don't waste time messing with NSEC3PARAM > :-) This is delayed push notice: 170d38dd1b27a5f78eb96fe8c80141f6dd56ec97 98d3deac7b75dfe71f6b0e1306c4c52e38e27f3f -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:18:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:18:21 +0100 Subject: [Freeipa-devel] [PATCH 0246-0248] Follow query/transfer/update policies for secure zones In-Reply-To: <536A33A3.4070602@redhat.com> References: <5357E6D5.5060704@redhat.com> <536A33A3.4070602@redhat.com> Message-ID: <5457728D.2080201@redhat.com> On 7.5.2014 15:22, Petr Spacek wrote: > On 23.4.2014 18:14, Petr Spacek wrote: >> This patch set configures secure zones according to policies in LDAP. > > Patch 246 v2 fixes incorrect ATTR_NONNULLS usage which causes segfaults when > compiled with -O0. > > Patch 246 v2 obsoletes patch 253. This is delayed push notice: b002846b94826d89e7577ad2ed3d852e5296e9d5 748602ed229d3925cc838a9baf2c9888aef7fb3c 0cee0a351c03522aea8ae643644776ed34b5c01f -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:20:35 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:20:35 +0100 Subject: [Freeipa-devel] [PATCH 0244-0245] Add basic support for inline-signingSeparate raw and secure zones in Zone Register In-Reply-To: <536A3406.8000407@redhat.com> References: <5351405B.7000003@redhat.com> <536A3406.8000407@redhat.com> Message-ID: <54577313.9070508@redhat.com> On 7.5.2014 15:24, Petr Spacek wrote: > On 18.4.2014 17:10, Petr Spacek wrote: >> Hello, >> >> Add basic support for inline-signing. >> >> Inline-signing is enabled for zones with idnsSecInlineSigning attribute = TRUE. >> >> Limitations: >> - Signing configuration is hardcoded in create_zone() as magic constants >> - idnsSecInlineSigning attribute cannot be changed at run-time >> - DNS updates are not supported >> - Signing keys have to be pre-generated and stored in >> ///keys >> directory before named is started >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > Patch 244 v2 fixes incorrect ATTR_NONNULLS usage which causes segfaults when > compiled with -O0. > > Patch 244 v2 obsoletes patch 253. This is delayed push notice: 63c66344c576a965d5fe65c6275c105a1b86ad93 03ac7114e55435bc07515ee4ed9759481d315619 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:29:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:29:30 +0100 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <538D8A27.2020100@redhat.com> References: <535016B2.2010809@redhat.com> <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> <5368FC93.2090703@redhat.com> <20140506201137.GA1129@mail.corp.redhat.com> <538D8A27.2020100@redhat.com> Message-ID: <5457752A.6080300@redhat.com> On 3.6.2014 10:41, Petr Spacek wrote: > On 6.5.2014 22:11, Lukas Slebodnik wrote: >> On (06/05/14 17:15), Petr Spacek wrote: >>> On 6.5.2014 14:41, Tomas Hozza wrote: >>>> ----- Original Message ----- >>>>> Hello, >>>>> >>>>> This patch set attempts to move ldap_parse_master_zoneentry() a little bit >>>>> closer to sane code. >>>>> >>>>> It is preparation for >>>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >>>>> >>>>> -- >>>>> Petr^2 Spacek >>>>> >>>> >>>> Patches look good. >>>> >>>> ACK. >>>> >>>> ACKing of version 2 of the patch 242 will follow. The patch 243 introduced >>>> new compilation >>>> warning that Peter is aware of. Unfortunately we are unable to find the >>>> root cause of it, >>>> so leaving it as is for now... >>> >>> I managed to find & fix one problem (see new version of the patch >>> 243) but GCC still complains. >>> >>> ../../src/ldap_helper.c: In function 'update_zone': >>> ../../src/ldap_helper.c:2334:34: error: 'data_changed' may be used >>> uninitialized in this function [-Werror=maybe-uninitialized] >>> if (sync_state == sync_finished && data_changed == ISC_TRUE) >>> ^ >>> ../../src/ldap_helper.c:2218:16: note: 'data_changed' was declared here >>> isc_boolean_t data_changed; >>> >>> On my machine with gcc-4.8.2-7.fc20.x86_64 this happens only with -O2. >>> >> The same problem with -01,-Os,-O2 or -O3 >> >> I doubt it is false possibive, because I could reproduce it even with >> gcc-4.9.0-1.fc21.x86_64 >> >>> I'm not able to reproduce this with clang-3.4-6.fc20.x86_64 but it is >>> no so surprising - Clang didn't catch even the first case (fixed by >>> patch version 2). >>> >>> Any hint what is wrong or how to refactor code will be appreciated! ;-) >>> >> I think it can be some kind of optimization in function zone_sync_apex. >> You can try to debug this function with plugin "-O2"-build :-) >> >> The warning can be suppresed with initialising variable before the 1st CHECK. >> It will not work if you try to initialize later. > > Yesterday I have discussed this with jkratoch. We weren't able to find out > case where would initialization in ldap_parse_master_zoneentry() cause any > problem so I have added initialization there. This is delayed push notice: 1aff693f77ef3f2e7f059b52becb5b178eb7b194 04fa577e67543a0b07db329e1ad7fb86c48896ff 2e45aa1d7b83bc33e31b87e919651530944553fb 4fcbaaabf94d9bf2f6942f2ebbc40fed9d2c41a6 f06a0a7375e97d7d275290d8331172fea73be6a4 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:34:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:34:09 +0100 Subject: [Freeipa-devel] [PATCH 0261-0262] Support run-time changes in idnsSecInlineSigning attribute In-Reply-To: <323995070.12040160.1403016092722.JavaMail.zimbra@redhat.com> References: <538F84AF.1060301@redhat.com> <323995070.12040160.1403016092722.JavaMail.zimbra@redhat.com> Message-ID: <54577641.3080307@redhat.com> On 17.6.2014 16:41, Tomas Hozza wrote: > ----- Original Message ----- >> >Hello, >> > >> >This patch set allows you to change DNSSEC zone configuration at run-time. >> > >> >-- >> >Petr^2 Spacek >> > > Looks good. > > ACK. This is delayed push notice: 5cede8e6f666aeec48aa47ba18a143f2037216f8 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:34:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:34:58 +0100 Subject: [Freeipa-devel] [PATCH 0263-0265] Support root master zone in LDAP & Follow BIND semantics for forwarders In-Reply-To: <777925185.12040232.1403016105913.JavaMail.zimbra@redhat.com> References: <5391FE70.6030405@redhat.com> <777925185.12040232.1403016105913.JavaMail.zimbra@redhat.com> Message-ID: <54577672.9010806@redhat.com> On 17.6.2014 16:41, Tomas Hozza wrote: > ----- Original Message ----- >> >Hello, >> > >> >This patch set contains necessary changes for supporting root master zone in >> >LDAP. I had to remove one hack so now we follow BIND semantics for >> >forwarders. >> > >> >Please see commit messages. >> > >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/122 >> > >> >-- >> >Petr^2 Spacek >> > > Looks good. > > ACK. This is delayed push notice: 1c9b7ec800b0cbdba6032ec4fd1d41cff6ce5e6d bff6d68ac200ea1ab543b090ab2763e2437a48ce 6c212c81f1297bef844cf4c6d6f36fc8231e4a45 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:36:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:36:00 +0100 Subject: [Freeipa-devel] [PATCH 0273-0274] Bump NVR to 5.0Update README and NEWS: DNSSEC and changes in forwarding semantics In-Reply-To: <53A9940F.2000005@redhat.com> References: <53A9940F.2000005@redhat.com> Message-ID: <545776B0.7010506@redhat.com> On 24.6.2014 17:06, Petr Spacek wrote: > Hello, > > it's release time! > > Bump NVR to 5.0 and update README and NEWS to describe DNSSEC support and > changes in forwarding semantics. This is delayed push notice: d093af67072e44ce65be04c7267c4dbaa6cadf08 c12f72dd3edf34c943a108f90c9fd0dac82a716b -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:36:44 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:36:44 +0100 Subject: [Freeipa-devel] [PATCH 0269] Silence GCC warning about uninitialized ldap_writeback In-Reply-To: <20140624155344.GB14562@mail.corp.redhat.com> References: <53A98F36.3010600@redhat.com> <20140624155344.GB14562@mail.corp.redhat.com> Message-ID: <545776DC.3010800@redhat.com> On 24.6.2014 17:53, Lukas Slebodnik wrote: > On (24/06/14 16:46), Petr Spacek wrote: >> >Hello, >> > >> >Silence GCC warning about uninitialized ldap_writeback. >> > >> >It seems like false positive, I can't imagine how ldap_writeback could be >> >used without prior initialization. >> > >> >-- >> >Petr^2 Spacek >>From eb253b58d6214b3f94d22c3ec2dcf62d0103ad46 Mon Sep 17 00:00:00 2001 >> >From: Petr Spacek >> >Date: Mon, 23 Jun 2014 17:02:08 +0200 >> >Subject: [PATCH] Silence GCC warning about uninitialized ldap_writeback. >> > >> >Signed-off-by: Petr Spacek >> >--- >> >src/ldap_helper.c | 4 ++++ >> >1 file changed, 4 insertions(+) >> > >> >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> >index 43bacf779f44a709b0cefd638826633b9d2d8891..a7a782fdfc5ae4d28b50155c9614d66a427dc3e0 100644 >> >--- a/src/ldap_helper.c >> >+++ b/src/ldap_helper.c >> >@@ -2130,7 +2130,11 @@ zone_sync_apex(const ldap_instance_t * const inst, >> > isc_boolean_t soa_tuple_alloc = ISC_FALSE; >> > isc_uint32_t curr_serial; >> > >> >+ REQUIRE(ldap_writeback != NULL); >> >+ >> > INIT_LIST(rdatalist); >> >+ *ldap_writeback = ISC_FALSE; /* GCC */ >> >+ >> > CHECK(setting_get_str("fake_mname", inst->local_settings, >> > &fake_mname)); >> > CHECK(ldap_parse_rrentry(inst->mctx, entry, &name, fake_mname, >> >-- >> >1.9.3 >> > > ACK This is delayed push notice: eb253b58d6214b3f94d22c3ec2dcf62d0103ad46 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:37:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:37:43 +0100 Subject: [Freeipa-devel] [PATCH 0270-0271] Add TLSA and DLV RR types to LDAP schema In-Reply-To: <1403699341.2323.2.camel@unused-4-145.brq.redhat.com> References: <53A99375.7030602@redhat.com> <1403699341.2323.2.camel@unused-4-145.brq.redhat.com> Message-ID: <54577717.4040808@redhat.com> On 25.6.2014 14:29, Martin Basti wrote: > On Tue, 2014-06-24 at 17:04 +0200, Petr Spacek wrote: >> >Hello, >> > >> >Add TLSA and DLV RR types to LDAP schema. >> > >> >Those RR types will be handy for DNSSEC users. >> > > Patch 270 LGTM > Patch 271 NACK: > You have to add the 'TLSARecord' attribute to idnsRecord objectclass This is delayed push notice: eae0035df2a510512844f602acc70c096fcde2b4 174190a582825478a555c722e9e0314770b895a5 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:38:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:38:07 +0100 Subject: [Freeipa-devel] [PATCH 0274] Add TLSARecord to idnsRecord object class In-Reply-To: <53AD1E74.5020606@redhat.com> References: <53AD1E74.5020606@redhat.com> Message-ID: <5457772F.2090508@redhat.com> On 27.6.2014 09:34, Petr Spacek wrote: > Hello, > > Add TLSARecord to idnsRecord object class. This is delayed push notice: 2d358ccbc323ea6d4339f22b16d419195054e017 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:45:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:45:05 +0100 Subject: [Freeipa-devel] [PATCH 0251-0256] Add support for NSEC3 In-Reply-To: <537C9462.4070400@redhat.com> References: <53601AD2.9070806@redhat.com> <536A34B7.5000400@redhat.com> <537C72FB.5030300@redhat.com> <537C9462.4070400@redhat.com> Message-ID: <545778D1.2030905@redhat.com> On 21.5.2014 13:56, Tomas Hozza wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/21/2014 11:33 AM, Petr Spacek wrote: >> >On 7.5.2014 15:27, Petr Spacek wrote: >>> >>On 29.4.2014 23:34, Petr Spacek wrote: >>>> >>>This patch set adds support for NSEC3. See commit messages for details. >>> >> >>> >>Patch 253 was obsoleted by patches 244v2 and 246v2. >>> >> >>> >>You can download latest & greatest version from dnssec branch on github: >>> >> >>> >>https://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec >> > >> >Patch 256v2 removes dead code from zone_master_reconfigure_nsec3param() >> >function. >> > >> >You can download latest & greatest version from dnssec branch on github. >> > >> >This doesn't solve a race condition somewhere in start-up sequence, I'm >> >looking into it. >> > > Hi. > > I tested and reviewed patches 244-256 (all latest versions) and tested > thehttps://github.com/spacekpe/bind-dyndb-ldap/tree/dnssec HEAD. > > Everything works as expected in constraints described in commit messages. > > There is still a race condition with signing that Petr is aware of and > is working on it. (The zone is sometimes not signed if started using > systemd). > > So I'm ACKing the patch-set 244-256 This is delayed push notice: c125ae548b77fffc5af9fc9c5e0f5b3c0b83bfbb 3b120f9a1536b56616f0c2da946039bcdb548025 f72976d1f73470fbbd00791d2cb8f823d9053f61 9ae956c448b0b60123e2d26eb60b37eab08b4393 b26e562c7dc19cca9cfcd51907ecbdeb0d8856f6 Patch 253 was obsoleted by patches 244v2 and 246v2. -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:46:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:46:14 +0100 Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading In-Reply-To: <1509097894.11927028.1402990386038.JavaMail.zimbra@redhat.com> References: <538498FA.7070609@redhat.com> <53849A57.4040106@redhat.com> <5385C7C8.3060102@redhat.com> <53864D88.6030400@redhat.com> <1509097894.11927028.1402990386038.JavaMail.zimbra@redhat.com> Message-ID: <54577916.8030308@redhat.com> On 17.6.2014 09:33, Tomas Hozza wrote: > ----- Original Message ----- >> >On 28.5.2014 13:26, Tomas Hozza wrote: >>> > >On 05/27/2014 03:59 PM, Petr Spacek wrote: >>>> > >>On 27.5.2014 15:54, Petr Spacek wrote: >>>>> > >>>Fix race condition during zone loading. >>>>> > >>> >>>>> > >>>DNS zone has to be added to DNS view before dns_zone_load() is called. >>>>> > >>>It is necessary to prevent dns_zone_load() from racing with >>>>> > >>>dns_zone_setview(). >>>>> > >>> >>>>> > >>>This race condition sometimes prevents zone from being signed. >>>>> > >>>Now the unsigned zone is visible until signing process is complete. This >>>>> > >>>mimics BIND behavior for in-line signed zones. >>>>> > >>> >>>>> > >>>https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >>>> > >> >>>> > >>And here is the patch... >>>> > >> >>> > > >>> > >Hi. >>> > > >>> > >When I use bind-dyndb-ldap plugin with this patch, named >>> > >does not start due to: >>> > > >>> > >rbt.c:1379: REQUIRE(name->buffer != ((void *)0)) failed, back trace >>> > > >>> > >(gdb) bt >>> > >#0 0x00007f3963924c39 in raise () from /lib64/libc.so.6 >>> > >#1 0x00007f3963926348 in abort () from /lib64/libc.so.6 >>> > >#2 0x00007f3966979aee in assertion_failed () >>> > >#3 0x00007f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95 >>> > >#4 0x00007f39661ca9da in dns_rbt_fullnamefromnode () from >>> > >/lib64/libdns.so.100 >>> > >#5 0x00007f396011824b in rbt_iter_getnodename (iter=, >>> > >nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:46 >>> > >#6 0x00007f396011839b in rbt_iter_next >>> > >(iterp=iterp at entry=0x7f39625f8b90, >>> > >nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:144 >>> > >#7 0x00007f3960112d32 in activate_zones >>> > >(task=task at entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164 >>> > >#8 0x00007f396011a20d in barrier_decrement (task=0x7f39668f5790, >>> > >event=0x7f396005b010) at syncrepl.c:138 >>> > >#9 0x00007f3964b8b836 in run () from /lib64/libisc.so.95 >>> > >#10 0x00007f396473ff33 in start_thread () from /lib64/libpthread.so.0 >>> > >#11 0x00007f39639e3ded in clone () from /lib64/libc.so.6 >>> > > >>> > > >>> > >It looks like you should use INIT_BUFFERED_NAME(name); used in the >>> > >original code instead of dns_name_init(&name, NULL). The macro >>> > >initializes the buffer in "name", which is missing in the new code. >> > >> >Oh yes, it didn't happened on my machine because I have had only single zone >> >defined in LDAP at the time of testing. Thank you for catching this! >> > >> >I'm attaching fixed patch. dns_name_reset() is good enough in this case. >> > >> >-- >> >Petr^2 Spacek >> > > Now it works. > > ACK This is delayed push notice: 129e54db4fb9ccbb85f2445db81d9f0c89722887 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:46:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:46:50 +0100 Subject: [Freeipa-devel] [PATCH 0266] (aka 257.5) Fix zone reloading for in-line signed zones In-Reply-To: <121537395.11936747.1402994121379.JavaMail.zimbra@redhat.com> References: <539FF96B.1020504@redhat.com> <121537395.11936747.1402994121379.JavaMail.zimbra@redhat.com> Message-ID: <5457793A.8000301@redhat.com> On 17.6.2014 10:35, Tomas Hozza wrote: > ----- Original Message ----- >> >Hello, >> > >> >I forgot to send one patch between no. 257 and 258, so here it is:-) >> > >> >Fix zone reloading for in-line signed zones. >> > >> >A invalid secure zone (e.g. without NS records) is now automatically >> >reloaded when data inside the zone are changed. >> > >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >> > >> >-- >> >Petr^2 Spacek >> > > ACK. This is delayed push notice: f0bedf45b7ed56717d5dc5566cbbf34938eba0ee -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:47:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:47:37 +0100 Subject: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for secure zones In-Reply-To: <1073701430.11937064.1402994169486.JavaMail.zimbra@redhat.com> References: <538F3C85.20507@redhat.com> <539FF3FE.3030404@redhat.com> <1073701430.11937064.1402994169486.JavaMail.zimbra@redhat.com> Message-ID: <54577969.8030405@redhat.com> On 17.6.2014 10:36, Tomas Hozza wrote: > ----- Original Message ----- >> >Subject: Re: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for >> >secure zones >> >Date: Wed, 04 Jun 2014 17:34:29 +0200 >> >From: Petr Spacek >> >Organization: Red Hat >> >To:freeipa-devel at redhat.com >> > >> >On 3.6.2014 10:53, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > >Fix run-time zone addition for secure zones. >> > >> >Here comes fix for the fix ... >> > >> >We really need a test-suite for bind-dyndb-ldap. >> > >>> > >https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >> > >> >-- >> >Petr^2 Spacek >> > >> > >> > >> > > ACK. This is delayed push notice: 7589888b70f23c10b0a215cf73d9444677df04d6 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:48:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:48:11 +0100 Subject: [Freeipa-devel] [PATCH 0259] Fix run-time zone addition for invalid secure zones In-Reply-To: <1503286783.12039965.1403016057093.JavaMail.zimbra@redhat.com> References: <538DAD5B.7090907@redhat.com> <1503286783.12039965.1403016057093.JavaMail.zimbra@redhat.com> Message-ID: <5457798B.4030707@redhat.com> On 17.6.2014 16:40, Tomas Hozza wrote: > ----- Original Message ----- >> >Hello, >> > >> >Fix run-time zone addition for invalid secure zones. >> > >> >It is important*not* to delete invalid zones to prevent >> >ldap_parse_master_zoneentry() from entering infinite cycle. >> > >> >Zone addition in ldap_parse_master_zoneentry() enforces serial >> >write-back to LDAP. This write generates LDAP modify event which >> >again triggers ldap_parse_master_zoneentry() and so on. >> > >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >> > >> >-- >> >Petr^2 Spacek >> > > Looks good. > > ACK. This is delayed push notice: 8fe1300f4e512a62cf9e5c3038538d52c176fa29 -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:48:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:48:54 +0100 Subject: [Freeipa-devel] [PATCH 0260] Add wrappers for isc_task_*exclusive() In-Reply-To: <1745344319.12040088.1403016078674.JavaMail.zimbra@redhat.com> References: <538F39D6.3080308@redhat.com> <1745344319.12040088.1403016078674.JavaMail.zimbra@redhat.com> Message-ID: <545779B6.8040606@redhat.com> On 17.6.2014 16:41, Tomas Hozza wrote: > ----- Original Message ----- >> >Hello, >> > >> >Add wrappers for isc_task_*exclusive(). >> > >> >This patch replaces scattered isc_task_* calls and associated locking to one >> >place. It helps with debugging sometimes. >> > >> >-- >> >Petr^2 Spacek >> > > Looks good. > > ACK. This is delayed push notice: d97e3905fd73839e8abcde8e7ddfb99eefeb22fe -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 12:54:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:54:22 +0100 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: References: <542AE179.6050303@redhat.com> Message-ID: <54577AFE.1060201@redhat.com> On 4.10.2014 01:58, Gabe Alford wrote: > Thanks Petr. Updated patch attached. Petr^3, is it okay now? Petr^2 Spacek > > On Tue, Sep 30, 2014 at 10:59 AM, Petr Viktorin wrote: > >> On 09/30/2014 05:13 AM, Gabe Alford wrote: >> >>> Updated patch to fix merge conflicts from recent changes. >>> >>> On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford >> > wrote: >>> >>> Hello, >>> >>> Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know >>> if I missed any. >>> >>> Thanks, >>> >>> Gabe >>> >> >> Thanks for the patch, and sorry for the delay! >> >> ipaserver/tools/ipa-upgradeconfig: >> The `filename` and `ca_file` aren't module-level constants; I think in >> this case they improve readability. >> The ticket calls for removing module-level lines like: >> NSSWITCH_CONF = paths.NSSWITCH_CONF >> which are just silly, but assigning a name locally to a global constant is >> a valid thing to do -- even if the local name just says "the file we're >> working on now". >> >> >> - ca_file = paths.ALIAS_CACERT_ASC >>> - if os.path.exists(ca_file): >>> + if os.path.exists(paths.SYSCONFIG_HTTPD): >>> >> >> Whoops! >> >> >> install/wsgi/plugins.py: >> >> -PLUGINS_DIR = paths.IPA_JS_PLUGINS_DIR >>> - >>> >> [...] >> >>> - if not os.path.isdir(PLUGINS_DIR): >>> + if not os.path.isdir(paths.IPA_CA_CSR): >>> >> >> Whoops too! >> >> >> ipaplatform/fedora/tasks.py: >> ipa-client/ipa-install/ipa-client-install: >> ipaserver/install/dsinstance.py: >> ipaserver/install/httpinstance.py: >> Again, I'd not change the target_fname, filepath. >> >> >> ipapython/sysrestore.py: >> Again, `SYSRESTORE_PATH` describes better what we do with `paths.TMP`, so >> I'd prefer keeping it. >> >> >> ipaserver/install/adtrustinstance.py: >> I don't think we want to convert the self.* to constants. >> >> >> ipaserver/install/certs.py: >> I'd leave NSS_DIR as it is, rather than lose the comment. >> >> >> ipapython/ipautil.py: >> ipaserver/install/ldapupdate.py: >> ipalib/session.py: >> ipaserver/install/bindinstance.py: >> SHARE_DIR, UPDATES_DIR, and krbccache_dir, NAMED_CONF (respectively) need >> to stay, unless you also replace them in everything that uses them. >> >> Be sure to run make-lint after doing these changes. >> >> >> I've rebased, and I made some of the changes as I went along the review. >> You can base another revision on the attached patch. From pspacek at redhat.com Mon Nov 3 12:59:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 13:59:52 +0100 Subject: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.' In-Reply-To: <5417F6A2.9060006@redhat.com> References: <53FB3191.7090102@redhat.com> <5405E653.2050604@redhat.com> <5406ED20.7040703@redhat.com> <5406F162.4060409@redhat.com> <5412F2CD.4060202@redhat.com> <54170169.7080607@redhat.com> <541702C5.5060203@redhat.com> <54173067.2080106@redhat.com> <5417E775.4050905@redhat.com> <5417ED7D.8000701@redhat.com> <5417F023.90109@redhat.com> <5417F4F5.1050907@redhat.com> <5417F51A.2030005@redhat.com> <5417F6A2.9060006@redhat.com> Message-ID: <54577C48.8060900@redhat.com> On 16.9.2014 10:36, Martin Kosek wrote: > On 09/16/2014 10:30 AM, Martin Basti wrote: >> On 16/09/14 10:29, Petr Spacek wrote: >>> On 16.9.2014 10:09, Martin Kosek wrote: >>>> On 09/16/2014 09:57 AM, Martin Basti wrote: >>>>> On 16/09/14 09:32, Martin Basti wrote: >>>>>> On 15/09/14 20:31, Martin Kosek wrote: >>>>>>> On 09/15/2014 05:16 PM, Martin Basti wrote: >>>>>>>> On 15/09/14 17:10, Petr Spacek wrote: >>>>>>>>> On 12.9.2014 15:19, Martin Basti wrote: >>>>>>>>>> On 03/09/14 12:45, Martin Basti wrote: >>>>>>>>>>> On 03/09/14 12:27, Martin Kosek wrote: >>>>>>>>>>>> On 09/02/2014 05:46 PM, Petr Spacek wrote: >>>>>>>>>>>>> On 25.8.2014 14:52, Martin Basti wrote: >>>>>>>>>>>>>> Patches attached. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4149 >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a bug in bind-dyndb-ldap (or worse in dirsrv), which >>>>>>>>>>>>>> cause the >>>>>>>>>>>>>> named >>>>>>>>>>>>>> service is stopped after deleting zone. >>>>>>>>>>>>>> Bug ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/138 >>>>>>>>>>>>> Functional ACK, it works for me. It can be pushed if Python gurus are >>>>>>>>>>>>> okay >>>>>>>>>>>>> with >>>>>>>>>>>>> the code. >>>>>>>>>>>> Is it safe to commit the change given that bind-dyndb-ldap still crash >>>>>>>>>>>> when >>>>>>>>>>>> "." >>>>>>>>>>>> is removed? Wouldn't it break our CI tests? >>>>>>>>>>>> >>>>>>>>>>>> Maybe we should wait until fixed bind-dydnb-ldap is released. >>>>>>>>>>>> Hopefully it >>>>>>>>>>>> would be soon. >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>>>> It will broke tests, don't push it until bind-dyndb-ldap is fixed. >>>>>>>>>>> Currently I'm testing bind-dyndb-ldap related patch. >>>>>>>>>>> >>>>>>>>>> Added patches 120 and 121, which are required by DNS to work correctly. >>>>>>>>>> Patches 120 and 121 add all DNS replicas to zone apex as NS, >>>>>>>>>> --name-server >>>>>>>>>> option doesn't add NS record, only changes the SOA MNAME attribute >>>>>>>>>> >>>>>>>>>> Original and new patches attached. >>>>>>>>> >>>>>>>>> NACK, unfortunately it doesn't work for me: >>>>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>>>>> ipa: WARNING: '--name-server' is used only for setting up the SOA MNAME >>>>>>>>> record. >>>>>>>>> To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ >>>>>>>>> --ns-rec=nameserver'. >>>>>>>>> Zone name: tri.test. >>>>>>>>> Active zone: TRUE >>>>>>>>> Authoritative nameserver: ns.test. >>>>>>>>> Administrator e-mail address: hostmaster.tri.test. >>>>>>>>> SOA serial: 1410793406 >>>>>>>>> SOA refresh: 3600 >>>>>>>>> SOA retry: 900 >>>>>>>>> SOA expire: 1209600 >>>>>>>>> SOA minimum: 3600 >>>>>>>>> BIND update policy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>>>> Dynamic update: FALSE >>>>>>>>> Allow query: any; >>>>>>>>> Allow transfer: none; >>>>>>>>> >>>>>>>>> [root at vm-035 rpms]# ipa dnszone-show tri.test. --all --raw >>>>>>>>> dn: idnsname=tri.test.,cn=dns,dc=ipa,dc=example >>>>>>>>> idnsname: tri.test. >>>>>>>>> idnszoneactive: TRUE >>>>>>>>> idnssoamname: ns.test. >>>>>>>>> idnssoarname: hostmaster.tri.test. >>>>>>>>> idnssoaserial: 1410793408 >>>>>>>>> idnssoarefresh: 3600 >>>>>>>>> idnssoaretry: 900 >>>>>>>>> idnssoaexpire: 1209600 >>>>>>>>> idnssoaminimum: 3600 >>>>>>>>> idnsallowquery: any; >>>>>>>>> idnsallowtransfer: none; >>>>>>>>> idnsAllowDynUpdate: FALSE >>>>>>>>> idnsUpdatePolicy: grant IPA.EXAMPLE krb5-self * A; grant IPA.EXAMPLE >>>>>>>>> krb5-self * AAAA; grant IPA.EXAMPLE krb5-self * SSHFP; >>>>>>>>> nsrecord: vm-035.idm.lab.eng.brq.redhat.com. >>>>>>>>> objectClass: idnszone >>>>>>>>> objectClass: top >>>>>>>>> objectClass: idnsrecord >>>>>>>>> >>>>>>>>> [root at vm-035 rpms]# ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>>>>> ipa: ERROR: tri.test.: DNS resource record not found >>>>>>>>> >>>>>>>> NACKing NACK >>>>>>>> ipa dnsrecord-mod @ tri.test. --ns-rec=$(hostname). >>>>>>>> you switched order zone and record, it should be >>>>>>>> ipa dnsrecord-mod tri.test. @ --ns-rec=$(hostname). >>>>>>>> >>>>>>> >>>>>>> BTW, since we are so nicely breaking the dnszone-add interface, can we also >>>>>>> get rid of always asking for "Administrator e-mail address"? >>>>>>> >>>>>>>>> # ipa dnszone-add tri.test. --name-server=ns.test. >>>>>>>>> Administrator e-mail address [hostmaster.tri.test.]: >>>>>>> ... >>>>>>> >>>>>>> Is there any risk in filling that with default as any other attribute? IMO >>>>>>> it would simplify adding zones for one more redundant step. CCing Rob in >>>>>>> case he knows some historical reasons why this is requested every time. >>>>>>> >>>>>>> Martin >>>>>> There is no risk, because ipa-replica-prepare do that with default values >>>> >>>> Then let us do this, as we are already simplifying the dnszone-add command. >>>> >>>>> However, this will not work with root zone ".", and I'm not sure how often an >>>>> admin email is used. I think whois is better utility to get contact email. >>>>> >>>>> Also RIPE-203 [1] recommends to use 'hostmaster' alias. >>>>> >>>>> [1] http://www.ripe.net/ripe/docs/ripe-203 >>> >>> This will likely generate tons of invalid e-mail addresses which is somehow >>> unfortunate. >>> >>> Please keep in mind that: >>> 1) E-mail hostmaster at ipa.domain.example. will be useful only if >>> ipa.domain.example. has MX record or at least A/AAAA record (which is usually >>> not the case for domains). >>> >>> 2) WHOIS is not useful for internal domains which is the main deployment >>> scenario for IPA, right? >>> >>>> DNS zone "." is quite an exception, you are not adding that zone every day. So >>>> I would not keep asking for admin mail just for this one. You can add a >>>> interactive prompt callback to ask in this case and otherwise just use the >>>> default - up to you. >>>> >>>> As for the mail alias, this can be an RFE. >>> >>> It would be nice to have some IPA-global default like 'DNS administrator >>> e-mail address' and to use this value for all DNS zones by default. >>> >> +1 > > Please file an RFE for this part (requires schema update, doc update, ...). For https://fedorahosted.org/freeipa/ticket/4542 > now I would stick just with using the defaults without asking (like in other > commands). I think it involves just setting autofill to True. -- Petr^2 Spacek From pspacek at redhat.com Mon Nov 3 13:04:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 14:04:00 +0100 Subject: [Freeipa-devel] [PATCH] Coverity fixes for slapi-nis In-Reply-To: <5236BA32.5030302@redhat.com> References: <20130902135813.GF21212@redhat.com> <5236BA32.5030302@redhat.com> Message-ID: <54577D40.9080804@redhat.com> On 16.9.2013 09:58, Petr Spacek wrote: > On 2.9.2013 15:58, Alexander Bokovoy wrote: >> Hi Nalin, >> >> attached please find two patches that fix minor Coverity issues. >> >> The first patch is for issue 11937 which is a false positive but caught >> up wrong use of the helper method -- the method map_data_set_entry() >> passes key and value length arguments through to map_data_save_list() >> which expects them to be arrays but we pass pointer to the variable. >> Luckily, in our case map_data_save_list() never goes beyond element 0 of >> the array so the fix is mostly cosmetic. >> >> The second fix is in PAM wrapper in the tests and minor too -- we would >> leak a memory if PAM wrapper wasn't called under wrapping condition. >> >> The same patches are in my Fedora people slapi-nis tree, branch >> 'coverity': >> http://fedorapeople.org/cgit/abbra/public_git/slapi-nis.git/log/?h=coverity > > ACK This is late push notice: 41b540bc76068355e076ba95e60780bd95905d77 929a68b13defe46c0f8913440ba28f0476dcbdab -- Petr^2 Spacek From mbasti at redhat.com Mon Nov 3 13:04:45 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 03 Nov 2014 14:04:45 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <54574AC6.9040005@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> <54511472.5010004@redhat.com> <545207FA.1040407@redhat.com> <54574AC6.9040005@redhat.com> Message-ID: <54577D6D.3020806@redhat.com> On 03/11/14 10:28, David Kupka wrote: > On 10/30/2014 10:42 AM, Martin Basti wrote: >> On 29/10/14 17:23, David Kupka wrote: >>> On 10/29/2014 02:34 PM, David Kupka wrote: >>>> On 10/24/2014 03:05 PM, David Kupka wrote: >>>>> On 10/24/2014 01:06 PM, David Kupka wrote: >>>>>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>>>>> On 24/10/14 09:51, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>>>>> NACK >>>>>>> >>>>>>> 1) >>>>>>> Why is there line with 'DS System User?' The comment should >>>>>>> depend on >>>>>>> service. >>>>>>> >>>>>>> + args = [ >>>>>>> + paths.USERADD, >>>>>>> + '-g', group, >>>>>>> + '-c', 'DS System User', >>>>>>> + '-d', homedir, >>>>>>> + '-s', shell, >>>>>>> + '-M', '-r', name, >>>>>>> + ] >>>>>> >>>>>> This was part of the original code and I didn't notice it. Nice >>>>>> catch, >>>>>> thanks. >>>>>> >>>>>>> >>>>>>> 2) >>>>>>> code create_system_user is duplicated between base and redhat tasks >>>>>>> with >>>>>>> platform dependent changes. >>>>>>> IMO it would be better to have one method to create user, with >>>>>>> keyword >>>>>>> arguments. And then platform dependent method which will call >>>>>>> method to >>>>>>> create user with appropriate arguments (or with default arguments) >>>>>>> >>>>>> >>>>>> You're right it was ugly. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> I shouldn't break SOLID principles. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Using super is probably better that explicit naming of parent class. >>>> Let user (developer) override UID/GID and hope that he knows why ... >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >> >> >> In your former patch you had pki homedir path VAR_LIB_PKI_DIR : >> >> + if name == 'pkiuser': >> + uid = 17 >> + gid = 17 >> + homedir = paths.VAR_LIB_PKI_DIR >> + shell = paths.NOLOGIN >> + comment = 'CA System User' >> >> in last patch you change it back to: >> >> homedir=paths.VAR_LIB, >> >> so what is the correct path? >> > > The setup package (soft static allocation) claims that pkiuser should > use '/usr/share/pki' as home directory. Since pkiuser has > /sbin/nologin set as a login shell it's unable to login and does't > need home directory at all. > We could use '--system' option of useradd utility to skip home > directory creation or change to proposed value or just leave the old > value and all will result in no change in behavior. > I'm not sure if the '--system' option is available universally. IIRC > it used to be Red Hat-like-systems specific extension. > ACK -- Martin Basti From pspacek at redhat.com Mon Nov 3 13:08:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Nov 2014 14:08:43 +0100 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: <5434EBEE.2000504@redhat.com> References: <54342251.6070304@redhat.com> <5434EBEE.2000504@redhat.com> Message-ID: <54577E5B.9070803@redhat.com> On 8.10.2014 09:46, Petr Spacek wrote: > Hello, > > this is going to be a little bit more interesting. > > RHEL/CentOS version of FreeIPA depends on python-dns >= 1.11.1-2 but Fedora > version should depend on >= 1.12.0. > > RHEL contains Git snapshot which is newer than 1.11.1 but is still not > complete 1.12.0. Fedora contains 'proper' 1.11.1 version which is > unfortunately too old. > > Fedora bug for rebase to 1.12.0: > https://bugzilla.redhat.com/show_bug.cgi?id=1150396 For now I have copied the necessary method to DNSSEC daemon directly so FreeIPA release is not blocked by necessity of having latest python-dns in Fedora. This thread should be resurrected when Fedora has new-enough python-dns so we can drop our copy of the code from FreeIPA source tree. Petr^2 Spacek > On 7.10.2014 19:34, Gabe Alford wrote: >> Done. Update patch to use python-dns >= 1.11.1 >> >> On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti wrote: >> >>> On 07/10/14 15:58, Gabe Alford wrote: >>> >>> Forgot to add patch. >>> >>> On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford wrote: >>> >>>> Hello, >>>> >>>> Fix for https://fedorahosted.org/freeipa/ticket/4613 >>>> >>>> Thanks, >>>> >>>> Gabe >>> >>> >>> Thank you! >>> >>> I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes which we >>> may use in tests. >>> >>> Could you send updated patch please? -- Petr^2 Spacek From dkupka at redhat.com Mon Nov 3 15:01:19 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 03 Nov 2014 16:01:19 +0100 Subject: [Freeipa-devel] [PATCH] 335 Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage In-Reply-To: <543E8827.5070402@redhat.com> References: <543E8827.5070402@redhat.com> Message-ID: <545798BF.803@redhat.com> On 10/15/2014 04:43 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > It depends on my patches 333 and 334, which are also attached. > > (The original patch was posted at > .) > > > How to test: > > 1. install server > > 2. kinit as admin > > 3. run "ipa-cacert-manage renew --external-ca", it will produce a CSR > > 4. sign the CSR with some external CA to get new IPA CA certificate > > 5. run "while true; do ldapdelete -H ldap://$HOSTNAME -Y GSSAPI > 'cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,'; > done" in background > > 6. run "ipa-cacert-manage renew --external-cert-file= CA certificate> --external-cert-file= chain>" > > 7. stop the loop from step 5 > > 8. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert > cert-pki-ca'", the request should be in MONITORING state, there should > be no ca-error > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. Please push only the patch freeipa-jcholast-335. Patches freeipa-jcholast-333 and freeipa-jcholast-334 was pushed earlier. -- David Kupka From pviktori at redhat.com Mon Nov 3 15:07:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Nov 2014 16:07:20 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects Message-ID: <54579A28.80607@redhat.com> Hello! There's been some interest in releasing pieces of FreeIPA's testing infrastructure so it can be reused in other projects. I will soon take the pytest-beakerlib plugin (currently in my patch 0672), and making a stand-alone project out of it. Later I'll extract the common pieces of the integration testign framework, and release that independently. Do we want projects projects like these to be hosted on Fedorahosted? That would be the 100% open-source solution. Or do we want to put it under a freeipa organization on Github, since we're more likely to get external contributors there? Or both? (Would we want to "officially" mirror the project to Github from FH?) I'm asking about the projects' "home", the Git repo can of course be mirrored anywhere. -- Petr? From rcritten at redhat.com Mon Nov 3 15:47:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Nov 2014 10:47:27 -0500 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <54579A28.80607@redhat.com> References: <54579A28.80607@redhat.com> Message-ID: <5457A38F.2030201@redhat.com> Petr Viktorin wrote: > Hello! > > There's been some interest in releasing pieces of FreeIPA's testing > infrastructure so it can be reused in other projects. > I will soon take the pytest-beakerlib plugin (currently in my patch > 0672), and making a stand-alone project out of it. Later I'll extract > the common pieces of the integration testign framework, and release that > independently. > > > Do we want projects projects like these to be hosted on Fedorahosted? > That would be the 100% open-source solution. > > Or do we want to put it under a freeipa organization on Github, since > we're more likely to get external contributors there? Why do you think it would get more contributors from github? Because yet another account isn't required, or the contributor process is perhaps better understood (via pull requests)? > Or both? (Would we want to "officially" mirror the project to Github > from FH?) I'd be in favor of fedorahosted because you get a tracker and wiki as well, and having the repo there would round things out. rob From edewata at redhat.com Tue Nov 4 06:27:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 00:27:28 -0600 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <54501A0F.30805@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> <54501A0F.30805@redhat.com> Message-ID: <545871D0.5070608@redhat.com> On 10/28/2014 5:34 PM, Endi Sukma Dewata wrote: >>>> The NSSConnection class has to be modified not to shutdown existing >>>> database because some of the vault clients (e.g. vault-archive and >>>> vault-retrieve) also use a database to encrypt/decrypt the secret. >>> >>> The problem is described in more detail in this ticket: >>> https://fedorahosted.org/freeipa/ticket/4638 >>> >>> The changes to the NSSConnection in the first patch caused the >>> installation to fail. Attached is a new patch that uses the solution >>> proposed by jdennis. >> >> New patch attached. It's now using the correct OID's for the schema. It >> also has been rebased on top of #352-1 and #354. > > New patch attached to fix the ticket URL. It depends on #352-2 and #354-1. New patch attached to fix vault/container ID problems and for some cleanups. -- Endi S. Dewata -------------- next part -------------- >From 71c91726e1c442baa243210bbbb00556a3c9ce8e Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive data, and retrieve data using a standard vault. It also includes the initial LDAP schema. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. The DN class has been enhanched to accept a list of RDNs. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 167 +++++++ VERSION | 4 +- install/share/60basev4.ldif | 3 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + install/updates/40-vault.update | 27 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 865 +++++++++++++++++++++++++++++++++++++ ipapython/dn.py | 2 + ipaserver/install/dsinstance.py | 1 + 13 files changed, 1081 insertions(+), 2 deletions(-) create mode 100644 install/share/60basev4.ldif create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py diff --git a/API.txt b/API.txt index 0000491d7a76fd1d2d50208d314d1600839ce295..b73da0af55a3c514de73ae4e1b2a4d13c01c903d 100644 --- a/API.txt +++ b/API.txt @@ -4475,6 +4475,173 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('data?', cli_name='data') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('text?', cli_name='text') +option: Str('vault_id', attribute=False, cli_name='vault_id', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,11,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('data?', cli_name='data') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('text?', cli_name='text') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('vault_id', attribute=False, autofill=False, cli_name='vault_id', multivalue=False, query=True, required=False) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('vault_id', attribute=False, autofill=False, cli_name='vault_id', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Flag('stdout?', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('container_id', attribute=False, cli_name='container_id', multivalue=False, required=False) +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, required=False) +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index b0d41e5e1ec59ddefbdcccf588b97bac2ff798ee..fe23eae5f349f4a2d40c3d3e55f6168a82b961b2 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=108 -# Last change: pvoborni - manage authorization of keytab operations +IPA_API_VERSION_MINOR=109 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif new file mode 100644 index 0000000000000000000000000000000000000000..97553d53938093c1b0ecba0826fc469d0d758c62 --- /dev/null +++ b/install/share/60basev4.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 878d8868bbbb4f774d378b1d2e886841e2b4b7e4..ec417b634aeb80be3a39f2b8e3410e68a1131ee0 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -14,6 +14,7 @@ app_DATA = \ 60ipaconfig.ldif \ 60basev2.ldif \ 60basev3.ldif \ + 60basev4.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ 61kerberos-ipav3.ldif \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..fb938d212f0f4ddd9a8250a362b89c29d3078efd 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -29,6 +29,7 @@ SCHEMA_FILENAMES = ( "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..59e5b629ce4e6c5acac06df78f02106afa6c859e --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,27 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 2bd877a0d89525a69ea2d09647499ab2311bb358..a127f91cbe03aa13ec90bd628eaa29b7a898c3b9 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 325414b64fdacd4d8df261588cfc9b7481923be1..f64e02b5cf2a949a3c0ea7c1702132a3a09c1c19 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index e206289248dfe9ae79bd87271ff2c7672fb98b4f..f639d9f6e8ab709e43e53be354912e9ae097db56 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -22,6 +22,7 @@ from time import gmtime, strftime import string import posixpath import os +import traceback from ipalib import api, errors from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime @@ -889,6 +890,14 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + try: + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_name, vaultcontainer_parent_id) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..711fd779b79f2fcf4df27ceb9e5c6be186cca11e --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,865 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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, either version 3 of the License, or +# (at your option) any later version. +# +# 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, see . + +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import * +from ipalib.plugins import baseldap +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths +import ipapython.nsslib + +__doc__ = _(""" +Vaults + +Manage vaults and vault containers. + +EXAMPLES: + + List private vaults: + ipa vault-find + + List shared vaults: + ipa vault-find --parent /shared + + Add a standard vault: + ipa vault-add MyVault + + Show a vault: + ipa vault-show MyVault + + Archive data into standard vault: + ipa vault-archive MyVault --in data.bin + + Retrieve data from standard vault: + ipa vault-retrieve MyVault --out data.bin + + Delete a vault: + ipa vault-del MyVault + + List private vault containers: + ipa vaultcontainer-find + + List top-level vault containers: + ipa vaultcontainer-find --parent / + + Add a vault container: + ipa vaultcontainer-add MyContainer + + Show a vault container: + ipa vaultcontainer-show MyContainer + + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = "KRA Transport Certificate" + + at register() +class vaultcontainer(LDAPObject): + """ + Vault container object. + """ + base_dn = DN(api.env.container_vault, api.env.basedn) + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'container_id', 'cn', 'description', + ] + search_display_attributes = [ + 'container_id', 'cn', 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='container_name', + label=_('Container name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + Str('container_id?', + cli_name='container_id', + label=_('Container ID'), + doc=_('Container ID'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **options): + """ + Generates vault container DN from container ID. + """ + + # get container ID from parameters + name = keys[0] if keys else None + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + container_id = parent_id + name + u'/' if name else parent_id + + dn = self.base_dn + + # for each name in the ID, prepend the base DN + for name in container_id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + def get_id(self, dn): + """ + Generates container ID from container DN. + """ + + if len(dn) < len(self.base_dn): + raise errors.ValidationError(name='dn', + error=_("Invalid container DN.")) + + if dn == self.base_dn: + return u'/' + + parent_dn = DN(dn[1:]) + parent_id = self.get_id(parent_dn) + + rdn = dn[0] + name = rdn['cn'] + id = parent_id + name + u'/' + + return id + + def get_private_id(self, username=None): + """ + Returns user's private container ID (i.e. /users//). + """ + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + """ + Normalizes container ID. + """ + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + """ + Splits a normalized container ID into (container name, parent ID) tuple. + """ + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return container name and parent ID + return (parts[1], parts[0] + u'/') + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + assert isinstance(dn, DN) + + # add parent container if it doesn't exist + try: + parent_dn = DN(dn[1:]) + parent_id = self.obj.get_id(parent_dn) + (parent_name, grandparent_id) = self.obj.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + assert isinstance(base_dn, DN) + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent=parent_id) + + return (filter, base_dn, scope) + + def post_callback(self, ldap, entries, truncated, *args, **options): + + for entry in entries: + entry['container_id'] = self.obj.get_id(entry.dn) + + return truncated + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault(LDAPObject): + """ + Vault object. + """ + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'vault_id', 'cn', 'description', + ] + search_display_attributes = [ + 'vault_id', 'cn', 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + Str('vault_id?', + cli_name='vault_id', + label=_('Vault ID'), + doc=_('Vault ID'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **options): + """ + Generates vault DN from vault ID. + """ + + # get vault ID from parameters + name = keys[0] if keys else None + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + vault_id = parent_id + name if name else parent_id + + dn = api.Object.vaultcontainer.base_dn + + # for each name in the ID, prepend the base DN + for name in vault_id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + def get_id(self, dn): + """ + Generates vault ID from vault DN. + """ + + if len(dn) <= len(api.Object.vaultcontainer.base_dn): + raise errors.ValidationError(name='dn', + error=_("Invalid vault DN.")) + + parent_dn = DN(dn[1:]) + parent_id = api.Object.vaultcontainer.get_id(parent_dn) + + rdn = dn[0] + name = rdn['cn'] + id = parent_id + name + + return id + + def split_id(self, id): + """ + Splits a vault ID into (vault name, parent ID) tuple. + """ + + # split ID into parent ID and vault name + parts = id.rsplit(u'/', 1) + + # return vault name and parent ID + return (parts[1], parts[0] + u'/') + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Bytes('data?', + cli_name='data', + doc=_('Base-64 encoded binary data to archive'), + ), + Str('text?', + cli_name='text', + doc=_('Text data to archive'), + ), + Str('in?', + cli_name='in', + doc=_('File containing data to archive'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + data = options.get('data') + text = options.get('text') + input_file = options.get('in') + + # don't send these parameters to server + if 'data' in options: + del options['data'] + if 'text' in options: + del options['text'] + if 'in' in options: + del options['in'] + + # get data + if data: + pass + + elif text: + data = text.encode('utf-8') + + elif input_file: + with open(input_file, 'rb') as f: + data = f.read() + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive initial data + api.Command.vault_archive( + vault_name, + parent=parent_id, + data=data) + + return response + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + assert isinstance(dn, DN) + + # add parent container if it doesn't exist + try: + parent_dn = DN(dn[1:]) + parent_id = api.Object.vaultcontainer.get_id(parent_dn) + (parent_name, grandparent_id) = api.Object.vaultcontainer.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + vault_id = self.obj.get_id(dn) + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + try: + client_key_id = 'ipa' + vault_id.replace(u'/', u'-') + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + return dn + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + assert isinstance(base_dn, DN) + + parent_id = self.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = self.Object.vaultcontainer.get_dn(parent=parent_id) + + return (filter, base_dn, scope) + + + def post_callback(self, ldap, entries, truncated, *args, **options): + + for entry in entries: + entry['vault_id'] = self.obj.get_id(entry.dn) + + return truncated + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive data into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('data?', + cli_name='data', + doc=_('Base-64 encoded binary data to archive'), + ), + Str('text?', + cli_name='text', + doc=_('Text data to archive'), + ), + Str('in?', + cli_name='in', + doc=_('File containing data to archive'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived data into vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + data = options.get('data') + text = options.get('text') + input_file = options.get('in') + + # don't send these parameters to server + if 'data' in options: + del options['data'] + if 'text' in options: + del options['text'] + if 'in' in options: + del options['in'] + + # get data + if data: + pass + + elif text: + data = text.encode('utf-8') + + elif input_file: + with open(input_file, 'rb') as f: + data = f.read() + + else: + data = '' + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + # generate session key + session_key = crypto.generate_session_key() + + # retrieve transport certificate + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + # encrypt data with session key + nonce = crypto.generate_nonce_iv() + encrypted_data = crypto.symmetric_wrap( + data, + session_key, + nonce_iv=nonce + ) + + # send archival request to server + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + vault_id = self.obj.get_id(dn) + entry_attrs['vault_id'] = vault_id + + # connect to KRA + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa' + vault_id.replace(u'/', u'-') + + # deactivate any existing KRA record for the vault + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + # forward encrypted data to KRA + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + "{1 2 840 113549 3 7}", + base64.encodestring(nonce), + ) + + kra_account.logout() + + return dn + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a data from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Flag('stdout?', + doc=_('Show data on standard output'), + autofill=False, + ), + Str('out?', + cli_name='out', + doc=_('File to store retrieved data'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + has_output_params = ( + Bytes('data', + label=_('Data'), + ), + ) + + msg_summary = _('Retrieved data from vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + stdout = options.get('stdout') + output_file = options.get('out') + + # don't send these parameters to server + if 'stdout' in options: + del options['stdout'] + if 'out' in options: + del options['out'] + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + # generate session key + session_key = crypto.generate_session_key() + + # retrieve transport certificate + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + # send retrieval request to server + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + # decrypt encrypted data with session key + data = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if stdout: + print data + response['result'] = {} + response['summary'] = None + + elif output_file: + with open(output_file, 'w') as f: + f.write(data) + + else: + response['result']['data'] = data + + return response + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + vault_id = self.obj.get_id(dn) + entry_attrs['vault_id'] = vault_id + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + # connect to KRA + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa' + vault_id.replace(u'/', u'-') + + # find KRA record for the vault + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + except pki.ResourceNotFoundException: + raise errors.NotFound(reason=_("Data not found.")) + + # retrieve encrypted data from KRA + key = kra_client.keys.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + entry_attrs['encrypted_data'] = base64.b64encode(key.encrypted_data) + entry_attrs['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return dn diff --git a/ipapython/dn.py b/ipapython/dn.py index 834291fbe8696622162efa5193622d74f11f25ca..cdc84052b29047e27b1a0349cbcb11873ec48e56 100644 --- a/ipapython/dn.py +++ b/ipapython/dn.py @@ -1247,6 +1247,8 @@ class DN(object): return rdns[0] else: return rdns + elif isinstance(value, list): + return value # create DN from a list of RDNs elif isinstance(value, (tuple, list)): if len(value) != 2: raise ValueError("tuple or list must be 2-valued, not \"%s\"" % (value)) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index d1569697cba7d7fb9f44a3b85afb643a42624f20..9fa736dcf635b286035b4438a6c342e64f09d1d6 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipapk11.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", -- 1.9.0 From edewata at redhat.com Tue Nov 4 06:28:54 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 00:28:54 -0600 Subject: [Freeipa-devel] [PATCH] 355 Added vault access control. In-Reply-To: <54501A32.3080905@redhat.com> References: <54480DE1.3070103@redhat.com> <54501A32.3080905@redhat.com> Message-ID: <54587226.7020502@redhat.com> On 10/28/2014 5:35 PM, Endi Sukma Dewata wrote: > On 10/22/2014 3:04 PM, Endi Sukma Dewata wrote: >> New LDAP ACIs have been added to allow users to create their own >> private vault container, to allow owners to manage vaults and >> containers, and to allow members to use the vaults. New CLIs have >> been added to manage the owner and member list. For archive and >> retrieve operations the access control has to be enforced by the >> plugins because the operations only affects KRA. The LDAP schema >> has been updated as well. >> >> Ticket #3872 >> >> This patch depends on #353-2. > > New patch attached to fix the ticket URL. It depends on #353-3. New patch attached for some cleanups. -- Endi S. Dewata -------------- next part -------------- >From a9714d34d180ce26c3d484fe313c991fa101ccfb Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 17 Oct 2014 12:05:34 -0400 Subject: [PATCH] Added vault access control. New LDAP ACIs have been added to allow users to create their own private vault container, to allow owners to manage vaults and containers, and to allow members to use the vaults. New CLIs have been added to manage the owner and member list. For archive and retrieve operations the access control has to be enforced by the plugins because the operations only affects KRA. The LDAP schema has been updated as well. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 134 +++++++++++++++++++++++++++--- VERSION | 4 +- install/share/60basev4.ldif | 4 +- install/updates/40-vault.update | 7 ++ ipalib/plugins/vault.py | 177 +++++++++++++++++++++++++++++++++++++++- 5 files changed, 310 insertions(+), 16 deletions(-) diff --git a/API.txt b/API.txt index b73da0af55a3c514de73ae4e1b2a4d13c01c903d..ee33af74eb2870fcdf1ab7e6781797b348243a8f 100644 --- a/API.txt +++ b/API.txt @@ -4476,12 +4476,13 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4491,13 +4492,40 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,11,3 +args: 1,12,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') option: Bytes('encrypted_data?', cli_name='encrypted_data') option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Bytes('nonce?', cli_name='nonce') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4518,11 +4546,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vault_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4535,12 +4564,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4550,10 +4580,37 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_retrieve -args: 1,8,3 +args: 1,9,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('out?', cli_name='out') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4565,9 +4622,10 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4576,12 +4634,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vaultcontainer_add -args: 1,8,3 +args: 1,9,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('container_id', attribute=False, cli_name='container_id', multivalue=False, required=False) option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -4589,6 +4648,32 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_del args: 1,3,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) @@ -4599,12 +4684,13 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vaultcontainer_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4616,13 +4702,14 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vaultcontainer_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, required=False) option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4631,11 +4718,38 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index fe23eae5f349f4a2d40c3d3e55f6168a82b961b2..c471ed80af6a2c26be7fc89281ae60fac6c68577 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=109 -# Last change: edewata - initial vault implementation +IPA_API_VERSION_MINOR=110 +# Last change: edewata - added vault access control diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif index 97553d53938093c1b0ecba0826fc469d0d758c62..61590562ffa174134e10567be93c18ab437d8008 100644 --- a/install/share/60basev4.ldif +++ b/install/share/60basev4.ldif @@ -1,3 +1,3 @@ dn: cn=schema -objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update index 59e5b629ce4e6c5acac06df78f02106afa6c859e..455d4719f612198890f8a914d3a13794a3b9ad75 100644 --- a/install/updates/40-vault.update +++ b/install/updates/40-vault.update @@ -4,6 +4,13 @@ default: objectClass: nsContainer default: objectClass: ipaVaultContainer default: cn: vaults default: description: Root vault container +default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,$SUFFIX")(targetattr="*")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container members can access the container"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can modify the container"; allow(read, search, compare, write) userattr="owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can manage sub-containers"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) dn: cn=services,cn=vaults,$SUFFIX default: objectClass: top diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 711fd779b79f2fcf4df27ceb9e5c6be186cca11e..20948b267e2c585bd59e801d02f9e0b752399609 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -68,6 +68,18 @@ EXAMPLES: Delete a vault: ipa vault-del MyVault + Add a vault owner: + ipa vault-add-owner MyVault --users testuser + + Delete a vault owner: + ipa vault-remove-owner MyVault --users testuser + + Add a vault member: + ipa vault-add-member MyVault --users testuser + + Delete a vault member: + ipa vault-remove-member MyVault --users testuser + List private vault containers: ipa vaultcontainer-find @@ -82,6 +94,18 @@ EXAMPLES: Delete a vault container: ipa vaultcontainer-del MyContainer + + Add a vault container owner: + ipa vaultcontainer-add-owner MyContainer --users testuser + + Delete a vault container owner: + ipa vaultcontainer-remove-owner MyContainer --users testuser + + Add a vault container member: + ipa vaultcontainer-add-member MyContainer --users testuser + + Delete a vault container member: + ipa vaultcontainer-remove-member MyContainer --users testuser """) register = Registry() @@ -98,11 +122,15 @@ class vaultcontainer(LDAPObject): object_class = ['ipaVaultContainer'] default_attributes = [ - 'container_id', 'cn', 'description', + 'container_id', 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'container_id', 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vault Containers') label_singular = _('Vault Container') @@ -231,6 +259,11 @@ class vaultcontainer_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: parent_dn = DN(dn[1:]) @@ -323,6 +356,61 @@ class vaultcontainer_show(LDAPRetrieve): @register() +class vaultcontainer_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + + at register() +class vaultcontainer_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault container.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + + at register() +class vaultcontainer_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + + at register() +class vaultcontainer_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault container.') + + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + + at register() class vault(LDAPObject): """ Vault object. @@ -332,11 +420,15 @@ class vault(LDAPObject): object_class = ['ipaVault'] default_attributes = [ - 'vault_id', 'cn', 'description', + 'vault_id', 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'vault_id', 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vaults') label_singular = _('Vault') @@ -481,6 +573,11 @@ class vault_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: parent_dn = DN(dn[1:]) @@ -699,6 +796,17 @@ class vault_archive(LDAPRetrieve): assert isinstance(dn, DN) vault_id = self.obj.get_id(dn) + + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) + entry_attrs['vault_id'] = vault_id # connect to KRA @@ -833,6 +941,17 @@ class vault_retrieve(LDAPRetrieve): assert isinstance(dn, DN) vault_id = self.obj.get_id(dn) + + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) + entry_attrs['vault_id'] = vault_id wrapped_session_key = base64.b64decode(options['wrapped_session_key']) @@ -863,3 +982,57 @@ class vault_retrieve(LDAPRetrieve): kra_account.logout() return dn + + + at register() +class vault_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + + at register() +class vault_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + + at register() +class vault_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + + at register() +class vault_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) -- 1.9.0 From edewata at redhat.com Tue Nov 4 06:29:59 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 00:29:59 -0600 Subject: [Freeipa-devel] [PATCH] 356 Added command to retrieve vault transport certificate. In-Reply-To: <5450262C.9050906@redhat.com> References: <54480E30.8040905@redhat.com> <5448E41D.5030401@redhat.com> <5450262C.9050906@redhat.com> Message-ID: <54587267.7030806@redhat.com> On 10/28/2014 6:26 PM, Endi Sukma Dewata wrote: > On 10/23/2014 6:18 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 22.10.2014 v 22:06 Endi Sukma Dewata napsal(a): >>> A new command has been added to retrieve the vault transport >>> certificate and optionally save it into a file. The vault archive >>> and retrieve command has been modified to retrieve the transport >>> certificate and store it locally for subsequent usage. This way >>> it's no longer necessary to manually import the transport >>> certificate into the client's NSS database. >> >> As part of the CA certificate renewal feature in 4.1, I have added a >> LDAP certificate store to IPA, see >> . Currently it >> supports only CA certificates, but can be extended to support end entity >> certificates rather easily. If you use it for the vault transport >> certificate, it can be added to the client NSS database automatically on >> install. >> >> Honza >> > > I'm attaching a new patch that's identical to the previous one with > ticket URL updated. I'm thinking we should check this patch in first > because it's already done, and then investigate the use of CA cert > management utility as a separate enhancement since the it seems to need > to be generalized before it can be used to manage KRA transport cert. > I'll also need to investigate the KRA transport cert replacement process > to make sure it can be accommodated via IPA's cert management utility. Revised the patch to always download the transport certificate (no local caching). Further optimization can be done later. -- Endi S. Dewata -------------- next part -------------- >From ef9af13e577343d3ff2564e81b9b6dc895a03b09 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 22 Oct 2014 10:02:25 -0400 Subject: [PATCH] Added command to retrieve vault transport certificate. A new command has been added to retrieve the vault transport certificate and optionally save it into a file. The vault archive and retrieve command has been modified to retrieve the transport certificate and store it locally for subsequent usage. This way it's no longer necessary to manually import the transport certificate into the client's NSS database. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 5 ++++ VERSION | 4 +-- ipalib/plugins/vault.py | 80 +++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 84 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index ee33af74eb2870fcdf1ab7e6781797b348243a8f..7668e8ceebb1a2b6e6ebcd6d70c9209f5a874627 100644 --- a/API.txt +++ b/API.txt @@ -4633,6 +4633,11 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_transport_cert +args: 0,2,1 +option: Str('out?', cli_name='out') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vaultcontainer_add args: 1,9,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/VERSION b/VERSION index c471ed80af6a2c26be7fc89281ae60fac6c68577..d0ada131b700e93faa8c4946b811db36d76341a9 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=110 -# Last change: edewata - added vault access control +IPA_API_VERSION_MINOR=111 +# Last change: edewata - added vault transport certificate diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 20948b267e2c585bd59e801d02f9e0b752399609..00a7a3471d79eee741a1986224c3ad534ec5ff3d 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -24,6 +24,8 @@ import shutil import string import tempfile +import nss.nss as nss + import pki import pki.account import pki.crypto @@ -109,7 +111,6 @@ EXAMPLES: """) register = Registry() -transport_cert_nickname = "KRA Transport Certificate" @register() class vaultcontainer(LDAPObject): @@ -693,6 +694,63 @@ class vault_show(LDAPRetrieve): @register() +class vault_transport_cert(Command): + __doc__ = _('Retrieve vault transport certificate.') + + + # list of attributes we want exported to JSON + json_friendly_attributes = ( + 'takes_args', + ) + + takes_options = ( + Str('out?', + cli_name='out', + doc=_('Output file to store the transport certificate'), + ), + ) + + has_output_params = ( + Str('certificate', + label=_('Certificate'), + ), + ) + + def __json__(self): + json_dict = dict( + (a, getattr(self, a)) for a in self.json_friendly_attributes + ) + json_dict['takes_options'] = list(self.get_json_options()) + return json_dict + + def forward(self, *args, **options): + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + response = super(vault_transport_cert, self).forward(*args, **options) + + if file: + with open(file, 'w') as f: + f.write(response['result']['certificate']) + + return response + + def execute(self, *args, **options): + + kra_client = api.Backend.kra.get_client() + transport_cert = kra_client.system_certs.get_transport_cert() + return { + 'result': { + 'certificate': transport_cert.encoded + } + } + + + at register() class vault_archive(LDAPRetrieve): __doc__ = _('Archive data into a vault.') @@ -769,7 +827,15 @@ class vault_archive(LDAPRetrieve): session_key = crypto.generate_session_key() # retrieve transport certificate - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + api.Command.vault_transport_cert(out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) # wrap session key with transport certificate wrapped_session_key = crypto.asymmetric_wrap( @@ -901,7 +967,15 @@ class vault_retrieve(LDAPRetrieve): session_key = crypto.generate_session_key() # retrieve transport certificate - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + api.Command.vault_transport_cert(out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) # wrap session key with transport certificate wrapped_session_key = crypto.asymmetric_wrap( -- 1.9.0 From edewata at redhat.com Tue Nov 4 06:30:47 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 00:30:47 -0600 Subject: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults. Message-ID: <54587297.1030802@redhat.com> The IPA vault has been modified to support symmetric and asymmetric vaults to allow client to pre-encrypt the data. Due to the status of the crypto library the actual encryption will be added separately later. New LDAP attribute types have been added to store vault type, salt and public key. https://fedorahosted.org/freeipa/ticket/3872 -- Endi S. Dewata -------------- next part -------------- From 062d86c4bf4f58eadb863cbcd01bd39ef30691d8 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 24 Oct 2014 19:53:16 -0400 Subject: [PATCH] Added symmetric and asymmetric vaults. The IPA vault has been modified to support symmetric and asymmetric vaults to allow client to pre-encrypt the data. Due to the status of the crypto library the actual encryption will be added separately later. New LDAP attribute types have been added to store vault type, salt and public key. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 27 +++- VERSION | 4 +- install/share/60basev4.ldif | 7 +- ipalib/plugins/vault.py | 332 +++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 358 insertions(+), 12 deletions(-) diff --git a/API.txt b/API.txt index 7668e8ceebb1a2b6e6ebcd6d70c9209f5a874627..7c4a87dcab4a523977cc63341801120816088db1 100644 --- a/API.txt +++ b/API.txt @@ -4476,14 +4476,20 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,11,3 +args: 1,17,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('in?', cli_name='in') +option: Bytes('ipavaultpublickey', attribute=True, cli_name='public_key', multivalue=False, required=False) +option: Bytes('ipavaultsalt', attribute=True, cli_name='salt', multivalue=False, required=False) +option: Str('ipavaulttype', attribute=True, autofill=True, cli_name='type', default=u'standard', multivalue=False, required=False) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') +option: Str('public_key_file?', cli_name='public_key_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) option: Str('text?', cli_name='text') @@ -4519,7 +4525,7 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,12,3 +args: 1,14,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') @@ -4528,6 +4534,8 @@ option: Str('in?', cli_name='in') option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Bytes('nonce?', cli_name='nonce') option: Str('parent?', cli_name='parent') +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) option: Str('text?', cli_name='text') @@ -4546,11 +4554,14 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vault_find -args: 1,11,4 +args: 1,14,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Bytes('ipavaultpublickey', attribute=True, autofill=False, cli_name='public_key', multivalue=False, query=True, required=False) +option: Bytes('ipavaultsalt', attribute=True, autofill=False, cli_name='salt', multivalue=False, query=True, required=False) +option: Str('ipavaulttype', attribute=True, autofill=False, cli_name='type', default=u'standard', multivalue=False, query=True, required=False) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) @@ -4564,12 +4575,15 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod -args: 1,11,3 +args: 1,14,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bytes('ipavaultpublickey', attribute=True, autofill=False, cli_name='public_key', multivalue=False, required=False) +option: Bytes('ipavaultsalt', attribute=True, autofill=False, cli_name='salt', multivalue=False, required=False) +option: Str('ipavaulttype', attribute=True, autofill=False, cli_name='type', default=u'standard', multivalue=False, required=False) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4607,12 +4621,15 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_retrieve -args: 1,9,3 +args: 1,12,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('out?', cli_name='out') option: Str('parent?', cli_name='parent') +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') +option: Str('private_key_file?', cli_name='private_key_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) option: Flag('stdout?', autofill=True, default=False) diff --git a/VERSION b/VERSION index d0ada131b700e93faa8c4946b811db36d76341a9..e539483c786d255bb3175912d34d0c7649f1fad3 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=111 -# Last change: edewata - added vault transport certificate +IPA_API_VERSION_MINOR=112 +# Last change: edewata - added symmetric and asymmetric vaults diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif index 61590562ffa174134e10567be93c18ab437d8008..efe714e47193d97c8c7a27dc8602ac9dd5a60bc0 100644 --- a/install/share/60basev4.ldif +++ b/install/share/60basev4.ldif @@ -1,3 +1,6 @@ dn: cn=schema -objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) +attributeTypes: (2.16.840.1.113730.3.8.18.2.1 NAME 'ipaVaultType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.2') +attributeTypes: (2.16.840.1.113730.3.8.18.2.2 NAME 'ipaVaultSalt' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.2') +attributeTypes: (2.16.840.1.113730.3.8.18.2.3 NAME 'ipaVaultPublicKey' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'IPA v4.2') +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member $ ipaVaultType $ ipaVaultSalt $ ipaVaultPublicKey ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.2' ) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 00a7a3471d79eee741a1986224c3ad534ec5ff3d..5e2c000de53892dc6a744a349b97c953baa5a225 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -17,6 +17,7 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see . +import getpass import json import os import random @@ -58,15 +59,33 @@ EXAMPLES: Add a standard vault: ipa vault-add MyVault + Add a symmetric vault: + ipa vault-add MyVault --type symmetric --password-file password.txt + + Add an asymmetric vault: + ipa vault-add MyVault --type asymmetric --public-key-file public.pem + Show a vault: ipa vault-show MyVault Archive data into standard vault: ipa vault-archive MyVault --in data.bin + Archive data into symmetric vault: + ipa vault-archive MyVault --in data.bin --password-file password.txt + + Archive data into asymmetric vault: + ipa vault-archive MyVault --in data.bin + Retrieve data from standard vault: ipa vault-retrieve MyVault --out data.bin + Retrieve data from symmetric vault: + ipa vault-retrieve MyVault --out data.bin --password-file password.txt + + Retrieve data from asymmetric vault: + ipa vault-retrieve MyVault --out data.bin --private-key-file private.pem + Delete a vault: ipa vault-del MyVault @@ -421,10 +440,10 @@ class vault(LDAPObject): object_class = ['ipaVault'] default_attributes = [ - 'vault_id', 'cn', 'description', 'owner', 'member', + 'vault_id', 'cn', 'description', 'ipavaulttype', 'ipavaultsalt', 'ipavaultpublickey', 'owner', 'member', ] search_display_attributes = [ - 'vault_id', 'cn', 'description', + 'vault_id', 'cn', 'description', 'ipavaulttype', ] attribute_members = { 'owner': ['user', 'group'], @@ -448,6 +467,23 @@ class vault(LDAPObject): label=_('Description'), doc=_('Vault description'), ), + Str('ipavaulttype?', + cli_name='type', + label=_('Type'), + doc=_('Vault type'), + default=u'standard', + autofill=True, + ), + Bytes('ipavaultsalt?', + cli_name='salt', + label=_('Salt'), + doc=_('Vault salt'), + ), + Bytes('ipavaultpublickey?', + cli_name='public_key', + label=_('Public key'), + doc=_('Vault public key'), + ), Str('parent?', cli_name='parent', label=_('Parent'), @@ -510,6 +546,24 @@ class vault(LDAPObject): # return vault name and parent ID return (parts[1], parts[0] + u'/') + def generate_symmetric_key(self, password, salt): + """ + Generates symmetric key from password and salt. + """ + return None + + def encrypt(self, data, symmetric_key=None, public_key=None): + """ + Encrypts data with symmetric key or public key. + """ + return data + + def decrypt(self, data, symmetric_key=None, private_key=None): + """ + Decrypts data with symmetric key or public key. + """ + return data + @register() class vault_add(LDAPCreate): @@ -528,6 +582,18 @@ class vault_add(LDAPCreate): cli_name='in', doc=_('File containing data to archive'), ), + Str('password?', + cli_name='password', + doc=_('Vault password'), + ), + Str('password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Str('public_key_file?', + cli_name='public_key_file', + doc=_('File containing the vault public key'), + ), ) msg_summary = _('Added vault "%(value)s"') @@ -537,9 +603,13 @@ class vault_add(LDAPCreate): vault_name = args[0] parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + vault_type = options.get('ipavaulttype') data = options.get('data') text = options.get('text') input_file = options.get('in') + password = options.get('password') + password_file = options.get('password_file') + public_key_file = options.get('public_key_file') # don't send these parameters to server if 'data' in options: @@ -548,6 +618,12 @@ class vault_add(LDAPCreate): del options['text'] if 'in' in options: del options['in'] + if 'password' in options: + del options['password'] + if 'password_file' in options: + del options['password_file'] + if 'public_key_file' in options: + del options['public_key_file'] # get data if data: @@ -560,6 +636,72 @@ class vault_add(LDAPCreate): with open(input_file, 'rb') as f: data = f.read() + # type-specific initialization + if vault_type == 'standard': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + if public_key_file: + raise errors.ValidationError(name='public_key_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + elif vault_type == 'symmetric': + + if public_key_file: + raise errors.ValidationError(name='public_key_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + # get vault password + if password: + pass + + elif password_file: + with open(password_file) as f: + password = unicode(f.read().rstrip('\n')) + + else: + while True: + password = unicode(getpass.getpass('New password: ')) + password2 = unicode(getpass.getpass('Verify password: ')) + if password == password2: + break + print ' ** Passwords do not match! **' + + # generate vault salt + salt = base64.b64encode(os.urandom(16)) + options['ipavaultsalt'] = salt + + elif vault_type == 'asymmetric': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + # get vault public key + if public_key_file: + with open(public_key_file, 'rb') as f: + public_key = f.read() + else: + raise errors.ValidationError(name='public_key_file', + error=_('Missing vault public key')) + + # store vault public key + options['ipavaultpublickey'] = public_key + + else: + raise errors.ValidationError(name='vault_type', + error=_('Invalid vault type')) + # create the vault response = super(vault_add, self).forward(*args, **options) @@ -567,7 +709,8 @@ class vault_add(LDAPCreate): api.Command.vault_archive( vault_name, parent=parent_id, - data=data) + data=data, + password=password) return response @@ -783,6 +926,14 @@ class vault_archive(LDAPRetrieve): cli_name='nonce', doc=_('Nonce encrypted encoded in base-64'), ), + Str('password?', + cli_name='password', + doc=_('Vault password'), + ), + Str('password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), ) msg_summary = _('Archived data into vault "%(value)s"') @@ -792,9 +943,28 @@ class vault_archive(LDAPRetrieve): vault_name = args[0] parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + vault_type = 'standard' + salt = None + public_key = None + + # retrieve vault info + response = api.Command.vault_show(vault_name, parent=parent_id) + result = response['result'] + + if result.has_key('ipavaulttype'): + vault_type = result['ipavaulttype'][0] + + if result.has_key('ipavaultsalt'): + salt = str(result['ipavaultsalt'][0]) + + if result.has_key('ipavaultpublickey'): + public_key = str(result['ipavaultpublickey'][0]) + data = options.get('data') text = options.get('text') input_file = options.get('in') + password = options.get('password') + password_file = options.get('password_file') # don't send these parameters to server if 'data' in options: @@ -803,6 +973,10 @@ class vault_archive(LDAPRetrieve): del options['text'] if 'in' in options: del options['in'] + if 'password' in options: + del options['password'] + if 'password_file' in options: + del options['password_file'] # get data if data: @@ -818,6 +992,61 @@ class vault_archive(LDAPRetrieve): else: data = '' + # pre-encrypt data + if vault_type == 'standard': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + elif vault_type == 'symmetric': + + # get vault password + if password: + pass + + elif password_file: + with open(password_file) as f: + password = unicode(f.read().rstrip('\n')) + else: + password = unicode(getpass.getpass('Password: ')) + + try: + api.Command.vault_retrieve( + vault_name, + parent=parent_id, + password=password) + + except errors.NotFound: + pass + + # generate symmetric key from vault password + symmetric_key = self.obj.generate_symmetric_key(password, salt) + + # pre-encrypt data with symmetric key + data = self.obj.encrypt(data, symmetric_key=symmetric_key) + + elif vault_type == 'asymmetric': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + # pre-encrypt data with public key + data = self.obj.encrypt(data, public_key=public_key) + + else: + raise errors.ValidationError(name='vault_type', + error=_('Invalid vault type')) + # initialize NSS database crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) crypto.initialize() @@ -934,6 +1163,18 @@ class vault_retrieve(LDAPRetrieve): cli_name='wrapped_session_key', doc=_('Session key wrapped with transport certificate and encoded in base-64'), ), + Str('password?', + cli_name='password', + doc=_('Vault password'), + ), + Str('password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Str('private_key_file?', + cli_name='private_key_file', + doc=_('File containing the vault private key'), + ), ) has_output_params = ( @@ -949,14 +1190,36 @@ class vault_retrieve(LDAPRetrieve): vault_name = args[0] parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + vault_type = 'standard' + salt = None + + # retrieve vault info + response = api.Command.vault_show(vault_name, parent=parent_id) + result = response['result'] + + if result.has_key('ipavaulttype'): + vault_type = result['ipavaulttype'][0] + + if result.has_key('ipavaultsalt'): + salt = str(result['ipavaultsalt'][0]) + stdout = options.get('stdout') output_file = options.get('out') + password = options.get('password') + password_file = options.get('password_file') + private_key_file = options.get('private_key_file') # don't send these parameters to server if 'stdout' in options: del options['stdout'] if 'out' in options: del options['out'] + if 'password' in options: + del options['password'] + if 'password_file' in options: + del options['password_file'] + if 'private_key_file' in options: + del options['private_key_file'] # initialize NSS database crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) @@ -997,6 +1260,69 @@ class vault_retrieve(LDAPRetrieve): session_key, nonce_iv=nonce) + if vault_type == 'standard': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + if private_key_file: + raise errors.ValidationError(name='private_key_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + elif vault_type == 'symmetric': + + if private_key_file: + raise errors.ValidationError(name='private_key_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + # get vault password + if password: + pass + + elif password_file: + with open(password_file) as f: + password = unicode(f.read().rstrip('\n')) + + else: + password = unicode(getpass.getpass('Password: ')) + + # generate symmetric key from vault password + symmetric_key = self.obj.generate_symmetric_key(password, salt) + + # post-decrypt data with symmetric key + data = self.obj.decrypt(data, symmetric_key=symmetric_key) + + elif vault_type == 'asymmetric': + + if password: + raise errors.ValidationError(name='password', + error=_('Invalid parameter for %s vault' % vault_type)) + + if password_file: + raise errors.ValidationError(name='password_file', + error=_('Invalid parameter for %s vault' % vault_type)) + + # get vault private key + if private_key_file: + with open(private_key_file, 'rb') as f: + private_key = f.read() + + else: + raise errors.ValidationError(name='private_key_file', + error=_('Missing vault private key')) + + # post-decrypt data with private key + data = self.obj.decrypt(data, private_key=private_key) + + else: + raise errors.ValidationError(name='vault_type', + error=_('Invalid vault type')) + if stdout: print data response['result'] = {} -- 1.9.0 From pspacek at redhat.com Tue Nov 4 09:11:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Nov 2014 10:11:09 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <5457A38F.2030201@redhat.com> References: <54579A28.80607@redhat.com> <5457A38F.2030201@redhat.com> Message-ID: <5458982D.5090307@redhat.com> On 3.11.2014 16:47, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello! >> >> There's been some interest in releasing pieces of FreeIPA's testing >> infrastructure so it can be reused in other projects. >> I will soon take the pytest-beakerlib plugin (currently in my patch >> 0672), and making a stand-alone project out of it. Later I'll extract >> the common pieces of the integration testign framework, and release that >> independently. >> >> >> Do we want projects projects like these to be hosted on Fedorahosted? >> That would be the 100% open-source solution. >> >> Or do we want to put it under a freeipa organization on Github, since >> we're more likely to get external contributors there? > > Why do you think it would get more contributors from github? Because yet > another account isn't required, or the contributor process is perhaps > better understood (via pull requests)? IMHO yes. Even for me it is much easier to quickly do - git clone - edit source - git push - create pull request (*this is the same for every project hosted on Github*) instead of - git clone - edit source (re-do following again for every single project) - hunt submission how-to - join mailing list/create account in project's tracker - prepare patch in project's format-of-choice - send patch >> Or both? (Would we want to "officially" mirror the project to Github >> from FH?) > > I'd be in favor of fedorahosted because you get a tracker and wiki as > well, and having the repo there would round things out. > > rob -- Petr^2 Spacek From pviktori at redhat.com Tue Nov 4 09:30:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 10:30:53 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <5457A38F.2030201@redhat.com> References: <54579A28.80607@redhat.com> <5457A38F.2030201@redhat.com> Message-ID: <54589CCD.3020006@redhat.com> On 11/03/2014 04:47 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello! >> >> There's been some interest in releasing pieces of FreeIPA's testing >> infrastructure so it can be reused in other projects. >> I will soon take the pytest-beakerlib plugin (currently in my patch >> 0672), and making a stand-alone project out of it. Later I'll extract >> the common pieces of the integration testing framework, and release that >> independently. >> >> >> Do we want projects projects like these to be hosted on Fedorahosted? >> That would be the 100% open-source solution. >> >> Or do we want to put it under a freeipa organization on Github, since >> we're more likely to get external contributors there? > > Why do you think it would get more contributors from github? Because yet > another account isn't required, or the contributor process is perhaps > better understood (via pull requests)? Both. The community is larger (i.e. contributors are likely to already have an account on Github), and the contribution process is nowadays more familiar to most people. And I'm not talking about a proprietary process here: the pull request process is "publish a Git repo, and nag people to merge from it". It's built into Git itself ? see git-request-pull(1). Github makes this easy, and adds a Web UI and some inevitable (but optional) proprietary "perks". But underneath it's still Git and e-mail if you care to use those. >> Or both? (Would we want to "officially" mirror the project to Github >> from FH?) > > I'd be in favor of fedorahosted because you get a tracker and wiki as > well, and having the repo there would round things out. Yeah, the tracker is a reason for FH. Github does host git-backed wikis using an open-source backend, but it doesn't have an acceptable bug tracker. -- Petr? From pspacek at redhat.com Tue Nov 4 09:46:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Nov 2014 10:46:24 +0100 Subject: [Freeipa-devel] User life-cycle management as additional plugin Message-ID: <5458A070.6000506@redhat.com> Hello, I wonder if user life-cycle extensions [1] can be in form of separate FreeIPA plugin for FreeIPA framework. Reasoning behind this is that different organizations will have different requirements (including no life-cycle management). I don't think that one-size-fits-all so from my point of view it makes sense to ease replacing our life-cycle management by some home-grown plugin. Is something like that possible? [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management -- Petr^2 Spacek From jcholast at redhat.com Tue Nov 4 09:58:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 04 Nov 2014 10:58:33 +0100 Subject: [Freeipa-devel] User life-cycle management as additional plugin In-Reply-To: <5458A070.6000506@redhat.com> References: <5458A070.6000506@redhat.com> Message-ID: <5458A349.9070908@redhat.com> Hi, Dne 4.11.2014 v 10:46 Petr Spacek napsal(a): > Hello, > > I wonder if user life-cycle extensions [1] can be in form of separate > FreeIPA plugin for FreeIPA framework. > > Reasoning behind this is that different organizations will have > different requirements (including no life-cycle management). > > I don't think that one-size-fits-all so from my point of view it makes > sense to ease replacing our life-cycle management by some home-grown > plugin. > > Is something like that possible? I'm afraid the framework is not extensible enough for this in its current incarnation. There is no way (or just a very hacky one) to add new options to an existing command in the form of a plugin. > > [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management > Honza -- Jan Cholasta From rmeggins at redhat.com Tue Nov 4 10:50:35 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 11:50:35 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <54589CCD.3020006@redhat.com> References: <54579A28.80607@redhat.com> <5457A38F.2030201@redhat.com> <54589CCD.3020006@redhat.com> Message-ID: <5458AF7B.6030304@redhat.com> On 11/04/2014 10:30 AM, Petr Viktorin wrote: > On 11/03/2014 04:47 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello! >>> >>> There's been some interest in releasing pieces of FreeIPA's testing >>> infrastructure so it can be reused in other projects. >>> I will soon take the pytest-beakerlib plugin (currently in my patch >>> 0672), and making a stand-alone project out of it. Later I'll extract >>> the common pieces of the integration testing framework, and release >>> that >>> independently. >>> >>> >>> Do we want projects projects like these to be hosted on Fedorahosted? >>> That would be the 100% open-source solution. >>> >>> Or do we want to put it under a freeipa organization on Github, since >>> we're more likely to get external contributors there? >> >> Why do you think it would get more contributors from github? Because yet >> another account isn't required, or the contributor process is perhaps >> better understood (via pull requests)? > > Both. The community is larger (i.e. contributors are likely to already > have an account on Github), and the contribution process is nowadays > more familiar to most people. +1, from my experience with the openstack community, and with redhat - see github.com/redhat-openstack, et. al. > > And I'm not talking about a proprietary process here: the pull request > process is "publish a Git repo, and nag people to merge from it". It's > built into Git itself ? see git-request-pull(1). > Github makes this easy, and adds a Web UI and some inevitable (but > optional) proprietary "perks". But underneath it's still Git and > e-mail if you care to use those. +1 > >>> Or both? (Would we want to "officially" mirror the project to Github >>> from FH?) >> >> I'd be in favor of fedorahosted because you get a tracker and wiki as >> well, and having the repo there would round things out. > > Yeah, the tracker is a reason for FH. Github does host git-backed > wikis using an open-source backend, but it doesn't have an acceptable > bug tracker. > What's wrong with the github issue tracker? From pviktori at redhat.com Tue Nov 4 11:00:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 12:00:12 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <5458AF7B.6030304@redhat.com> References: <54579A28.80607@redhat.com> <5457A38F.2030201@redhat.com> <54589CCD.3020006@redhat.com> <5458AF7B.6030304@redhat.com> Message-ID: <5458B1BC.5070007@redhat.com> On 11/04/2014 11:50 AM, Rich Megginson wrote: > On 11/04/2014 10:30 AM, Petr Viktorin wrote: >> On 11/03/2014 04:47 PM, Rob Crittenden wrote: [...] >>>> Or both? (Would we want to "officially" mirror the project to Github >>>> from FH?) >>> >>> I'd be in favor of fedorahosted because you get a tracker and wiki as >>> well, and having the repo there would round things out. >> >> Yeah, the tracker is a reason for FH. Github does host git-backed >> wikis using an open-source backend, but it doesn't have an acceptable >> bug tracker. >> > What's wrong with the github issue tracker? It's stored in a closed format and hosted on a proprietary service; if Github goes down or goes evil we lose the issues. -- Petr? From rmeggins at redhat.com Tue Nov 4 11:09:26 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 04 Nov 2014 12:09:26 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <5458B1BC.5070007@redhat.com> References: <54579A28.80607@redhat.com> <5457A38F.2030201@redhat.com> <54589CCD.3020006@redhat.com> <5458AF7B.6030304@redhat.com> <5458B1BC.5070007@redhat.com> Message-ID: <5458B3E6.4010903@redhat.com> On 11/04/2014 12:00 PM, Petr Viktorin wrote: > On 11/04/2014 11:50 AM, Rich Megginson wrote: >> On 11/04/2014 10:30 AM, Petr Viktorin wrote: >>> On 11/03/2014 04:47 PM, Rob Crittenden wrote: > [...] >>>>> Or both? (Would we want to "officially" mirror the project to Github >>>>> from FH?) >>>> >>>> I'd be in favor of fedorahosted because you get a tracker and wiki as >>>> well, and having the repo there would round things out. >>> >>> Yeah, the tracker is a reason for FH. Github does host git-backed >>> wikis using an open-source backend, but it doesn't have an acceptable >>> bug tracker. >>> >> What's wrong with the github issue tracker? > > It's stored in a closed format and hosted on a proprietary service; if > Github goes down or goes evil we lose the issues. > > Ah, ok. That does tilt things in favor of using fedorahosted for trac. I believe we can configure fedorahosted trac to use a different git repo (github) than git.fedorahosted. From mbasti at redhat.com Tue Nov 4 11:33:02 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 04 Nov 2014 12:33:02 +0100 Subject: [Freeipa-devel] [PATCH 0155] Fix CI test Message-ID: <5458B96E.7010508@redhat.com> patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0155-Fix-CI-tests-install_adtrust.patch Type: text/x-patch Size: 1462 bytes Desc: not available URL: From dkupka at redhat.com Tue Nov 4 11:57:02 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 04 Nov 2014 12:57:02 +0100 Subject: [Freeipa-devel] [PATCH] 0026 Stop dirsrv last in ipactl stop. Message-ID: <5458BF0E.7070403@redhat.com> https://fedorahosted.org/freeipa/ticket/4632 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0026-Stop-dirsrv-last-in-ipactl-stop.patch Type: text/x-patch Size: 1369 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 4 11:58:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 12:58:52 +0100 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: <54577AFE.1060201@redhat.com> References: <542AE179.6050303@redhat.com> <54577AFE.1060201@redhat.com> Message-ID: <5458BF7C.10307@redhat.com> On 11/03/2014 01:54 PM, Petr Spacek wrote: > On 4.10.2014 01:58, Gabe Alford wrote: >> Thanks Petr. Updated patch attached. > > Petr^3, is it okay now? Oh my, this patch fell through the cracks during the release frenzy. Apologies! ACK, pushed to master: 7eca640ffa3e661140843d91dc4a846d3355a242 > > Petr^2 Spacek > >> >> On Tue, Sep 30, 2014 at 10:59 AM, Petr Viktorin >> wrote: >> >>> On 09/30/2014 05:13 AM, Gabe Alford wrote: >>> >>>> Updated patch to fix merge conflicts from recent changes. >>>> >>>> On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford >>> > wrote: >>>> >>>> Hello, >>>> >>>> Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me >>>> know >>>> if I missed any. >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>> -- Petr? From pvoborni at redhat.com Tue Nov 4 12:05:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Nov 2014 13:05:05 +0100 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <544A583C.3060601@redhat.com> References: <543E6685.8000704@redhat.com> <5447EBE0.4080203@redhat.com> <5448BEBB.6030609@redhat.com> <544A583C.3060601@redhat.com> Message-ID: <5458C0F1.2070508@redhat.com> >>> On 10/15/2014 02:20 PM, Petr Vobornik wrote: >>>> ticket: https://fedorahosted.org/freeipa/ticket/4221 >>>> updated version of patch 773 attached. Fixes issue in interactive_prompt_callback. Not related to this ticket: - should we show interactive prompt for domain name when user specifies --type=ipa-adtrust or ipa-adtrust-posix? Atm it will prompt for values related to local range. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0773-2-ranges-prohibit-setting-rid-base-with-ipa-trust-ad-p.patch Type: text/x-patch Size: 7292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0774-1-unittests-baserid-for-ipa-ad-trust-posix-idranges.patch Type: text/x-patch Size: 12972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0775-1-ldapupdater-set-baserid-to-0-for-ipa-ad-trust-posix-.patch Type: text/x-patch Size: 3810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0776-1-idrange-include-raw-range-type-in-output.patch Type: text/x-patch Size: 4540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0777-1-webui-prohibit-setting-rid-base-with-ipa-trust-ad-po.patch Type: text/x-patch Size: 5415 bytes Desc: not available URL: From simo at redhat.com Tue Nov 4 13:53:05 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 4 Nov 2014 08:53:05 -0500 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <54579A28.80607@redhat.com> References: <54579A28.80607@redhat.com> Message-ID: <20141104085305.3274d101@willson.usersys.redhat.com> On Mon, 03 Nov 2014 16:07:20 +0100 Petr Viktorin wrote: > Hello! > > There's been some interest in releasing pieces of FreeIPA's testing > infrastructure so it can be reused in other projects. > I will soon take the pytest-beakerlib plugin (currently in my patch > 0672), and making a stand-alone project out of it. Later I'll extract > the common pieces of the integration testign framework, and release > that independently. > > > Do we want projects projects like these to be hosted on Fedorahosted? > That would be the 100% open-source solution. > > Or do we want to put it under a freeipa organization on Github, since > we're more likely to get external contributors there? > > Or both? (Would we want to "officially" mirror the project to Github > from FH?) > > > I'm asking about the projects' "home", the Git repo can of course be > mirrored anywhere. The "release" and "issues" stuff on github is ridiculous, I have no opposition to mirror on github and get pull requests from there, but the "home" (ie where official tarballs are released) should be elsewhere also trac, although perhaps not so fancy looking is much better than github issue tracker imo. The only "nice" thing about github's issues is that you can answer via email, too bad it mangles addresses so that it is super easy to just send any reply in a black hole (done that on several occasions and was wondering why the reporter did not reply). Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Nov 4 14:54:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Nov 2014 15:54:05 +0100 Subject: [Freeipa-devel] [PATCH] 782 webui: use domain name instead of domain SID in idrange adder dialog Message-ID: <5458E88D.4030200@redhat.com> It's more user friendly. Almost nobody remembers SIDs. https://fedorahosted.org/freeipa/ticket/4661 depends on patch 777 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0782-webui-use-domain-name-instead-of-domain-SID-in-idran.patch Type: text/x-patch Size: 6273 bytes Desc: not available URL: From pvoborni at redhat.com Tue Nov 4 14:54:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 04 Nov 2014 15:54:35 +0100 Subject: [Freeipa-devel] [PATCH] 783 webui: normalize idview tab labels Message-ID: <5458E8AB.7000203@redhat.com> ID View tab labels are no longer redundant. https://fedorahosted.org/freeipa/ticket/4650 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0783-webui-normalize-idview-tab-labels.patch Type: text/x-patch Size: 1694 bytes Desc: not available URL: From tbordaz at redhat.com Tue Nov 4 14:54:30 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 04 Nov 2014 15:54:30 +0100 Subject: [Freeipa-devel] User life-cycle management as additional plugin In-Reply-To: <5458A349.9070908@redhat.com> References: <5458A070.6000506@redhat.com> <5458A349.9070908@redhat.com> Message-ID: <5458E8A6.10102@redhat.com> On 11/04/2014 10:58 AM, Jan Cholasta wrote: > Hi, > > Dne 4.11.2014 v 10:46 Petr Spacek napsal(a): >> Hello, >> >> I wonder if user life-cycle extensions [1] can be in form of separate >> FreeIPA plugin for FreeIPA framework. >> >> Reasoning behind this is that different organizations will have >> different requirements (including no life-cycle management). >> >> I don't think that one-size-fits-all so from my point of view it makes >> sense to ease replacing our life-cycle management by some home-grown >> plugin. >> >> Is something like that possible? > > I'm afraid the framework is not extensible enough for this in its > current incarnation. There is no way (or just a very hacky one) to add > new options to an existing command in the form of a plugin. > >> >> [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management >> > > Honza > Hi Petr, I like the idea of home-grown ULC. If it is not feasible with the current framework, customer would have the ability to define home made placeholder. I does not implement the workflow of commands but is a kind of flexibility. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Nov 4 15:08:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 04 Nov 2014 16:08:30 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS Message-ID: <5458EBEE.4050803@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4670 Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0156-Fix-upgrade-do-not-use-invalid-ldap-connection.patch Type: text/x-patch Size: 1698 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 4 15:24:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 16:24:49 +0100 Subject: [Freeipa-devel] [PATCH 0155] Fix CI test In-Reply-To: <5458B96E.7010508@redhat.com> References: <5458B96E.7010508@redhat.com> Message-ID: <5458EFC1.1050401@redhat.com> On 11/04/2014 12:33 PM, Martin Basti wrote: > patch attached > Thanks! ACK, pushed to: master: e7edac30a10c0da40d7cfd625e19bd4237b9e1f6 ipa-4-1: 49a73e1d6b710d777d4cc3a3ac358491c3e0e85a -- Petr? From mbasti at redhat.com Tue Nov 4 15:29:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 04 Nov 2014 16:29:35 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS In-Reply-To: <5458EBEE.4050803@redhat.com> References: <5458EBEE.4050803@redhat.com> Message-ID: <5458F0DF.7070709@redhat.com> On 04/11/14 16:08, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4670 > > Patch attached > > I forgot to mention, this is an ancient bug, IMO the fix should go to all branches. -- Martin Basti From pviktori at redhat.com Tue Nov 4 15:33:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 16:33:40 +0100 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <545209B6.5000504@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> <5448C356.9040105@redhat.com> <54500FC5.7070207@redhat.com> <5450E472.90903@redhat.com> <54513B93.2020409@redhat.com> <545209B6.5000504@redhat.com> Message-ID: <5458F1D4.4050608@redhat.com> On 10/30/2014 10:49 AM, Petr Viktorin wrote: > On 10/29/2014 08:10 PM, Endi Sukma Dewata wrote: >> New patch attached. >> >> On 10/29/2014 7:58 AM, Petr Viktorin wrote: >>>> Dependency is bumped to 10.2.1-0.1 which is available from my >>>> COPR repo: >>>> >>>> dnf copr enable edewata/pki >>> >>> OK. We should get that to an IPA COPR before merging this. >> >> How do we do that? Here is the SRPM: >> https://edewata.fedorapeople.org/pki/copr/pki-core-10.2.1-0.1.fc20.src.rpm >> > > Martin and I will handle this today. > >>> How can I do some basic smoke check on this? Is there something I still >>> need to to besides ipa-kra-istall? Any other patches? > [...] >> >> The simplest test is probably this: >> >> from ipalib import api >> >> api.bootstrap(context='server') >> api.finalize() >> >> kra_client = api.Backend.kra.get_client() >> transport_cert = kra_client.system_certs.get_transport_cert() >> >> print "Serial number: %s" % transport_cert.serial_number >> print "Issuer DN: %s" % transport_cert.issuer_dn >> print "Subject DN: %s" % transport_cert.subject_dn >> >> print transport_cert.encoded > > Thanks! Works here; the rest is for other patches. > > ACK, to be pushed when the COPR is ready. > > Pushed to master: 0b08043c37210d0f86cb0c66d659acafda0fb529 -- Petr? From npmccallum at redhat.com Tue Nov 4 16:17:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 04 Nov 2014 11:17:35 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1414589697.16650.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> Message-ID: <1415117855.3318.3.camel@redhat.com> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > >> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > >>> This patch gives the administrator variables to control the size of > > >>> the authentication and synchronization windows for OTP tokens. > > >>> > > >>> https://fedorahosted.org/freeipa/ticket/4511 > > >>> > > >>> NOTE: There is one known issue with this patch which I don't know how to > > >>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. > > >>> On an upgrade, all of the new attributeTypes appear correctly. However, > > >>> the modifications to the pre-existing objectClass do not show up on the > > >>> server. What am I doing wrong? > > >>> > > >>> After modifying ipaGuiConfig manually, everything in this patch works > > >>> just fine. > > >> > > >> This new version takes into account the new (proper) OIDs and attribute > > >> names. > > > > > > Thanks Nathaniel! > > > > > >> The above known issue still remains. > > > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list extension > > > should work just fine, AFAIK. > > > > You added a blank line to the LDIF file. This is an entry separator, so > > the objectClasses after the blank line don't belong to cn=schema, so > > they aren't considered in the update. > > Without the blank line it works fine. > > Thanks for the catch! > > Here is a version without the blank line. I forgot to remove the old steps defines. This patch performs this cleanup. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0074.3-Make-token-window-sizes-configurable.patch Type: text/x-patch Size: 38076 bytes Desc: not available URL: From edewata at redhat.com Tue Nov 4 16:54:36 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 10:54:36 -0600 Subject: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults. In-Reply-To: <54587297.1030802@redhat.com> References: <54587297.1030802@redhat.com> Message-ID: <545904CC.6030200@redhat.com> Hi, In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute types to store salt and public key for vault. Are there existing attribute types that I can use instead? I see there's an ipaPublicKey, should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. -- Endi S. Dewata On 11/4/2014 12:30 AM, Endi Sukma Dewata wrote: > The IPA vault has been modified to support symmetric and asymmetric > vaults to allow client to pre-encrypt the data. Due to the status > of the crypto library the actual encryption will be added separately > later. > > New LDAP attribute types have been added to store vault type, salt > and public key. > > https://fedorahosted.org/freeipa/ticket/3872 From mbasti at redhat.com Tue Nov 4 16:59:44 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 04 Nov 2014 17:59:44 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <54524168.8040108@redhat.com> References: <54524168.8040108@redhat.com> Message-ID: <54590600.4030103@redhat.com> On 30/10/14 14:47, thierry bordaz wrote: > https://fedorahosted.org/freeipa/ticket/4635 > > I can't reproduce the deadlock, so ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Nov 4 17:36:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Nov 2014 18:36:49 +0100 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <545871D0.5070608@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> <54501A0F.30805@redhat.com> <545871D0.5070608@redhat.com> Message-ID: <54590EB1.1070203@redhat.com> On 11/04/2014 07:27 AM, Endi Sukma Dewata wrote: > On 10/28/2014 5:34 PM, Endi Sukma Dewata wrote: >>>>> The NSSConnection class has to be modified not to shutdown existing >>>>> database because some of the vault clients (e.g. vault-archive and >>>>> vault-retrieve) also use a database to encrypt/decrypt the secret. >>>> >>>> The problem is described in more detail in this ticket: >>>> https://fedorahosted.org/freeipa/ticket/4638 >>>> >>>> The changes to the NSSConnection in the first patch caused the >>>> installation to fail. Attached is a new patch that uses the solution >>>> proposed by jdennis. >>> >>> New patch attached. It's now using the correct OID's for the schema. It >>> also has been rebased on top of #352-1 and #354. >> >> New patch attached to fix the ticket URL. It depends on #352-2 and >> #354-1. > > New patch attached to fix vault/container ID problems and for some > cleanups. The new schema can go to 60basev3.ldif, no need for a new file. ipalib/plugins/user.py: Make the try: block as small as possible; maybe something like this: try: vaultcontainer_id = ... except errors.NotFound: pass else: (vaultcontainer_name, vaultcontainer_parent_id) = ... self.api.Command.vaultcontainer_del(...) ipapython/dn.py: This change is not needed. If you have a sequence of RNDs you can do `DN(*seq)`. ipalib/plugins/vault.py: Do not use star imports in new code; remove the line from ipalib.plugins.baseldap import * and use e.g. `baseldap.LDAPObject` instead of just `LDAPObject`. Hopefully the only star-imported used are the base classes? To make translators' jobs easier, split the help text in __doc__ into strings that can be translated individually. Replace every blank line by: """) + _(""" The pattern and pattern_errmsg for the 'cn' param don't match. Which one is right? Shouldn't a similar check be there for parent? vaultcontainer.get_dn: Why put '/' at the end of container_id, if the empty string is ignored later anyway? Nitpick: In vaultcontainer.get_dn, prefer the if statement over the if-else expressions; it's a bit longer but more readable. In vaultcontainer.get_id, what's the purpose of the len() check? Did you want dn.endswith() instead? I sugggest writing doctests for the id manipulation methods (get_id, get_private_id, ...) ? it's not always obvious what exactly they do. According to the design doc, container IDs shouldn't end in '/'. If you did that I think the manipulation would be simpler, and it could be shared with the vault equivalents. vaultcontainer_add: You should use ldap backend directly. Calling Commands is costly, most of the call is spent doing validation of what here is already validated. You should add a function to recursively create vault container using just the ldap client, and call that here and in vault_add. You can delete a container with children; is that expected? vault_add should complain if it does not get exactly one of data/text/in. What's the difference between vault_add and vault_archive? I don't see vault_archive in the design. It seems '/' is equivalent to '-' as far as KRA is concerned; should we disallow '-' in container/vault names? You can specify an absolute id by starting it with a slash, but only in --parent and not in the name itself. I think this should be possible in the name too. You can't include slashes in the name, so you always need to specify the prefix with --parent. I don't think there's a technical reason for this limitation. There are no tests. -- Petr? From edewata at redhat.com Wed Nov 5 00:24:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Nov 2014 18:24:26 -0600 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <54590EB1.1070203@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> <54501A0F.30805@redhat.com> <545871D0.5070608@redhat.com> <54590EB1.1070203@redhat.com> Message-ID: <54596E3A.9060404@redhat.com> Thanks for the review. I have some questions below. I'll post a new patch after the issues are addressed. On 11/4/2014 11:36 AM, Petr Viktorin wrote: > The new schema can go to 60basev3.ldif, no need for a new file. Fixed. Also removed nsContainer as suggested by Simo. > ipalib/plugins/user.py: Make the try: block as small as possible; maybe > something like this: > > try: > vaultcontainer_id = ... > except errors.NotFound: > pass > else: > (vaultcontainer_name, vaultcontainer_parent_id) = ... > self.api.Command.vaultcontainer_del(...) Actually the command that generates the NotFound exception is the last command. The first two commands are preparing the parameters. I moved them before the try-block. > ipapython/dn.py: This change is not needed. If you have a sequence of > RNDs you can do `DN(*seq)`. This is actually needed to construct a parent DN from an existing DN: parent_dn = DN(dn[1:]) Note that the parameter is an array of RDNs, not a sequence of RDNs. I don't see an existing mechanism to get a parent DN from a DN. Without this change it would generate an error: ValueError: tuple or list must be 2-valued, not "[ipapython.dn.RDN('cn=admin'), ipapython.dn.RDN('cn=users'), ipapython.dn.RDN('cn=vaults'), ipapython.dn.RDN('dc=idm'), ipapython.dn.RDN('dc=lab'), ipapython.dn.RDN('dc=bos'), ipapython.dn.RDN('dc=redhat'), ipapython.dn.RDN('dc=com')]" > ipalib/plugins/vault.py: > Do not use star imports in new code; remove the line > from ipalib.plugins.baseldap import * > and use e.g. `baseldap.LDAPObject` instead of just `LDAPObject`. > Hopefully the only star-imported used are the base classes? I found 20 star imports in the existing plugins :/ All existing plugins are actually using LDAPObject directly, not baseldap.LDAPObject. Is there a concern doing that? I fixed the code to do the same thing. > To make translators' jobs easier, split the help text in __doc__ into > strings that can be translated individually. > Replace every blank line by: > """) + _(""" Fixed. > The pattern and pattern_errmsg for the 'cn' param don't match. Which one > is right? Shouldn't a similar check be there for parent? This is actually copied verbatim from user's uid. Could you give some sample values that show the problem? I think ideally there should be a similar check for parent, but I haven't figured out the proper pattern yet. I think we can do this as a later enhancement. Or maybe we should remove the validation for cn for now. > vaultcontainer.get_dn: Why put '/' at the end of container_id, if the > empty string is ignored later anyway? I'm still considering some options for container ID: a) use a slash at the end for all containers (e.g. /users/) b) don't use a trailing slash, except for root container (/) I think option (a) is more consistent, container ID always ends with slash, although in cases like this it can be redundant. This is how the code is currently written. We can make an exception for vaultcontainer.get_dn() though. Option (b) will require more careful coding in many places (e.g. concatenations) because it needs to handle a special case for root container. Maybe a better way is to use an array of names internally and the slash is only used during input/output. The problem is when calling another command the array has to be converted into string and parsed back into array, so it may even introduce more redundancies. I don't see a way to pass an object parameter to a command. Any suggestion? > Nitpick: In vaultcontainer.get_dn, prefer the if statement over the > if-else expressions; it's a bit longer but more readable. Fixed. > In vaultcontainer.get_id, what's the purpose of the len() check? Did you > want dn.endswith() instead? Yes, but my assumption is the DN will always be within the namespace because it's only used internally, and using len() will be faster than endswith(). The error case will never happen, but I was just making sure there won't be an infinite loop. Maybe instead of calling the method recursively I should just use a loop? That will avoid repetitive validations. > I sugggest writing doctests for the id manipulation methods (get_id, > get_private_id, ...) ? it's not always obvious what exactly they do. Do you mean sample code in docs? Is it still necessary if we have some test code? > According to the design doc, container IDs shouldn't end in '/'. If you > did that I think the manipulation would be simpler, and it could be > shared with the vault equivalents. Yeah, as mentioned above I'm still considering several options. The design may need to be adjusted. > vaultcontainer_add: You should use ldap backend directly. Calling > Commands is costly, most of the call is spent doing validation of what > here is already validated. You should add a function to recursively > create vault container using just the ldap client, and call that here > and in vault_add. Hmm.. I'm not sure if we should write a code that will duplicate everything done by the LDAPCreate class. Shouldn't server-side command-to-command invocation be relatively faster? The recursion is mainly used to create the user's private container. Note that the private container is not created by default. We only provide /users top-level container. When a user creates a private vault the command will automatically create the /users/ private container on the user's behalf. This will only happen once for each user. In most other cases the parent would already exist. Another option is to require the user or the admin to create the private container manually, but that would be less user-friendly. Another option is to check the parent container using direct LDAP search, but still do the add using vaultcontainer_add. What do you think? > You can delete a container with children; is that expected? This seems to be LDAPDelete's built-in functionality. Is there an option to disallow non-empty subtree removal? For vault purposes, when a user is removed from IPA the server will remove the user's entire private container, so the feature would actually be useful here. But probably in general we should warn the user if they are deleting a non-empty container. If there's an option in LDAPDelete we can let the user specify that option if necessary. > vault_add should complain if it does not get exactly one of data/text/in. Actually, no. The primary way to archive data is via vault_archive. The vault_add is for creating a vault, but optionally you can specify the initial data to be archived. If nothing is specified it will archive an empty string. Note that for symmetric vault the encrypted empty string can be used to enforce that the same password will be used on on subsequent archival operations. I'm trying to change vault_archive to raise an error if it's missing the input data and change vault_add to archive empty string if nothing is specified, but it doesn't work since the framework seems to be converting the empty string into None, so vault_archive can't tell if it's archiving an empty string or missing the input data. Any suggestion? > What's the difference between vault_add and vault_archive? I don't see > vault_archive in the design. Yes, that's due to a recent 'standard vault' addition. I have not added vault_archive yet to the design. The vault_archive is used to archive a generic blob of data. The vaultsecret_archive will later be used to add secrets into a JSON structure which will then be archived using the vault_archive. > It seems '/' is equivalent to '-' as far as KRA is concerned; should we > disallow '-' in container/vault names? I think so, but as I mentioned earlier I haven't look very far on attribute validations. The slashes in vault ID is converted into dashes in KRA's client key ID. KRA actually accepts slashes, but the slashes will not look pretty in REST URL because they will be URL-encoded (in case it's needed for troubleshooting KRA via browser) so I changed them to dashes. > You can specify an absolute id by starting it with a slash, but only in > --parent and not in the name itself. I think this should be possible in > the name too. Right, but I'm not sure how it will work with the IPA framework. The first command parameter is the cn (vault name). If we specify a vault ID (with slashes) there it will be entered into cn. Should we parse the ID and insert the vault name and parent ID back into keys and options variables? Which value will eventually be stored into cn in LDAP? > You can't include slashes in the name, so you always need to specify the > prefix with --parent. I don't think there's a technical reason for this > limitation. See the above explanation. What does primary_key actually mean in hierarchical structure like vault? Since cn is only unique locally, is cn a primary key? Can a virtual attribute be a primary key? > There are no tests. Right, I'll take a look at how to write tests. Is there a way to run tests without running the full build? -- Endi S. Dewata From jcholast at redhat.com Wed Nov 5 07:14:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Nov 2014 08:14:28 +0100 Subject: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults. In-Reply-To: <545904CC.6030200@redhat.com> References: <54587297.1030802@redhat.com> <545904CC.6030200@redhat.com> Message-ID: <5459CE54.9010805@redhat.com> Hi, Dne 4.11.2014 v 17:54 Endi Sukma Dewata napsal(a): > Hi, > > In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute > types to store salt and public key for vault. Are there existing > attribute types that I can use instead? I see there's an ipaPublicKey, > should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. > yes, please re-use existing attributes where possible. Honza -- Jan Cholasta From mkosek at redhat.com Wed Nov 5 08:32:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Nov 2014 09:32:53 +0100 Subject: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults. In-Reply-To: <5459CE54.9010805@redhat.com> References: <54587297.1030802@redhat.com> <545904CC.6030200@redhat.com> <5459CE54.9010805@redhat.com> Message-ID: <5459E0B5.1090807@redhat.com> On 11/05/2014 08:14 AM, Jan Cholasta wrote: > Hi, > > Dne 4.11.2014 v 17:54 Endi Sukma Dewata napsal(a): >> Hi, >> >> In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute >> types to store salt and public key for vault. Are there existing >> attribute types that I can use instead? I see there's an ipaPublicKey, >> should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. >> > > yes, please re-use existing attributes where possible. > > Honza > +1. Also, if ipaSalt/ipaEncSalt is usable outside of Vault, I would go with it, instead of adding ipaVaultSalt. Martin From jcholast at redhat.com Wed Nov 5 09:41:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Nov 2014 10:41:17 +0100 Subject: [Freeipa-devel] [PATCHES] 359-364 Coverity fixes Message-ID: <5459F0BD.6010003@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-359-Fix-possible-NULL-dereference-in-ipa-kdb.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-360-Fix-memory-leaks-in-ipa-extdom-extop.patch Type: text/x-patch Size: 1870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-361-Fix-various-bugs-in-ipa-opt-counter-and-ipa-otp-last.patch Type: text/x-patch Size: 3610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-362-Fix-memory-leak-in-ipa-pwd-extop.patch Type: text/x-patch Size: 2131 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-363-Fix-memory-leaks-in-ipa-join.patch Type: text/x-patch Size: 3449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-364-Fix-various-bugs-in-ipap11helper.patch Type: text/x-patch Size: 3922 bytes Desc: not available URL: From pviktori at redhat.com Wed Nov 5 10:06:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Nov 2014 11:06:04 +0100 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <54596E3A.9060404@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> <54501A0F.30805@redhat.com> <545871D0.5070608@redhat.com> <54590EB1.1070203@redhat.com> <54596E3A.9060404@redhat.com> Message-ID: <5459F68C.20005@redhat.com> On 11/05/2014 01:24 AM, Endi Sukma Dewata wrote: > Thanks for the review. I have some questions below. I'll post a new > patch after the issues are addressed. > > On 11/4/2014 11:36 AM, Petr Viktorin wrote: >> The new schema can go to 60basev3.ldif, no need for a new file. > > Fixed. Also removed nsContainer as suggested by Simo. > >> ipalib/plugins/user.py: Make the try: block as small as possible; maybe >> something like this: >> >> try: >> vaultcontainer_id = ... >> except errors.NotFound: >> pass >> else: >> (vaultcontainer_name, vaultcontainer_parent_id) = ... >> self.api.Command.vaultcontainer_del(...) > > Actually the command that generates the NotFound exception is the last > command. The first two commands are preparing the parameters. I moved > them before the try-block. Thanks! >> ipapython/dn.py: This change is not needed. If you have a sequence of >> RNDs you can do `DN(*seq)`. > > This is actually needed to construct a parent DN from an existing DN: > > parent_dn = DN(dn[1:]) > > Note that the parameter is an array of RDNs, not a sequence of RDNs. I > don't see an existing mechanism to get a parent DN from a DN. Without > this change it would generate an error: > > ValueError: tuple or list must be 2-valued, not > "[ipapython.dn.RDN('cn=admin'), ipapython.dn.RDN('cn=users'), > ipapython.dn.RDN('cn=vaults'), ipapython.dn.RDN('dc=idm'), > ipapython.dn.RDN('dc=lab'), ipapython.dn.RDN('dc=bos'), > ipapython.dn.RDN('dc=redhat'), ipapython.dn.RDN('dc=com')]" Right, for that you can do parent_dn = DN(*dn[1:]) (note the asterisk) >> ipalib/plugins/vault.py: >> Do not use star imports in new code; remove the line >> from ipalib.plugins.baseldap import * >> and use e.g. `baseldap.LDAPObject` instead of just `LDAPObject`. >> Hopefully the only star-imported used are the base classes? > > I found 20 star imports in the existing plugins :/ Yes, we need to fix those someday. http://www.freeipa.org/page/Coding_Best_Practices#Do_not_use_star_imports https://fedorahosted.org/freeipa/ticket/2653 > All existing plugins are actually using LDAPObject directly, not > baseldap.LDAPObject. Is there a concern doing that? I fixed the code to > do the same thing. Your choice. If there are many objects imported from a module I prefer importing the module itself, but individual names work too. >> To make translators' jobs easier, split the help text in __doc__ into >> strings that can be translated individually. >> Replace every blank line by: >> """) + _(""" > > Fixed. > >> The pattern and pattern_errmsg for the 'cn' param don't match. Which one >> is right? Shouldn't a similar check be there for parent? > > This is actually copied verbatim from user's uid. Could you give some > sample values that show the problem? These messages are misleading: $ ipa vaultcontainer-add '$$' ipa: ERROR: invalid 'container_name': may only include letters, numbers, _, -, . and $ $ ipa vaultcontainer-add -- '-myvault-' ipa: ERROR: invalid 'container_name': may only include letters, numbers, _, -, . and $ (Note that in webUI you wouldn't need the awkward quoting and `--`) > I think ideally there should be a similar check for parent, but I > haven't figured out the proper pattern yet. I think we can do this as a > later enhancement. Or maybe we should remove the validation for cn for now. Well, what are the PKI limitations on ids? Are there any best practices for the id names? I think we want to limit the names to avoid nasty surprises later; '[a-zA-Z0-9_.-]+' seems like a good set. For parent you also need the slash, otherwise use the same pattern. I think this is quite an important decision; weird names could lead to security issues. >> vaultcontainer.get_dn: Why put '/' at the end of container_id, if the >> empty string is ignored later anyway? > > I'm still considering some options for container ID: > a) use a slash at the end for all containers (e.g. /users/) > b) don't use a trailing slash, except for root container (/) > > I think option (a) is more consistent, container ID always ends with > slash, although in cases like this it can be redundant. This is how the > code is currently written. We can make an exception for > vaultcontainer.get_dn() though. > > Option (b) will require more careful coding in many places (e.g. > concatenations) because it needs to handle a special case for root > container. > > Maybe a better way is to use an array of names internally and the slash > is only used during input/output. The problem is when calling another > command the array has to be converted into string and parsed back into > array, so it may even introduce more redundancies. I don't see a way to > pass an object parameter to a command. Any suggestion? That would indeed be better. Hopefully you can avoid re-parsing and re-validating by not calling nested Commands, see below. >> Nitpick: In vaultcontainer.get_dn, prefer the if statement over the >> if-else expressions; it's a bit longer but more readable. > > Fixed. > >> In vaultcontainer.get_id, what's the purpose of the len() check? Did you >> want dn.endswith() instead? > > Yes, but my assumption is the DN will always be within the namespace > because it's only used internally, and using len() will be faster than > endswith(). The error case will never happen, but I was just making sure > there won't be an infinite loop. Maybe instead of calling the method > recursively I should just use a loop? That will avoid repetitive > validations. Well, if you end up with representing the id as a list the problem will largely go away, but: use an internal error (e.g. ValueError) for internal sanity checking. The public errors are for user errors, they are presented "nicely" which makes them much harder to debug. And "Invalid container DN" with no indication of what the DN is isn't helpful to the user either. >> I sugggest writing doctests for the id manipulation methods (get_id, >> get_private_id, ...) ? it's not always obvious what exactly they do. > > Do you mean sample code in docs? Is it still necessary if we have some > test code? Not strictly necessary, but it better explains what the method does. >> According to the design doc, container IDs shouldn't end in '/'. If you >> did that I think the manipulation would be simpler, and it could be >> shared with the vault equivalents. > > Yeah, as mentioned above I'm still considering several options. The > design may need to be adjusted. > >> vaultcontainer_add: You should use ldap backend directly. Calling >> Commands is costly, most of the call is spent doing validation of what >> here is already validated. You should add a function to recursively >> create vault container using just the ldap client, and call that here >> and in vault_add. > > Hmm.. I'm not sure if we should write a code that will duplicate > everything done by the LDAPCreate class. Shouldn't server-side > command-to-command invocation be relatively faster? But you don't everything done by LDAPCreate. Most of what it does is parsing options, validating options, formatting output. You don't even use the added entry, after LDAPCreate spends an additional LDAP call to re-retreive it after adding. Commands are not really designed to be nested, and tend to have subtle assumptions of "owning" the current thread. Not to mention that debugging nested Command calls is a nightmare. Imagine calling your own vault_retrieve from an unrelated command, and getting a "Data not found." error, formatted for user consumption (e.g. no traceback). (Yes, some parts of IPA do currently call nested commands. This is unfortunate and leads to hard-to-debug issues.) > The recursion is mainly used to create the user's private container. > Note that the private container is not created by default. We only > provide /users top-level container. When a user creates a private vault > the command will automatically create the /users/ private > container on the user's behalf. This will only happen once for each > user. In most other cases the parent would already exist. > > Another option is to require the user or the admin to create the private > container manually, but that would be less user-friendly. > > Another option is to check the parent container using direct LDAP > search, but still do the add using vaultcontainer_add. What do you think? Why? Is adding the entry via ldap that hard to do? What functionality from LDAPCreate do you need? Maybe we can pull it out into a function. >> You can delete a container with children; is that expected? > > This seems to be LDAPDelete's built-in functionality. Is there an option > to disallow non-empty subtree removal? > > For vault purposes, when a user is removed from IPA the server will > remove the user's entire private container, so the feature would > actually be useful here. But probably in general we should warn the user > if they are deleting a non-empty container. If there's an option in > LDAPDelete we can let the user specify that option if necessary. A warning doesn't seem very useful. ("Yes sir, deleted your data! Oh, by the way, did you really want to do that?") I think requiring a --force or --recursive option for non-empty trees could better prevent surprises. >> vault_add should complain if it does not get exactly one of data/text/in. > > Actually, no. The primary way to archive data is via vault_archive. The > vault_add is for creating a vault, but optionally you can specify the > initial data to be archived. If nothing is specified it will archive an > empty string. Note that for symmetric vault the encrypted empty string > can be used to enforce that the same password will be used on on > subsequent archival operations. Then the command should complain if is gets more than one type of input. It still seems redundant to me. If I'm getting it correctly, to change a vault's attributes like description, you need vault_mod, but to change the stored secret you do vault_archive. Is that right? Why not do all modifications in vault_mod? And if you do end up needing separate commands, you can pull the communication with KRA into a function and call that, rather than calling the whole Command machinery. > I'm trying to change vault_archive to raise an error if it's missing the > input data and change vault_add to archive empty string if nothing is > specified, but it doesn't work since the framework seems to be > converting the empty string into None, so vault_archive can't tell if > it's archiving an empty string or missing the input data. Any suggestion? > >> What's the difference between vault_add and vault_archive? I don't see >> vault_archive in the design. > > Yes, that's due to a recent 'standard vault' addition. I have not added > vault_archive yet to the design. The vault_archive is used to archive a > generic blob of data. The vaultsecret_archive will later be used to add > secrets into a JSON structure which will then be archived using the > vault_archive. Okay. I'm not sure I get the details right, a design would help. >> It seems '/' is equivalent to '-' as far as KRA is concerned; should we >> disallow '-' in container/vault names? > > I think so, but as I mentioned earlier I haven't look very far on > attribute validations. > > The slashes in vault ID is converted into dashes in KRA's client key ID. > KRA actually accepts slashes, but the slashes will not look pretty in > REST URL because they will be URL-encoded (in case it's needed for > troubleshooting KRA via browser) so I changed them to dashes. So it seems that these IDs would be equivalent for the KRA: /users/admin/private/secret /users/admin-private/secret If this is just for troubleshooting purposes, please don't change to dashes. >> You can specify an absolute id by starting it with a slash, but only in >> --parent and not in the name itself. I think this should be possible in >> the name too. > > Right, but I'm not sure how it will work with the IPA framework. The > first command parameter is the cn (vault name). If we specify a vault ID > (with slashes) there it will be entered into cn. Should we parse the ID > and insert the vault name and parent ID back into keys and options > variables? Which value will eventually be stored into cn in LDAP? You're right, managing that would need some delicate coding. But I you could override args_options_2_params to adjust the options before they're even validated, so the framework gets cn and parent as it does currently. >> You can't include slashes in the name, so you always need to specify the >> prefix with --parent. I don't think there's a technical reason for this >> limitation. > > See the above explanation. What does primary_key actually mean in > hierarchical structure like vault? Since cn is only unique locally, is > cn a primary key? Can a virtual attribute be a primary key? > >> There are no tests. > > Right, I'll take a look at how to write tests. Is there a way to run > tests without running the full build? Yes, see http://www.freeipa.org/page/Testing (Though I usually just copy changed files to /usr/lib/ and restart Apache) -- Petr? From abokovoy at redhat.com Wed Nov 5 10:27:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 12:27:46 +0200 Subject: [Freeipa-devel] [PATCHES] 359-364 Coverity fixes In-Reply-To: <5459F0BD.6010003@redhat.com> References: <5459F0BD.6010003@redhat.com> Message-ID: <20141105102746.GE4107@redhat.com> On Wed, 05 Nov 2014, Jan Cholasta wrote: > Hi, > > the attached patches fix . > Thanks. ACK to all patches. -- / Alexander Bokovoy From pspacek at redhat.com Wed Nov 5 13:27:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Nov 2014 14:27:49 +0100 Subject: [Freeipa-devel] [PATCH] 357 Added symmetric and asymmetric vaults. In-Reply-To: <5459E0B5.1090807@redhat.com> References: <54587297.1030802@redhat.com> <545904CC.6030200@redhat.com> <5459CE54.9010805@redhat.com> <5459E0B5.1090807@redhat.com> Message-ID: <545A25D5.7020704@redhat.com> On 5.11.2014 09:32, Martin Kosek wrote: > On 11/05/2014 08:14 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 4.11.2014 v 17:54 Endi Sukma Dewata napsal(a): >>> Hi, >>> >>> In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute >>> types to store salt and public key for vault. Are there existing >>> attribute types that I can use instead? I see there's an ipaPublicKey, >>> should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. >>> >> >> yes, please re-use existing attributes where possible. >> >> Honza >> > > +1. Also, if ipaSalt/ipaEncSalt is usable outside of Vault, I would go with it, > instead of adding ipaVaultSalt. Existing schema including ipaPublicKey attribute is described on: http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema Please note that there are defined data formats too, not only OIDs. -- Petr^2 Spacek From abokovoy at redhat.com Wed Nov 5 14:19:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 16:19:38 +0200 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <54524168.8040108@redhat.com> References: <54524168.8040108@redhat.com> Message-ID: <20141105141938.GI4107@redhat.com> On Thu, 30 Oct 2014, thierry bordaz wrote: >https://fedorahosted.org/freeipa/ticket/4635 > >From 0a72220fc2b8af160b20085f372ab55d997546b4 Mon Sep 17 00:00:00 2001 >From: "Thierry bordaz (tbordaz)" >Date: Wed, 29 Oct 2014 16:23:03 +0100 >Subject: [PATCH] Deadlock in schema compat plugin (between > automember_update_membership task and dse update) > > Defining schema-compat-ignore-subtree values for schema compat plugin config entries removes the > default value (ignore: cn=tasks,cn=config). This default value prevented deadlocks. > Schema plugin needs to scope the $SUFFIX and also any updates to its configuration. > This change restrict the schema compat to those subtrees. It replaces the definition of ignored subtrees > that would be too long for cn=config (tasks, mapping tree, replication, snmp..) > >https://fedorahosted.org/freeipa/ticket/4635 >--- > install/updates/10-schema_compat.update | 30 ++++++++++++++++++++---------- > 1 file changed, 20 insertions(+), 10 deletions(-) > >diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update >index 7b75ba532612bbdaf9c85f8c88b0c8b8454e5969..b8c79012d121116f9cf53908fbe4eeeebe9d3d82 100644 >--- a/install/updates/10-schema_compat.update >+++ b/install/updates/10-schema_compat.update >@@ -18,15 +18,19 @@ add: schema-compat-entry-attribute: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCatego > add: schema-compat-entry-attribute: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")")' > add: schema-compat-entry-attribute: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")' > add: schema-compat-entry-attribute: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")")' >-add: schema-compat-ignore-subtree: cn=changelog >-add: schema-compat-ignore-subtree: o=ipaca >+remove: schema-compat-ignore-subtree: cn=changelog >+remove: schema-compat-ignore-subtree: o=ipaca >+add: schema-compat-restrict-subtree: '$SUFFIX' >+add: schema-compat-restrict-subtree: 'cn=Schema Compatibility,cn=plugins,cn=config' > > # Change padding for host and userCategory so the pad returns the same value > # as the original, '' or -. > dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config > replace: schema-compat-entry-attribute:'nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-})::nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","%ifeq(\"hostCategory\",\"all\",\"\",\"-\")",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","%ifeq(\"userCategory\",\"all\",\"\",\"-\")"),%{nisDomainName:-})' >-add: schema-compat-ignore-subtree: cn=changelog >-add: schema-compat-ignore-subtree: o=ipaca >+remove: schema-compat-ignore-subtree: cn=changelog >+remove: schema-compat-ignore-subtree: o=ipaca >+add: schema-compat-restrict-subtree: '$SUFFIX' >+add: schema-compat-restrict-subtree: 'cn=Schema Compatibility,cn=plugins,cn=config' > > dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config > default:objectClass: top >@@ -41,19 +45,25 @@ default:schema-compat-entry-attribute: objectclass=device > default:schema-compat-entry-attribute: objectclass=ieee802Device > default:schema-compat-entry-attribute: cn=%{fqdn} > default:schema-compat-entry-attribute: macAddress=%{macAddress} >-add: schema-compat-ignore-subtree: cn=changelog >-add: schema-compat-ignore-subtree: o=ipaca >+remove: schema-compat-ignore-subtree: cn=changelog >+remove: schema-compat-ignore-subtree: o=ipaca >+add: schema-compat-restrict-subtree: '$SUFFIX' >+add: schema-compat-restrict-subtree: 'cn=Schema Compatibility,cn=plugins,cn=config' > > dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config > add:schema-compat-entry-attribute: sudoOrder=%{sudoOrder} > > dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >-add: schema-compat-ignore-subtree: cn=changelog >-add: schema-compat-ignore-subtree: o=ipaca >+remove: schema-compat-ignore-subtree: cn=changelog >+remove: schema-compat-ignore-subtree: o=ipaca >+add: schema-compat-restrict-subtree: '$SUFFIX' >+add: schema-compat-restrict-subtree: 'cn=Schema Compatibility,cn=plugins,cn=config' > > dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >-add: schema-compat-ignore-subtree: cn=changelog >-add: schema-compat-ignore-subtree: o=ipaca >+remove: schema-compat-ignore-subtree: cn=changelog >+remove: schema-compat-ignore-subtree: o=ipaca >+add: schema-compat-restrict-subtree: '$SUFFIX' >+add: schema-compat-restrict-subtree: 'cn=Schema Compatibility,cn=plugins,cn=config' > > dn: cn=Schema Compatibility,cn=plugins,cn=config > # We need to run schema-compat pre-bind callback before Conditional ACK -- did you check upgrades from 3.3 version? -- / Alexander Bokovoy From mkosek at redhat.com Wed Nov 5 14:26:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Nov 2014 15:26:09 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <54577D6D.3020806@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> <54511472.5010004@redhat.com> <545207FA.1040407@redhat.com> <54574AC6.9040005@redhat.com> <54577D6D.3020806@redhat.com> Message-ID: <545A3381.7040200@redhat.com> On 11/03/2014 02:04 PM, Martin Basti wrote: > On 03/11/14 10:28, David Kupka wrote: >> On 10/30/2014 10:42 AM, Martin Basti wrote: >>> On 29/10/14 17:23, David Kupka wrote: >>>> On 10/29/2014 02:34 PM, David Kupka wrote: >>>>> On 10/24/2014 03:05 PM, David Kupka wrote: >>>>>> On 10/24/2014 01:06 PM, David Kupka wrote: >>>>>>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>>>>>> On 24/10/14 09:51, David Kupka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>>>>>> NACK >>>>>>>> >>>>>>>> 1) >>>>>>>> Why is there line with 'DS System User?' The comment should depend on >>>>>>>> service. >>>>>>>> >>>>>>>> + args = [ >>>>>>>> + paths.USERADD, >>>>>>>> + '-g', group, >>>>>>>> + '-c', 'DS System User', >>>>>>>> + '-d', homedir, >>>>>>>> + '-s', shell, >>>>>>>> + '-M', '-r', name, >>>>>>>> + ] >>>>>>> >>>>>>> This was part of the original code and I didn't notice it. Nice catch, >>>>>>> thanks. >>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> code create_system_user is duplicated between base and redhat tasks >>>>>>>> with >>>>>>>> platform dependent changes. >>>>>>>> IMO it would be better to have one method to create user, with >>>>>>>> keyword >>>>>>>> arguments. And then platform dependent method which will call >>>>>>>> method to >>>>>>>> create user with appropriate arguments (or with default arguments) >>>>>>>> >>>>>>> >>>>>>> You're right it was ugly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> I shouldn't break SOLID principles. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> Using super is probably better that explicit naming of parent class. >>>>> Let user (developer) override UID/GID and hope that he knows why ... >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>> >>> >>> In your former patch you had pki homedir path VAR_LIB_PKI_DIR : >>> >>> + if name == 'pkiuser': >>> + uid = 17 >>> + gid = 17 >>> + homedir = paths.VAR_LIB_PKI_DIR >>> + shell = paths.NOLOGIN >>> + comment = 'CA System User' >>> >>> in last patch you change it back to: >>> >>> homedir=paths.VAR_LIB, >>> >>> so what is the correct path? >>> >> >> The setup package (soft static allocation) claims that pkiuser should use >> '/usr/share/pki' as home directory. Since pkiuser has /sbin/nologin set as a >> login shell it's unable to login and does't need home directory at all. >> We could use '--system' option of useradd utility to skip home directory >> creation or change to proposed value or just leave the old value and all will >> result in no change in behavior. >> I'm not sure if the '--system' option is available universally. IIRC it used >> to be Red Hat-like-systems specific extension. >> > > ACK Pushed to: master: 364d466fd7def3589ddb9e4a9f8d73fc2df80439 ipa-4-1: 71c24b187a8d4b8990c0899d2c907d600b7bcc21 Martin From mkosek at redhat.com Wed Nov 5 14:27:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Nov 2014 15:27:24 +0100 Subject: [Freeipa-devel] [PATCH] 335 Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage In-Reply-To: <545798BF.803@redhat.com> References: <543E8827.5070402@redhat.com> <545798BF.803@redhat.com> Message-ID: <545A33CC.8010903@redhat.com> On 11/03/2014 04:01 PM, David Kupka wrote: > On 10/15/2014 04:43 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> It depends on my patches 333 and 334, which are also attached. >> >> (The original patch was posted at >> .) >> >> >> How to test: >> >> 1. install server >> >> 2. kinit as admin >> >> 3. run "ipa-cacert-manage renew --external-ca", it will produce a CSR >> >> 4. sign the CSR with some external CA to get new IPA CA certificate >> >> 5. run "while true; do ldapdelete -H ldap://$HOSTNAME -Y GSSAPI >> 'cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,'; >> done" in background >> >> 6. run "ipa-cacert-manage renew --external-cert-file=> CA certificate> --external-cert-file=> chain>" >> >> 7. stop the loop from step 5 >> >> 8. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert >> cert-pki-ca'", the request should be in MONITORING state, there should >> be no ca-error >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > > Works for me, ACK. > > Please push only the patch freeipa-jcholast-335. Patches freeipa-jcholast-333 > and freeipa-jcholast-334 was pushed earlier. > Pushed to: master: 2cf0f0a658ba3151596e3782c76d6273362080cf ipa-4-1: 59af17d5e42ee50b000b18f6e420cf26737d055d Martin From mkosek at redhat.com Wed Nov 5 14:35:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Nov 2014 15:35:44 +0100 Subject: [Freeipa-devel] [PATCHES] 359-364 Coverity fixes In-Reply-To: <20141105102746.GE4107@redhat.com> References: <5459F0BD.6010003@redhat.com> <20141105102746.GE4107@redhat.com> Message-ID: <545A35C0.8040401@redhat.com> On 11/05/2014 11:27 AM, Alexander Bokovoy wrote: > On Wed, 05 Nov 2014, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> > Thanks. ACK to all patches. > Pushed to: master: 4589ef133c3abf47568d6cda4eda726f316a475a ipa-4-1: 1cc27f9c68266fe0463660fe2244760e9b4444f3 Martin From tbordaz at redhat.com Wed Nov 5 14:37:44 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 05 Nov 2014 15:37:44 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <20141105141938.GI4107@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> Message-ID: <545A3638.3080507@redhat.com> On 11/05/2014 03:19 PM, Alexander Bokovoy wrote: > On Thu, 30 Oct 2014, thierry bordaz wrote: >> https://fedorahosted.org/freeipa/ticket/4635 >> > >> From 0a72220fc2b8af160b20085f372ab55d997546b4 Mon Sep 17 00:00:00 2001 >> From: "Thierry bordaz (tbordaz)" >> Date: Wed, 29 Oct 2014 16:23:03 +0100 >> Subject: [PATCH] Deadlock in schema compat plugin (between >> automember_update_membership task and dse update) >> >> Defining schema-compat-ignore-subtree values for schema compat >> plugin config entries removes the >> default value (ignore: cn=tasks,cn=config). This default value >> prevented deadlocks. >> Schema plugin needs to scope the $SUFFIX and also any updates to >> its configuration. >> This change restrict the schema compat to those subtrees. It >> replaces the definition of ignored subtrees >> that would be too long for cn=config (tasks, mapping tree, >> replication, snmp..) >> >> https://fedorahosted.org/freeipa/ticket/4635 >> --- >> install/updates/10-schema_compat.update | 30 >> ++++++++++++++++++++---------- >> 1 file changed, 20 insertions(+), 10 deletions(-) >> >> diff --git a/install/updates/10-schema_compat.update >> b/install/updates/10-schema_compat.update >> index >> 7b75ba532612bbdaf9c85f8c88b0c8b8454e5969..b8c79012d121116f9cf53908fbe4eeeebe9d3d82 >> 100644 >> --- a/install/updates/10-schema_compat.update >> +++ b/install/updates/10-schema_compat.update >> @@ -18,15 +18,19 @@ add: schema-compat-entry-attribute: >> 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCatego >> add: schema-compat-entry-attribute: >> 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")")' >> add: schema-compat-entry-attribute: >> 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")' >> add: schema-compat-entry-attribute: >> 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")")' >> -add: schema-compat-ignore-subtree: cn=changelog >> -add: schema-compat-ignore-subtree: o=ipaca >> +remove: schema-compat-ignore-subtree: cn=changelog >> +remove: schema-compat-ignore-subtree: o=ipaca >> +add: schema-compat-restrict-subtree: '$SUFFIX' >> +add: schema-compat-restrict-subtree: 'cn=Schema >> Compatibility,cn=plugins,cn=config' >> >> # Change padding for host and userCategory so the pad returns the >> same value >> # as the original, '' or -. >> dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config >> replace: >> schema-compat-entry-attribute:'nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-})::nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","%ifeq(\"hostCategory\",\"all\",\"\",\"-\")",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","%ifeq(\"userCategory\",\"all\",\"\",\"-\")"),%{nisDomainName:-})' >> -add: schema-compat-ignore-subtree: cn=changelog >> -add: schema-compat-ignore-subtree: o=ipaca >> +remove: schema-compat-ignore-subtree: cn=changelog >> +remove: schema-compat-ignore-subtree: o=ipaca >> +add: schema-compat-restrict-subtree: '$SUFFIX' >> +add: schema-compat-restrict-subtree: 'cn=Schema >> Compatibility,cn=plugins,cn=config' >> >> dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config >> default:objectClass: top >> @@ -41,19 +45,25 @@ default:schema-compat-entry-attribute: >> objectclass=device >> default:schema-compat-entry-attribute: objectclass=ieee802Device >> default:schema-compat-entry-attribute: cn=%{fqdn} >> default:schema-compat-entry-attribute: macAddress=%{macAddress} >> -add: schema-compat-ignore-subtree: cn=changelog >> -add: schema-compat-ignore-subtree: o=ipaca >> +remove: schema-compat-ignore-subtree: cn=changelog >> +remove: schema-compat-ignore-subtree: o=ipaca >> +add: schema-compat-restrict-subtree: '$SUFFIX' >> +add: schema-compat-restrict-subtree: 'cn=Schema >> Compatibility,cn=plugins,cn=config' >> >> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config >> add:schema-compat-entry-attribute: sudoOrder=%{sudoOrder} >> >> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >> -add: schema-compat-ignore-subtree: cn=changelog >> -add: schema-compat-ignore-subtree: o=ipaca >> +remove: schema-compat-ignore-subtree: cn=changelog >> +remove: schema-compat-ignore-subtree: o=ipaca >> +add: schema-compat-restrict-subtree: '$SUFFIX' >> +add: schema-compat-restrict-subtree: 'cn=Schema >> Compatibility,cn=plugins,cn=config' >> >> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >> -add: schema-compat-ignore-subtree: cn=changelog >> -add: schema-compat-ignore-subtree: o=ipaca >> +remove: schema-compat-ignore-subtree: cn=changelog >> +remove: schema-compat-ignore-subtree: o=ipaca >> +add: schema-compat-restrict-subtree: '$SUFFIX' >> +add: schema-compat-restrict-subtree: 'cn=Schema >> Compatibility,cn=plugins,cn=config' >> >> dn: cn=Schema Compatibility,cn=plugins,cn=config >> # We need to run schema-compat pre-bind callback before > > Conditional ACK -- did you check upgrades from 3.3 version? > No I did not. I will do it :) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 5 14:47:53 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 05 Nov 2014 15:47:53 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <545A3638.3080507@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> Message-ID: <545A3899.4070802@redhat.com> On 05/11/14 15:37, thierry bordaz wrote: > On 11/05/2014 03:19 PM, Alexander Bokovoy wrote: >> On Thu, 30 Oct 2014, thierry bordaz wrote: >>> https://fedorahosted.org/freeipa/ticket/4635 >>> >> >>> From 0a72220fc2b8af160b20085f372ab55d997546b4 Mon Sep 17 00:00:00 2001 >>> From: "Thierry bordaz (tbordaz)" >>> Date: Wed, 29 Oct 2014 16:23:03 +0100 >>> Subject: [PATCH] Deadlock in schema compat plugin (between >>> automember_update_membership task and dse update) >>> >>> Defining schema-compat-ignore-subtree values for schema compat >>> plugin config entries removes the >>> default value (ignore: cn=tasks,cn=config). This default value >>> prevented deadlocks. >>> Schema plugin needs to scope the $SUFFIX and also any updates to >>> its configuration. >>> This change restrict the schema compat to those subtrees. It >>> replaces the definition of ignored subtrees >>> that would be too long for cn=config (tasks, mapping tree, >>> replication, snmp..) >>> >>> https://fedorahosted.org/freeipa/ticket/4635 >>> --- >>> install/updates/10-schema_compat.update | 30 >>> ++++++++++++++++++++---------- >>> 1 file changed, 20 insertions(+), 10 deletions(-) >>> >>> diff --git a/install/updates/10-schema_compat.update >>> b/install/updates/10-schema_compat.update >>> index >>> 7b75ba532612bbdaf9c85f8c88b0c8b8454e5969..b8c79012d121116f9cf53908fbe4eeeebe9d3d82 >>> 100644 >>> --- a/install/updates/10-schema_compat.update >>> +++ b/install/updates/10-schema_compat.update >>> @@ -18,15 +18,19 @@ add: schema-compat-entry-attribute: >>> 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCatego >>> add: schema-compat-entry-attribute: >>> 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")")' >>> add: schema-compat-entry-attribute: >>> 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")' >>> add: schema-compat-entry-attribute: >>> 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")")' >>> -add: schema-compat-ignore-subtree: cn=changelog >>> -add: schema-compat-ignore-subtree: o=ipaca >>> +remove: schema-compat-ignore-subtree: cn=changelog >>> +remove: schema-compat-ignore-subtree: o=ipaca >>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>> +add: schema-compat-restrict-subtree: 'cn=Schema >>> Compatibility,cn=plugins,cn=config' >>> >>> # Change padding for host and userCategory so the pad returns the >>> same value >>> # as the original, '' or -. >>> dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config >>> replace: >>> schema-compat-entry-attribute:'nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-})::nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","%ifeq(\"hostCategory\",\! >>> "all\",\"\ >>> ",\"-\")",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","%ifeq(\"userCategory\",\"all\",\"\",\"-\")"),%{nisDomainName:-})' >>> -add: schema-compat-ignore-subtree: cn=changelog >>> -add: schema-compat-ignore-subtree: o=ipaca >>> +remove: schema-compat-ignore-subtree: cn=changelog >>> +remove: schema-compat-ignore-subtree: o=ipaca >>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>> +add: schema-compat-restrict-subtree: 'cn=Schema >>> Compatibility,cn=plugins,cn=config' >>> >>> dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config >>> default:objectClass: top >>> @@ -41,19 +45,25 @@ default:schema-compat-entry-attribute: >>> objectclass=device >>> default:schema-compat-entry-attribute: objectclass=ieee802Device >>> default:schema-compat-entry-attribute: cn=%{fqdn} >>> default:schema-compat-entry-attribute: macAddress=%{macAddress} >>> -add: schema-compat-ignore-subtree: cn=changelog >>> -add: schema-compat-ignore-subtree: o=ipaca >>> +remove: schema-compat-ignore-subtree: cn=changelog >>> +remove: schema-compat-ignore-subtree: o=ipaca >>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>> +add: schema-compat-restrict-subtree: 'cn=Schema >>> Compatibility,cn=plugins,cn=config' >>> >>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config >>> add:schema-compat-entry-attribute: sudoOrder=%{sudoOrder} >>> >>> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>> -add: schema-compat-ignore-subtree: cn=changelog >>> -add: schema-compat-ignore-subtree: o=ipaca >>> +remove: schema-compat-ignore-subtree: cn=changelog >>> +remove: schema-compat-ignore-subtree: o=ipaca >>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>> +add: schema-compat-restrict-subtree: 'cn=Schema >>> Compatibility,cn=plugins,cn=config' >>> >>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >>> -add: schema-compat-ignore-subtree: cn=changelog >>> -add: schema-compat-ignore-subtree: o=ipaca >>> +remove: schema-compat-ignore-subtree: cn=changelog >>> +remove: schema-compat-ignore-subtree: o=ipaca >>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>> +add: schema-compat-restrict-subtree: 'cn=Schema >>> Compatibility,cn=plugins,cn=config' >>> >>> dn: cn=Schema Compatibility,cn=plugins,cn=config >>> # We need to run schema-compat pre-bind callback before >> >> Conditional ACK -- did you check upgrades from 3.3 version? >> > I did upgrade from 3.3.5 to 4.1 and it worked -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Nov 5 20:11:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 22:11:16 +0200 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <545A3899.4070802@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> <545A3899.4070802@redhat.com> Message-ID: <20141105201116.GL4107@redhat.com> On Wed, 05 Nov 2014, Martin Basti wrote: >>>>+remove: schema-compat-ignore-subtree: o=ipaca >>>>+add: schema-compat-restrict-subtree: '$SUFFIX' >>>>+add: schema-compat-restrict-subtree: 'cn=Schema >>>>Compatibility,cn=plugins,cn=config' >>>> >>>>dn: cn=Schema Compatibility,cn=plugins,cn=config >>>># We need to run schema-compat pre-bind callback before >>> >>>Conditional ACK -- did you check upgrades from 3.3 version? >>> >> >I did upgrade from 3.3.5 to 4.1 and it worked ACK. -- / Alexander Bokovoy From npmccallum at redhat.com Wed Nov 5 20:14:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 05 Nov 2014 15:14:09 -0500 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation Message-ID: <1415218449.7177.14.camel@redhat.com> Before this patch users could log in using only the OTP value. This arose because ipapwd_authentication() successfully determined that an empty password was invalid, but 389 itself would see this as an anonymous bind. An anonymous bind would never even get this far in this code, so we simply deny requests with empty passwords. This patch resolves CVE-2014-7828. https://fedorahosted.org/freeipa/ticket/4690 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0076-Ensure-that-a-password-exists-after-OTP-validation.patch Type: text/x-patch Size: 2650 bytes Desc: not available URL: From abokovoy at redhat.com Wed Nov 5 20:22:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 22:22:16 +0200 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <1415218449.7177.14.camel@redhat.com> References: <1415218449.7177.14.camel@redhat.com> Message-ID: <20141105202216.GM4107@redhat.com> On Wed, 05 Nov 2014, Nathaniel McCallum wrote: >Before this patch users could log in using only the OTP value. This >arose because ipapwd_authentication() successfully determined that >an empty password was invalid, but 389 itself would see this as an >anonymous bind. An anonymous bind would never even get this far in >this code, so we simply deny requests with empty passwords. > >This patch resolves CVE-2014-7828. > >https://fedorahosted.org/freeipa/ticket/4690 ACK. We need to do release for 4.0 and 4.1 first thing tomorrow. A possible workaround is to disable 2FA for users in mean time. -- / Alexander Bokovoy From ssorce at redhat.com Wed Nov 5 20:31:07 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 5 Nov 2014 15:31:07 -0500 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <20141105202216.GM4107@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <20141105202216.GM4107@redhat.com> Message-ID: <20141105153107.7722ca51@willson.usersys.redhat.com> On Wed, 5 Nov 2014 22:22:16 +0200 Alexander Bokovoy wrote: > On Wed, 05 Nov 2014, Nathaniel McCallum wrote: > >Before this patch users could log in using only the OTP value. This > >arose because ipapwd_authentication() successfully determined that > >an empty password was invalid, but 389 itself would see this as an > >anonymous bind. An anonymous bind would never even get this far in > >this code, so we simply deny requests with empty passwords. > > > >This patch resolves CVE-2014-7828. > > > >https://fedorahosted.org/freeipa/ticket/4690 > ACK. Code sounds good, but I haven't tested it. > We need to do release for 4.0 and 4.1 first thing tomorrow. Yes. > A possible workaround is to disable 2FA for users in mean time. We should send a warning to freeipa-users mailing list that we are preparing a release and they should consider disabling 2FA ion the meanwhile if they are using it. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Nov 5 20:45:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Nov 2014 22:45:27 +0200 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <20141105153107.7722ca51@willson.usersys.redhat.com> References: <1415218449.7177.14.camel@redhat.com> <20141105202216.GM4107@redhat.com> <20141105153107.7722ca51@willson.usersys.redhat.com> Message-ID: <20141105204527.GP4107@redhat.com> On Wed, 05 Nov 2014, Simo Sorce wrote: >On Wed, 5 Nov 2014 22:22:16 +0200 >Alexander Bokovoy wrote: > >> On Wed, 05 Nov 2014, Nathaniel McCallum wrote: >> >Before this patch users could log in using only the OTP value. This >> >arose because ipapwd_authentication() successfully determined that >> >an empty password was invalid, but 389 itself would see this as an >> >anonymous bind. An anonymous bind would never even get this far in >> >this code, so we simply deny requests with empty passwords. >> > >> >This patch resolves CVE-2014-7828. >> > >> >https://fedorahosted.org/freeipa/ticket/4690 >> ACK. > >Code sounds good, but I haven't tested it. > >> We need to do release for 4.0 and 4.1 first thing tomorrow. > >Yes. > >> A possible workaround is to disable 2FA for users in mean time. > >We should send a warning to freeipa-users mailing list that we are >preparing a release and they should consider disabling 2FA ion the >meanwhile if they are using it. Done. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Nov 6 08:40:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 09:40:08 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <20141105201116.GL4107@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> <545A3899.4070802@redhat.com> <20141105201116.GL4107@redhat.com> Message-ID: <545B33E8.9000205@redhat.com> On 5.11.2014 21:11, Alexander Bokovoy wrote: > On Wed, 05 Nov 2014, Martin Basti wrote: >>>>> +remove: schema-compat-ignore-subtree: o=ipaca >>>>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>>>> +add: schema-compat-restrict-subtree: 'cn=Schema >>>>> Compatibility,cn=plugins,cn=config' >>>>> >>>>> dn: cn=Schema Compatibility,cn=plugins,cn=config >>>>> # We need to run schema-compat pre-bind callback before >>>> >>>> Conditional ACK -- did you check upgrades from 3.3 version? >>>> >>> >> I did upgrade from 3.3.5 to 4.1 and it worked > ACK. Pushed to: master: 85eb17553f46bfb4446279037e324f825d3389bd ipa-4-1: f0bcf2b29553003af3e5dd35fb6c73752fc95e21 -- Petr Vobornik From tbordaz at redhat.com Thu Nov 6 09:27:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 06 Nov 2014 10:27:39 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <545B33E8.9000205@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> <545A3899.4070802@redhat.com> <20141105201116.GL4107@redhat.com> <545B33E8.9000205@redhat.com> Message-ID: <545B3F0B.3030504@redhat.com> On 11/06/2014 09:40 AM, Petr Vobornik wrote: > On 5.11.2014 21:11, Alexander Bokovoy wrote: >> On Wed, 05 Nov 2014, Martin Basti wrote: >>>>>> +remove: schema-compat-ignore-subtree: o=ipaca >>>>>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>>>>> +add: schema-compat-restrict-subtree: 'cn=Schema >>>>>> Compatibility,cn=plugins,cn=config' >>>>>> >>>>>> dn: cn=Schema Compatibility,cn=plugins,cn=config >>>>>> # We need to run schema-compat pre-bind callback before >>>>> >>>>> Conditional ACK -- did you check upgrades from 3.3 version? >>>>> >>>> >>> I did upgrade from 3.3.5 to 4.1 and it worked >> ACK. > > Pushed to: > master: 85eb17553f46bfb4446279037e324f825d3389bd > ipa-4-1: f0bcf2b29553003af3e5dd35fb6c73752fc95e21 Hello, Just curious, this deadlock also exists in ipa-4-0. Is it planed to backport it into that branch ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Nov 6 09:32:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Nov 2014 10:32:50 +0100 Subject: [Freeipa-devel] [PATCH] 0026 Stop dirsrv last in ipactl stop. In-Reply-To: <5458BF0E.7070403@redhat.com> References: <5458BF0E.7070403@redhat.com> Message-ID: <545B4042.5030005@redhat.com> Hi, Dne 4.11.2014 v 12:57 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4632 Thanks, ACK. Honza -- Jan Cholasta From abokovoy at redhat.com Thu Nov 6 09:41:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 11:41:20 +0200 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <545B3F0B.3030504@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> <545A3899.4070802@redhat.com> <20141105201116.GL4107@redhat.com> <545B33E8.9000205@redhat.com> <545B3F0B.3030504@redhat.com> Message-ID: <20141106094120.GT4107@redhat.com> On Thu, 06 Nov 2014, thierry bordaz wrote: >On 11/06/2014 09:40 AM, Petr Vobornik wrote: >>On 5.11.2014 21:11, Alexander Bokovoy wrote: >>>On Wed, 05 Nov 2014, Martin Basti wrote: >>>>>>>+remove: schema-compat-ignore-subtree: o=ipaca >>>>>>>+add: schema-compat-restrict-subtree: '$SUFFIX' >>>>>>>+add: schema-compat-restrict-subtree: 'cn=Schema >>>>>>>Compatibility,cn=plugins,cn=config' >>>>>>> >>>>>>>dn: cn=Schema Compatibility,cn=plugins,cn=config >>>>>>># We need to run schema-compat pre-bind callback before >>>>>> >>>>>>Conditional ACK -- did you check upgrades from 3.3 version? >>>>>> >>>>> >>>>I did upgrade from 3.3.5 to 4.1 and it worked >>>ACK. >> >>Pushed to: >>master: 85eb17553f46bfb4446279037e324f825d3389bd >>ipa-4-1: f0bcf2b29553003af3e5dd35fb6c73752fc95e21 >Hello, > > Just curious, this deadlock also exists in ipa-4-0. Is it planed to > backport it into that branch ? It applies fine to 4.0, I think we can add it there as well. -- / Alexander Bokovoy From jcholast at redhat.com Thu Nov 6 09:42:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Nov 2014 10:42:24 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS In-Reply-To: <5458F0DF.7070709@redhat.com> References: <5458EBEE.4050803@redhat.com> <5458F0DF.7070709@redhat.com> Message-ID: <545B4280.7050405@redhat.com> Hi, Dne 4.11.2014 v 16:29 Martin Basti napsal(a): > On 04/11/14 16:08, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4670 >> >> Patch attached >> >> > I forgot to mention, this is an ancient bug, IMO the fix should go to > all branches. > Thanks, ACK. Honza -- Jan Cholasta From pvoborni at redhat.com Thu Nov 6 09:43:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 10:43:47 +0100 Subject: [Freeipa-devel] [PATCH] 0026 Stop dirsrv last in ipactl stop. In-Reply-To: <545B4042.5030005@redhat.com> References: <5458BF0E.7070403@redhat.com> <545B4042.5030005@redhat.com> Message-ID: <545B42D3.60701@redhat.com> On 6.11.2014 10:32, Jan Cholasta wrote: > Hi, > > Dne 4.11.2014 v 12:57 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4632 > > Thanks, ACK. > > Honza > Pushed to: master: 9335552418e515cd97da549da403447e5cae842c ipa-4-1: 25abb1154b7b9b6164612f624143bc583e896b12 -- Petr Vobornik From pvoborni at redhat.com Thu Nov 6 09:46:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 10:46:12 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS In-Reply-To: <545B4280.7050405@redhat.com> References: <5458EBEE.4050803@redhat.com> <5458F0DF.7070709@redhat.com> <545B4280.7050405@redhat.com> Message-ID: <545B4364.9060305@redhat.com> On 6.11.2014 10:42, Jan Cholasta wrote: > Hi, > > Dne 4.11.2014 v 16:29 Martin Basti napsal(a): >> On 04/11/14 16:08, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4670 >>> >>> Patch attached >>> >>> >> I forgot to mention, this is an ancient bug, IMO the fix should go to >> all branches. >> > > Thanks, ACK. > > Honza > Pushed to: master: 730f33680b7254622659eec2e48399ef7033a477 ipa-4-1: 5d65a2a3058aadff29e9af2a6fd3aab91607674f ipa-4-0: d6697b683d3f3517c41e5bbb4b9033fa860fd9d0 -- Petr Vobornik From pvoborni at redhat.com Thu Nov 6 09:54:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 10:54:36 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) In-Reply-To: <20141106094120.GT4107@redhat.com> References: <54524168.8040108@redhat.com> <20141105141938.GI4107@redhat.com> <545A3638.3080507@redhat.com> <545A3899.4070802@redhat.com> <20141105201116.GL4107@redhat.com> <545B33E8.9000205@redhat.com> <545B3F0B.3030504@redhat.com> <20141106094120.GT4107@redhat.com> Message-ID: <545B455C.8070305@redhat.com> On 6.11.2014 10:41, Alexander Bokovoy wrote: > On Thu, 06 Nov 2014, thierry bordaz wrote: >> On 11/06/2014 09:40 AM, Petr Vobornik wrote: >>> On 5.11.2014 21:11, Alexander Bokovoy wrote: >>>> On Wed, 05 Nov 2014, Martin Basti wrote: >>>>>>>> +remove: schema-compat-ignore-subtree: o=ipaca >>>>>>>> +add: schema-compat-restrict-subtree: '$SUFFIX' >>>>>>>> +add: schema-compat-restrict-subtree: 'cn=Schema >>>>>>>> Compatibility,cn=plugins,cn=config' >>>>>>>> >>>>>>>> dn: cn=Schema Compatibility,cn=plugins,cn=config >>>>>>>> # We need to run schema-compat pre-bind callback before >>>>>>> >>>>>>> Conditional ACK -- did you check upgrades from 3.3 version? >>>>>>> >>>>>> >>>>> I did upgrade from 3.3.5 to 4.1 and it worked >>>> ACK. >>> >>> Pushed to: >>> master: 85eb17553f46bfb4446279037e324f825d3389bd >>> ipa-4-1: f0bcf2b29553003af3e5dd35fb6c73752fc95e21 >> Hello, >> >> Just curious, this deadlock also exists in ipa-4-0. Is it planed to >> backport it into that branch ? > It applies fine to 4.0, I think we can add it there as well. Pushed to ipa-4-0: a56a6aff88e9f3fd092fe45056aeb19f15cc2f9f -- Petr Vobornik From pvoborni at redhat.com Thu Nov 6 10:00:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 11:00:06 +0100 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <20141105202216.GM4107@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <20141105202216.GM4107@redhat.com> Message-ID: <545B46A6.40305@redhat.com> On 5.11.2014 21:22, Alexander Bokovoy wrote: > On Wed, 05 Nov 2014, Nathaniel McCallum wrote: >> Before this patch users could log in using only the OTP value. This >> arose because ipapwd_authentication() successfully determined that >> an empty password was invalid, but 389 itself would see this as an >> anonymous bind. An anonymous bind would never even get this far in >> this code, so we simply deny requests with empty passwords. >> >> This patch resolves CVE-2014-7828. >> >> https://fedorahosted.org/freeipa/ticket/4690 > ACK. > > We need to do release for 4.0 and 4.1 first thing tomorrow. > A possible workaround is to disable 2FA for users in mean time. > > Pushed to: master: 79df668b5df59813ffbb6192eecfb687bccbc0eb ipa-4-1: a601daa0117c4991ae7e198cc864246c66d36f57 ipa-4-0: 013e2eae2041729d5ee6ad4dc825bc4f24234ec6 -- Petr Vobornik From tbordaz at redhat.com Thu Nov 6 11:19:38 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 06 Nov 2014 12:19:38 +0100 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <1415218449.7177.14.camel@redhat.com> References: <1415218449.7177.14.camel@redhat.com> Message-ID: <545B594A.1020203@redhat.com> On 11/05/2014 09:14 PM, Nathaniel McCallum wrote: > Before this patch users could log in using only the OTP value. This > arose because ipapwd_authentication() successfully determined that > an empty password was invalid, but 389 itself would see this as an > anonymous bind. An anonymous bind would never even get this far in > this code, so we simply deny requests with empty passwords. > > This patch resolves CVE-2014-7828. > > https://fedorahosted.org/freeipa/ticket/4690 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, With the DS flag 'nsslapd-allow-unauthenticated-binds', customer have the ability to allows unauthenticated binds and connections. With the fix, a ldapclient bind containing only OTP part will fail even if the flag was set. When ipapwd_pre_bind, stipping the OTP part, detects that the password is zero length, I wonder if it should not test that flag to determine if it should fail or succeed. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Nov 6 11:35:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 13:35:55 +0200 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <545B594A.1020203@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <545B594A.1020203@redhat.com> Message-ID: <20141106113555.GV4107@redhat.com> On Thu, 06 Nov 2014, thierry bordaz wrote: >On 11/05/2014 09:14 PM, Nathaniel McCallum wrote: >>Before this patch users could log in using only the OTP value. This >>arose because ipapwd_authentication() successfully determined that >>an empty password was invalid, but 389 itself would see this as an >>anonymous bind. An anonymous bind would never even get this far in >>this code, so we simply deny requests with empty passwords. >> >>This patch resolves CVE-2014-7828. >> >>https://fedorahosted.org/freeipa/ticket/4690 >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel >Hello Nathaniel, > > With the DS flag 'nsslapd-allow-unauthenticated-binds', customer > have the ability to allows unauthenticated binds and connections. > With the fix, a ldapclient bind containing only OTP part will fail > even if the flag was set. By definition of nsslapd-allow-unauthenticated-binds, it requires a BIND with name but no password. Specifying OTP value will make password non-empty and thus failing unauthenticated bind request definition. > When ipapwd_pre_bind, stipping the OTP part, detects that the > password is zero length, I wonder if it should not test that flag to > determine if it should fail or succeed. Since original password was non-empty it wouldn't make sense to check the value for empty password after stripping the OTP part as it is not an unauthenticated password in the first place. -- / Alexander Bokovoy From tbordaz at redhat.com Thu Nov 6 12:47:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 06 Nov 2014 13:47:05 +0100 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <20141106113555.GV4107@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <545B594A.1020203@redhat.com> <20141106113555.GV4107@redhat.com> Message-ID: <545B6DC9.9070602@redhat.com> On 11/06/2014 12:35 PM, Alexander Bokovoy wrote: > On Thu, 06 Nov 2014, thierry bordaz wrote: >> On 11/05/2014 09:14 PM, Nathaniel McCallum wrote: >>> Before this patch users could log in using only the OTP value. This >>> arose because ipapwd_authentication() successfully determined that >>> an empty password was invalid, but 389 itself would see this as an >>> anonymous bind. An anonymous bind would never even get this far in >>> this code, so we simply deny requests with empty passwords. >>> >>> This patch resolves CVE-2014-7828. >>> >>> https://fedorahosted.org/freeipa/ticket/4690 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello Nathaniel, >> >> With the DS flag 'nsslapd-allow-unauthenticated-binds', customer >> have the ability to allows unauthenticated binds and connections. >> With the fix, a ldapclient bind containing only OTP part will fail >> even if the flag was set. > By definition of nsslapd-allow-unauthenticated-binds, it requires a BIND > with name but no password. Specifying OTP value will make password > non-empty and thus failing unauthenticated bind request definition. Hello Alexander, I agree that regarding the RFC, there is unauthenticated bind when the password is empty. The question is when the test of empty password should be done. On DS implementation, the toggle ('nsslapd-allow-unauthenticated-binds') is enforced in frontend when the password is untouched (and so not empty). Later in backend bind, the password has been stripped from its OTP part and being now emptied the backend considere the connection to be anonymous authorized. Should DS also enforce the toggle at backend level ? In that sense that means that the fix (test of password len to reject the bind) could/should rather be done in DS backend than in the preop plugin. thanks thierry > >> When ipapwd_pre_bind, stipping the OTP part, detects that the >> password is zero length, I wonder if it should not test that flag to >> determine if it should fail or succeed. > Since original password was non-empty it wouldn't make sense to check > the value for empty password after stripping the OTP part as it is not > an unauthenticated password in the first place. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 6 13:11:41 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 06 Nov 2014 14:11:41 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS In-Reply-To: <545B4364.9060305@redhat.com> References: <5458EBEE.4050803@redhat.com> <5458F0DF.7070709@redhat.com> <545B4280.7050405@redhat.com> <545B4364.9060305@redhat.com> Message-ID: <545B738D.9080001@redhat.com> On 06/11/14 10:46, Petr Vobornik wrote: > On 6.11.2014 10:42, Jan Cholasta wrote: >> Hi, >> >> Dne 4.11.2014 v 16:29 Martin Basti napsal(a): >>> On 04/11/14 16:08, Martin Basti wrote: >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4670 >>>> >>>> Patch attached >>>> >>>> >>> I forgot to mention, this is an ancient bug, IMO the fix should go to >>> all branches. >>> >> >> Thanks, ACK. >> >> Honza >> > > Pushed to: > master: 730f33680b7254622659eec2e48399ef7033a477 > ipa-4-1: 5d65a2a3058aadff29e9af2a6fd3aab91607674f > ipa-4-0: d6697b683d3f3517c41e5bbb4b9033fa860fd9d0 This bug is also in ipa-3-3, do we want to backport it? -- Martin Basti From abokovoy at redhat.com Thu Nov 6 13:12:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 15:12:25 +0200 Subject: [Freeipa-devel] [PATCH] 0169 Update slapi-nis dependency to 0.54.1 Message-ID: <20141106131225.GW4107@redhat.com> Hi! I've released slapi-nis 0.54.1 to add LDAP BIND support for ID overrides in schema compat plugin and to ignore searches of the overrides themselves outside of the schema compat subtrees. FreeIPA 4.1 and later should depend on this version. I've pushed package updates to rawhide and F21, the latter will be released later today in a combined Bodhi update for FreeIPA 4.1. A patch to freeipa.spec.in is attached. -- / Alexander Bokovoy -------------- next part -------------- From 80e2720b45c77f40264dcab56f4269d5e84d532d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 6 Nov 2014 15:08:55 +0200 Subject: [PATCH] Update slapi-nis dependency to pull 0.54.1 --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 2e453a8..36c2a35 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -129,7 +129,7 @@ Requires(pre): systemd-units Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base -Requires: slapi-nis >= 0.54-1 +Requires: slapi-nis >= 0.54.1-1 Requires: pki-ca >= 10.2.0-3 %if 0%{?rhel} Requires: subscription-manager -- 2.1.0 From abokovoy at redhat.com Thu Nov 6 13:14:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Nov 2014 15:14:59 +0200 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <545B6DC9.9070602@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <545B594A.1020203@redhat.com> <20141106113555.GV4107@redhat.com> <545B6DC9.9070602@redhat.com> Message-ID: <20141106131459.GX4107@redhat.com> On Thu, 06 Nov 2014, thierry bordaz wrote: >On 11/06/2014 12:35 PM, Alexander Bokovoy wrote: >>On Thu, 06 Nov 2014, thierry bordaz wrote: >>>On 11/05/2014 09:14 PM, Nathaniel McCallum wrote: >>>>Before this patch users could log in using only the OTP value. This >>>>arose because ipapwd_authentication() successfully determined that >>>>an empty password was invalid, but 389 itself would see this as an >>>>anonymous bind. An anonymous bind would never even get this far in >>>>this code, so we simply deny requests with empty passwords. >>>> >>>>This patch resolves CVE-2014-7828. >>>> >>>>https://fedorahosted.org/freeipa/ticket/4690 >>>> >>>> >>>>_______________________________________________ >>>>Freeipa-devel mailing list >>>>Freeipa-devel at redhat.com >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>>Hello Nathaniel, >>> >>> With the DS flag 'nsslapd-allow-unauthenticated-binds', customer >>> have the ability to allows unauthenticated binds and connections. >>> With the fix, a ldapclient bind containing only OTP part will fail >>> even if the flag was set. >>By definition of nsslapd-allow-unauthenticated-binds, it requires a BIND >>with name but no password. Specifying OTP value will make password >>non-empty and thus failing unauthenticated bind request definition. > >Hello Alexander, > > I agree that regarding the RFC, there is unauthenticated bind when > the password is empty. The question is when the test of empty > password should be done. > On DS implementation, the toggle > ('nsslapd-allow-unauthenticated-binds') is enforced in frontend when > the password is untouched (and so not empty). > Later in backend bind, the password has been stripped from its OTP > part and being now emptied the backend considere the connection to > be anonymous authorized. Should DS also enforce the toggle at > backend level ? > > In that sense that means that the fix (test of password len to > reject the bind) could/should rather be done in DS backend than in > the preop plugin. IPA preop plugin has to check for the empty password because we update token-related information and user's Kerberos attributes even in case password failed as we need to keep track of the used token values and authentication failures. Thus, I think, the check in the preop plugin is still needed. -- / Alexander Bokovoy From tbordaz at redhat.com Thu Nov 6 13:19:04 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 06 Nov 2014 14:19:04 +0100 Subject: [Freeipa-devel] [PATCH 0076] Ensure that a password exists after OTP validation In-Reply-To: <20141106131459.GX4107@redhat.com> References: <1415218449.7177.14.camel@redhat.com> <545B594A.1020203@redhat.com> <20141106113555.GV4107@redhat.com> <545B6DC9.9070602@redhat.com> <20141106131459.GX4107@redhat.com> Message-ID: <545B7548.7050103@redhat.com> On 11/06/2014 02:14 PM, Alexander Bokovoy wrote: > On Thu, 06 Nov 2014, thierry bordaz wrote: >> On 11/06/2014 12:35 PM, Alexander Bokovoy wrote: >>> On Thu, 06 Nov 2014, thierry bordaz wrote: >>>> On 11/05/2014 09:14 PM, Nathaniel McCallum wrote: >>>>> Before this patch users could log in using only the OTP value. This >>>>> arose because ipapwd_authentication() successfully determined that >>>>> an empty password was invalid, but 389 itself would see this as an >>>>> anonymous bind. An anonymous bind would never even get this far in >>>>> this code, so we simply deny requests with empty passwords. >>>>> >>>>> This patch resolves CVE-2014-7828. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4690 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Hello Nathaniel, >>>> >>>> With the DS flag 'nsslapd-allow-unauthenticated-binds', customer >>>> have the ability to allows unauthenticated binds and connections. >>>> With the fix, a ldapclient bind containing only OTP part will fail >>>> even if the flag was set. >>> By definition of nsslapd-allow-unauthenticated-binds, it requires a >>> BIND >>> with name but no password. Specifying OTP value will make password >>> non-empty and thus failing unauthenticated bind request definition. >> >> Hello Alexander, >> >> I agree that regarding the RFC, there is unauthenticated bind when >> the password is empty. The question is when the test of empty >> password should be done. >> On DS implementation, the toggle >> ('nsslapd-allow-unauthenticated-binds') is enforced in frontend when >> the password is untouched (and so not empty). >> Later in backend bind, the password has been stripped from its OTP >> part and being now emptied the backend considere the connection to >> be anonymous authorized. Should DS also enforce the toggle at >> backend level ? >> >> In that sense that means that the fix (test of password len to >> reject the bind) could/should rather be done in DS backend than in >> the preop plugin. > IPA preop plugin has to check for the empty password because we update > token-related information and user's Kerberos attributes even in case > password failed as we need to keep track of the used token values and > authentication failures. > > Thus, I think, the check in the preop plugin is still needed. ok I understand. Checking/update is fine.. but I was wondering if the failure was needed (systematically). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Nov 6 13:29:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 06 Nov 2014 14:29:31 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <54579A28.80607@redhat.com> References: <54579A28.80607@redhat.com> Message-ID: <545B77BB.3050604@redhat.com> On 11/03/2014 04:07 PM, Petr Viktorin wrote: > Hello! > > There's been some interest in releasing pieces of FreeIPA's testing > infrastructure so it can be reused in other projects. > I will soon take the pytest-beakerlib plugin (currently in my patch > 0672), and making a stand-alone project out of it. Later I'll extract > the common pieces of the integration testign framework, and release that > independently. Thanks for the discussion, everyone. I've opened a ticket to get the project space for the BeakerLib plugin: https://fedorahosted.org/fedora-infrastructure/ticket/4589 When that's done I'll point the package metadata to there, push to PyPI and open a Fedora review request. While we wait, it's available here: https://github.com/encukou/pytest-beakerlib https://copr.fedoraproject.org/coprs/pviktori/pytest-beakerlib Do we need a version for EL 6? I'd need to check the pytest versions there, and build a newer pytest if necessary. The second part is the multi-host framework. I've looked at what parts are applicable to other projects than IPA, and came up with an initial design/README here: https://github.com/encukou/pytest-multihost I'll add a concrete example, code, and patches for IPA, soon. IPA also has/will have a plugin to run tests within a class in source order (respecting inheritance), rather than in pytest's unspecified order ("usually alphabetically", IIRC). It can be extracted as well if there's interest. -- Petr? From tbabej at redhat.com Thu Nov 6 14:02:10 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 06 Nov 2014 15:02:10 +0100 Subject: [Freeipa-devel] [PATCH 0285] specfile: Add BuildRequires for pki-base 10.2.1-0 Message-ID: <545B7F62.80701@redhat.com> Hi, this solves the build errors we've been seeing recently on master branch. https://fedorahosted.org/freeipa/ticket/4688 Copr for pki-base 10.2.1-0 is available here: http://copr.fedoraproject.org/coprs/edewata/pki/ -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0285-specfile-Add-BuildRequires-for-pki-base-10.2.1-0.patch Type: text/x-patch Size: 829 bytes Desc: not available URL: From spoore at redhat.com Thu Nov 6 16:00:57 2014 From: spoore at redhat.com (Scott Poore) Date: Thu, 6 Nov 2014 11:00:57 -0500 (EST) Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <545B77BB.3050604@redhat.com> References: <54579A28.80607@redhat.com> <545B77BB.3050604@redhat.com> Message-ID: <1044494194.6508622.1415289657120.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Viktorin" > To: freeipa-devel at redhat.com > Sent: Thursday, November 6, 2014 7:29:31 AM > Subject: Re: [Freeipa-devel] Releasing testing tools as standalone projects > > On 11/03/2014 04:07 PM, Petr Viktorin wrote: > > Hello! > > > > There's been some interest in releasing pieces of FreeIPA's testing > > infrastructure so it can be reused in other projects. > > I will soon take the pytest-beakerlib plugin (currently in my patch > > 0672), and making a stand-alone project out of it. Later I'll extract > > the common pieces of the integration testign framework, and release that > > independently. > > Thanks for the discussion, everyone. > I've opened a ticket to get the project space for the BeakerLib plugin: > https://fedorahosted.org/fedora-infrastructure/ticket/4589 > When that's done I'll point the package metadata to there, push to PyPI > and open a Fedora review request. Awesome. Thanks, Petr. > > While we wait, it's available here: > https://github.com/encukou/pytest-beakerlib > https://copr.fedoraproject.org/coprs/pviktori/pytest-beakerlib > Mind if I pass this on to some other QE teams that might be interested? > Do we need a version for EL 6? I'd need to check the pytest versions > there, and build a newer pytest if necessary. Yes, I think we will want an EL6 version as well at least at some point. > > > The second part is the multi-host framework. I've looked at what parts > are applicable to other projects than IPA, and came up with an initial > design/README here: https://github.com/encukou/pytest-multihost > I'll add a concrete example, code, and patches for IPA, soon. This is the paramiko/openssh stuff you've mentioned before right? I think this is the other piece I'd be very interested in. > > > IPA also has/will have a plugin to run tests within a class in source > order (respecting inheritance), rather than in pytest's unspecified > order ("usually alphabetically", IIRC). It can be extracted as well if > there's interest. > When you say in source order here, you mean source code order? So, we could actually order tests in the file as we see fit instead of relying on naming to define execution order? Would this affect use of the built in setup/teardown fixtures? Or we should just stay away from those anyway? Thanks, Petr. Scott > > -- > Petr? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Thu Nov 6 16:34:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 17:34:41 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.5 Message-ID: <545BA321.7020906@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.5 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 21 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/ COPR repository]. == Highlights in 4.0.5 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * prevent possible deadlocks with schema compatibility plugin == 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 if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require 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 3.3.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 4.0.4 == === Martin Basti (1) === * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Vobornik (1) === * Become IPA 4.0.5 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik From pvoborni at redhat.com Thu Nov 6 16:35:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Nov 2014 17:35:27 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 4.1.1 Message-ID: <545BA34F.2060100@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.1 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.1 == === Bug fixes === * CVE-2014-7828: ensure that a password is provided in 2 factor authentication [http://www.freeipa.org/page/CVE-2014-7828] * fixed upgrade issue from FreeIPA 3.3.5 [https://fedorahosted.org/freeipa/ticket/4670] [https://fedorahosted.org/freeipa/ticket/4635] * various bug fixes in CA management tools and DNS sec * Allow reading SSH public keys overrides of users * Allow reading GID value override for users * prevent possible deadlocks with schema compatibility plugin == Known Issues == * On Fedora 21 beta, FreeIPA server installation fails with SELinux in enforcing mode. == 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 if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require 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 3.3.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 4.1.0 == === Alexander Bokovoy (1) === * Add ipaSshPubkey and gidNumber to the ACI to read ID user overrides === David Kupka (2) === * Respect UID and GID soft static allocation. * Stop dirsrv last in ipactl stop. === Jan Cholasta (10) === * Do not check if port 8443 is available in step 2 of external CA install * Handle profile changes in dogtag-ipa-ca-renew-agent * Do not wait for new CA certificate to appear in LDAP in ipa-certupdate * Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage * Fix possible NULL dereference in ipa-kdb * Fix memory leaks in ipa-extdom-extop * Fix various bugs in ipa-opt-counter and ipa-otp-lasttoken * Fix memory leak in ipa-pwd-extop * Fix memory leaks in ipa-join * Fix various bugs in ipap11helper === Martin Basti (4) === * Fix dns zonemgr validation regression * Add bind-dyndb-ldap working dir to IPA specfile * Fix CI tests: install_adtrust * Fix upgrade: do not use invalid ldap connection === Nathaniel McCallum (1) === * Ensure that a password exists after OTP validation === Petr Spacek (1) === * Fix zone name to directory name conversion in BINDMgr. === Petr Vobornik (2) === * build: increase java stack size for all arches * Become IPA 4.1.1 === Thierry bordaz (tbordaz) (1) === * Deadlock in schema compat plugin (between automember_update_membership task and dse update) -- Petr Vobornik From npmccallum at redhat.com Thu Nov 6 19:11:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Nov 2014 14:11:15 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415117855.3318.3.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> Message-ID: <1415301075.3273.0.camel@redhat.com> On Tue, 2014-11-04 at 11:17 -0500, Nathaniel McCallum wrote: > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > > On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > > >> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > > >>> This patch gives the administrator variables to control the size of > > > >>> the authentication and synchronization windows for OTP tokens. > > > >>> > > > >>> https://fedorahosted.org/freeipa/ticket/4511 > > > >>> > > > >>> NOTE: There is one known issue with this patch which I don't know how to > > > >>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. > > > >>> On an upgrade, all of the new attributeTypes appear correctly. However, > > > >>> the modifications to the pre-existing objectClass do not show up on the > > > >>> server. What am I doing wrong? > > > >>> > > > >>> After modifying ipaGuiConfig manually, everything in this patch works > > > >>> just fine. > > > >> > > > >> This new version takes into account the new (proper) OIDs and attribute > > > >> names. > > > > > > > > Thanks Nathaniel! > > > > > > > >> The above known issue still remains. > > > > > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list extension > > > > should work just fine, AFAIK. > > > > > > You added a blank line to the LDIF file. This is an entry separator, so > > > the objectClasses after the blank line don't belong to cn=schema, so > > > they aren't considered in the update. > > > Without the blank line it works fine. > > > > Thanks for the catch! > > > > Here is a version without the blank line. > > I forgot to remove the old steps defines. This patch performs this > cleanup. Can I get a review on this soon? I need to make other changes in these files for another bug and I'd prefer to not have to shuffle between patches. Nathaniel From npmccallum at redhat.com Thu Nov 6 20:24:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Nov 2014 15:24:50 -0500 Subject: [Freeipa-devel] [PATCH 0077] Improve otptoken help messages Message-ID: <1415305490.3273.6.camel@redhat.com> https://fedorahosted.org/freeipa/ticket/4689 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0077-Improve-otptoken-help-messages.patch Type: text/x-patch Size: 4511 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 6 20:33:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Nov 2014 15:33:54 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add Message-ID: <1415306034.3273.8.camel@redhat.com> This is possible because python-qrcode's output now fits in a standard terminal. Also, update ipa-otp-import and otptoken-add-yubikey to disable QR code output as it doesn't make sense in these contexts. https://fedorahosted.org/freeipa/ticket/4703 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0078-Enable-QR-code-display-by-default-in-otptoken-add.patch Type: text/x-patch Size: 3097 bytes Desc: not available URL: From rcritten at redhat.com Thu Nov 6 21:16:32 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 Nov 2014 16:16:32 -0500 Subject: [Freeipa-devel] [PATCH] 1110 fix search scope Message-ID: <545BE530.1090409@redhat.com> The wrong search scope was being used to determine if a given master had a CA installed during ipa-csreplica-manage connect. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1110-scope.patch Type: text/x-patch Size: 1230 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 6 21:46:05 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Nov 2014 16:46:05 -0500 Subject: [Freeipa-devel] [PATCH] 1110 fix search scope In-Reply-To: <545BE530.1090409@redhat.com> References: <545BE530.1090409@redhat.com> Message-ID: <1415310365.11046.1.camel@redhat.com> On Thu, 2014-11-06 at 16:16 -0500, Rob Crittenden wrote: > The wrong search scope was being used to determine if a given master had > a CA installed during ipa-csreplica-manage connect. ACK From npmccallum at redhat.com Thu Nov 6 23:00:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 06 Nov 2014 18:00:21 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> Message-ID: <1415314821.5013.3.camel@redhat.com> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > ----- Original Message ----- > > On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > Patch attached. > > > > I'm curious - what is the purpose of this patch? To prevent 1 second timeouts > > and re-transmits when OTP is in place? > > > > What is the expected performance impact? Could it be configured for OTP > > separately - somehow? (I guess that it is not possible now ...) > > It benefits also communication of large packets (when large MS-PAC or CAMMAC AD Data > are attached), so it is a better choice for IPA in general. Especially given we have > multiple KDC processes configured we do not want clients wasting KDC resources by > making multiple processes do the same operation. So apparently this patch never got reviewed over a year ago. It was related to a bug which was opened in SSSD. However, when it became clear we wanted to solve this in FreeIPA, the SSSD bug was closed but no corresponding FreeIPA bug was opened. The patch then fell through the cracks. Without this patch, if OTP validation runs long we get retransmits and failures. One question I have is how to handle this for upgrades since (I think) this patch only handles new installs. Anyway, this patch is somewhat urgent now. So help is appreciated. I have attached a rebased version which has no other changes. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0019-Prefer-TCP-connections-to-UDP-in-krb5-clients.patch Type: text/x-patch Size: 3306 bytes Desc: not available URL: From ssorce at redhat.com Fri Nov 7 00:46:11 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 6 Nov 2014 19:46:11 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1415314821.5013.3.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> Message-ID: <20141106194611.1c91f5eb@willson.usersys.redhat.com> On Thu, 06 Nov 2014 18:00:21 -0500 Nathaniel McCallum wrote: > On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > > > ----- Original Message ----- > > > On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > Patch attached. > > > > > > I'm curious - what is the purpose of this patch? To prevent 1 > > > second timeouts and re-transmits when OTP is in place? > > > > > > What is the expected performance impact? Could it be configured > > > for OTP separately - somehow? (I guess that it is not possible > > > now ...) > > > > It benefits also communication of large packets (when large MS-PAC > > or CAMMAC AD Data are attached), so it is a better choice for IPA > > in general. Especially given we have multiple KDC processes > > configured we do not want clients wasting KDC resources by making > > multiple processes do the same operation. > > So apparently this patch never got reviewed over a year ago. > > It was related to a bug which was opened in SSSD. However, when it > became clear we wanted to solve this in FreeIPA, the SSSD bug was > closed but no corresponding FreeIPA bug was opened. The patch then > fell through the cracks. > > Without this patch, if OTP validation runs long we get retransmits and > failures. > > One question I have is how to handle this for upgrades since (I think) > this patch only handles new installs. > > Anyway, this patch is somewhat urgent now. So help is appreciated. > > I have attached a rebased version which has no other changes. > > Nathaniel I am not sure we can do much on updates, we do not have a client-update tool, I would just document it I guess. Otherwise we'd have to go back to sssd which can inject additional values in krb5.conf, however I am not sure it would be ok to set something like this in the sssd's pubconf includes ... Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 7 07:02:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 08:02:02 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141106194611.1c91f5eb@willson.usersys.redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> Message-ID: <545C6E6A.5070101@redhat.com> On 11/07/2014 01:46 AM, Simo Sorce wrote: > On Thu, 06 Nov 2014 18:00:21 -0500 > Nathaniel McCallum wrote: > >> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>> >>> ----- Original Message ----- >>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>> Patch attached. >>>> >>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>> second timeouts and re-transmits when OTP is in place? >>>> >>>> What is the expected performance impact? Could it be configured >>>> for OTP separately - somehow? (I guess that it is not possible >>>> now ...) >>> >>> It benefits also communication of large packets (when large MS-PAC >>> or CAMMAC AD Data are attached), so it is a better choice for IPA >>> in general. Especially given we have multiple KDC processes >>> configured we do not want clients wasting KDC resources by making >>> multiple processes do the same operation. >> >> So apparently this patch never got reviewed over a year ago. >> >> It was related to a bug which was opened in SSSD. However, when it >> became clear we wanted to solve this in FreeIPA, the SSSD bug was >> closed but no corresponding FreeIPA bug was opened. The patch then >> fell through the cracks. Right - without an associated ticket tracking the patch, it is too easy to loose it unless the author prods people to review it. >> Without this patch, if OTP validation runs long we get retransmits and >> failures. >> >> One question I have is how to handle this for upgrades since (I think) >> this patch only handles new installs. >> >> Anyway, this patch is somewhat urgent now. So help is appreciated. >> >> I have attached a rebased version which has no other changes. >> >> Nathaniel > > I am not sure we can do much on updates, we do not have a > client-update tool, I would just document it I guess. > Otherwise we'd have to go back to sssd which can inject additional > values in krb5.conf, however I am not sure it would be ok to set > something like this in the sssd's pubconf includes ... Agreed, pubconf update does not sound right. However, we already update krb5.conf on client updates, in %post: %post client if [ $1 -gt 1 ] ; then # Has the client been configured? restore=0 test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then if ! grep -E -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 2>/dev/null ; then echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > /etc/krb5.conf.ipanew cat /etc/krb5.conf >> /etc/krb5.conf.ipanew mv /etc/krb5.conf.ipanew /etc/krb5.conf /sbin/restorecon /etc/krb5.conf fi fi ... This particular update is more difficult as not a first line needs to be changed. Without adding ipa client update tool with some reasonable krb5.conf parser, we could do something along the lines of sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = 0/g' /etc/krb5.conf (tested), but it is not pretty. Martin From mkosek at redhat.com Fri Nov 7 07:08:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 08:08:19 +0100 Subject: [Freeipa-devel] [PATCH 0156] Fix upgrade: create new connection after restarting DS In-Reply-To: <545B738D.9080001@redhat.com> References: <5458EBEE.4050803@redhat.com> <5458F0DF.7070709@redhat.com> <545B4280.7050405@redhat.com> <545B4364.9060305@redhat.com> <545B738D.9080001@redhat.com> Message-ID: <545C6FE3.6090204@redhat.com> On 11/06/2014 02:11 PM, Martin Basti wrote: > On 06/11/14 10:46, Petr Vobornik wrote: >> On 6.11.2014 10:42, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 4.11.2014 v 16:29 Martin Basti napsal(a): >>>> On 04/11/14 16:08, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4670 >>>>> >>>>> Patch attached >>>>> >>>>> >>>> I forgot to mention, this is an ancient bug, IMO the fix should go to >>>> all branches. >>>> >>> >>> Thanks, ACK. >>> >>> Honza >>> >> >> Pushed to: >> master: 730f33680b7254622659eec2e48399ef7033a477 >> ipa-4-1: 5d65a2a3058aadff29e9af2a6fd3aab91607674f >> ipa-4-0: d6697b683d3f3517c41e5bbb4b9033fa860fd9d0 > This bug is also in ipa-3-3, do we want to backport it? It can be pushed also to ipa-3-3 branch, but I would not release a new FreeIPA version for it (unless it blocks people) - FreeIPA 4.0+ are the releases to focus on. Martin From mkosek at redhat.com Fri Nov 7 07:58:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 08:58:56 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415117855.3318.3.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> Message-ID: <545C7BC0.80205@redhat.com> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>> This patch gives the administrator variables to control the size of >>>>>> the authentication and synchronization windows for OTP tokens. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>> >>>>>> NOTE: There is one known issue with this patch which I don't know how to >>>>>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. >>>>>> On an upgrade, all of the new attributeTypes appear correctly. However, >>>>>> the modifications to the pre-existing objectClass do not show up on the >>>>>> server. What am I doing wrong? >>>>>> >>>>>> After modifying ipaGuiConfig manually, everything in this patch works >>>>>> just fine. >>>>> >>>>> This new version takes into account the new (proper) OIDs and attribute >>>>> names. >>>> >>>> Thanks Nathaniel! >>>> >>>>> The above known issue still remains. >>>> >>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list extension >>>> should work just fine, AFAIK. >>> >>> You added a blank line to the LDIF file. This is an entry separator, so >>> the objectClasses after the blank line don't belong to cn=schema, so >>> they aren't considered in the update. >>> Without the blank line it works fine. >> >> Thanks for the catch! >> >> Here is a version without the blank line. > > I forgot to remove the old steps defines. This patch performs this > cleanup. I am now wondering, is the global config object really the nest place to add these OTP specific settings? I would prefer not to overload the object and instead: - create new ipaOTPConfig objectclass - add it to cn=otp,$SUFFIX - create otpconfig-mod and otpconfig-show commands to follow an example of dnsconfig-* and trustconfig-* commands IMO, this would allow more flexibility for the OTP settings and would also scale better for the future updates. Martin From mkosek at redhat.com Fri Nov 7 09:14:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 10:14:57 +0100 Subject: [Freeipa-devel] New Feature Template Message-ID: <545C8D91.2060200@redhat.com> Hello all, Most developers involved in 4.1.0 design updates already know, but we updated the Feature Template to better fit the needs of the project. See http://www.freeipa.org/page/Feature_template Major changes: - The main shift is that we want the design pages to be readable by both developers, but also the users. Especially the Overview, Use Cases, high level part of Design and the new How to Test section need to be understandable for them. This is after all the main and only upstream documentation of the feature so it needs to be ready for external consumers. - There is a new wiki template for creating the Feature Box in the top of the page, see for example http://www.freeipa.org/page/V4/OTP. Main goal is to provide a link from the feature to the release and trac ticket. I went through and updated most of 4.0.0 and 4.1.0 designs to have this box, this has immediate benefit of not only being more clear, but also with "What Links Here" part of releases pages being quite interesting: http://www.freeipa.org/page/Special:WhatLinksHere/Releases/4.0.0 http://www.freeipa.org/page/Special:WhatLinksHere/Releases/4.1.0 - Some sections of the previous template were not used in most design pages so they were just converted to optional subsections. - (minor) header level was changed from "= Header =" to "== Header ==". Wiki pages are not really supposed to "=" level of headers as it generates

tag and there should be just one such tag - page title. Any other improvements or comments welcome. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Fri Nov 7 09:29:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 10:29:24 +0100 Subject: [Freeipa-devel] [PATCH] 0169 Update slapi-nis dependency to 0.54.1 In-Reply-To: <20141106131225.GW4107@redhat.com> References: <20141106131225.GW4107@redhat.com> Message-ID: <545C90F4.7060506@redhat.com> On 11/06/2014 02:12 PM, Alexander Bokovoy wrote: > Hi! > > I've released slapi-nis 0.54.1 to add LDAP BIND support for ID overrides > in schema compat plugin and to ignore searches of the overrides > themselves outside of the schema compat subtrees. > > FreeIPA 4.1 and later should depend on this version. I've pushed package > updates to rawhide and F21, the latter will be released later today in a > combined Bodhi update for FreeIPA 4.1. > > A patch to freeipa.spec.in is attached. Fedora build should be already handled, we just miss upstream fix. ACK. Pushed to master (with rebase) and ipa-4-1. Martin From pviktori at redhat.com Fri Nov 7 11:32:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 07 Nov 2014 12:32:06 +0100 Subject: [Freeipa-devel] [PATCH 0285] specfile: Add BuildRequires for pki-base 10.2.1-0 In-Reply-To: <545B7F62.80701@redhat.com> References: <545B7F62.80701@redhat.com> Message-ID: <545CADB6.5040301@redhat.com> On 11/06/2014 03:02 PM, Tomas Babej wrote: > Hi, > > this solves the build errors we've been seeing recently on master branch. > > https://fedorahosted.org/freeipa/ticket/4688 > > Copr for pki-base 10.2.1-0 is available here: > http://copr.fedoraproject.org/coprs/edewata/pki/ Thanks! ACK, pushed to master: b168a7f2d1793fbeb32790e1752b16dce0e5133d -- Petr? From pviktori at redhat.com Fri Nov 7 11:41:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 07 Nov 2014 12:41:37 +0100 Subject: [Freeipa-devel] Releasing testing tools as standalone projects In-Reply-To: <1044494194.6508622.1415289657120.JavaMail.zimbra@redhat.com> References: <54579A28.80607@redhat.com> <545B77BB.3050604@redhat.com> <1044494194.6508622.1415289657120.JavaMail.zimbra@redhat.com> Message-ID: <545CAFF1.9020306@redhat.com> On 11/06/2014 05:00 PM, Scott Poore wrote: > ----- Original Message ----- >> From: "Petr Viktorin" [...] >> I've opened a ticket to get the project space for the BeakerLib plugin: >> https://fedorahosted.org/fedora-infrastructure/ticket/4589 >> When that's done I'll point the package metadata to there, push to PyPI >> and open a Fedora review request. > > Awesome. Thanks, Petr. > >> >> While we wait, it's available here: >> https://github.com/encukou/pytest-beakerlib >> https://copr.fedoraproject.org/coprs/pviktori/pytest-beakerlib >> > > Mind if I pass this on to some other QE teams that might be interested? Not at all, go ahead! You might want to wait until the project gets its permanent home, though. > >> Do we need a version for EL 6? I'd need to check the pytest versions >> there, and build a newer pytest if necessary. > > Yes, I think we will want an EL6 version as well at least at some point. Let me know when that point comes :) >> The second part is the multi-host framework. I've looked at what parts >> are applicable to other projects than IPA, and came up with an initial >> design/README here: https://github.com/encukou/pytest-multihost >> I'll add a concrete example, code, and patches for IPA, soon. > > This is the paramiko/openssh stuff you've mentioned before right? > > I think this is the other piece I'd be very interested in. Yup, that's what it is. >> IPA also has/will have a plugin to run tests within a class in source >> order (respecting inheritance), rather than in pytest's unspecified >> order ("usually alphabetically", IIRC). It can be extracted as well if >> there's interest. >> > > When you say in source order here, you mean source code order? So, we could actually order tests in the file as we see fit instead of relying on naming to define execution order? Yes. (Except it orders per class, not per source file.) It's not good practice to rely on test order, but it works for integration tests with big setup costs. > Would this affect use of the built in setup/teardown fixtures? Or we should just stay away from those anyway? I'm not sure what you mean by built in setup/teardown fixtures? Anyway it should be safe, unless you use another test reordering plugin as well. (e.g. there's a 3rd party plugin for distributed running of tests, using that would not be a good idea) -- Petr? From mbasti at redhat.com Fri Nov 7 12:33:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 13:33:43 +0100 Subject: [Freeipa-devel] [PATCH 0157] Fix installer adds invalid zonemgr email Message-ID: <545CBC27.9080703@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4707 Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0157-Fix-DNS-installer-adds-invalid-zonemgr-email.patch Type: text/x-patch Size: 1566 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 7 12:33:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 13:33:54 +0100 Subject: [Freeipa-devel] [PATCH 0306] Improve info messages about number of defined/loaded zones Message-ID: <545CBC32.7030205@redhat.com> Hello, Improve info messages about number of defined/loaded zones. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0306-Improve-info-messages-about-number-of-defined-loaded.patch Type: text/x-patch Size: 1118 bytes Desc: not available URL: From ssorce at redhat.com Fri Nov 7 13:20:06 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 7 Nov 2014 08:20:06 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <545C6E6A.5070101@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> Message-ID: <20141107082006.1d2543c5@willson.usersys.redhat.com> On Fri, 07 Nov 2014 08:02:02 +0100 Martin Kosek wrote: > On 11/07/2014 01:46 AM, Simo Sorce wrote: > > On Thu, 06 Nov 2014 18:00:21 -0500 > > Nathaniel McCallum wrote: > > > >> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>> > >>> ----- Original Message ----- > >>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>> Patch attached. > >>>> > >>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>> second timeouts and re-transmits when OTP is in place? > >>>> > >>>> What is the expected performance impact? Could it be configured > >>>> for OTP separately - somehow? (I guess that it is not possible > >>>> now ...) > >>> > >>> It benefits also communication of large packets (when large MS-PAC > >>> or CAMMAC AD Data are attached), so it is a better choice for IPA > >>> in general. Especially given we have multiple KDC processes > >>> configured we do not want clients wasting KDC resources by making > >>> multiple processes do the same operation. > >> > >> So apparently this patch never got reviewed over a year ago. > >> > >> It was related to a bug which was opened in SSSD. However, when it > >> became clear we wanted to solve this in FreeIPA, the SSSD bug was > >> closed but no corresponding FreeIPA bug was opened. The patch then > >> fell through the cracks. > > Right - without an associated ticket tracking the patch, it is too > easy to loose it unless the author prods people to review it. > > >> Without this patch, if OTP validation runs long we get retransmits > >> and failures. > >> > >> One question I have is how to handle this for upgrades since (I > >> think) this patch only handles new installs. > >> > >> Anyway, this patch is somewhat urgent now. So help is appreciated. > >> > >> I have attached a rebased version which has no other changes. > >> > >> Nathaniel > > > > I am not sure we can do much on updates, we do not have a > > client-update tool, I would just document it I guess. > > Otherwise we'd have to go back to sssd which can inject additional > > values in krb5.conf, however I am not sure it would be ok to set > > something like this in the sssd's pubconf includes ... > > Agreed, pubconf update does not sound right. > > However, we already update krb5.conf on client updates, in %post: > > %post client > if [ $1 -gt 1 ] ; then > # Has the client been configured? > restore=0 > test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && > restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | > awk '{print $1}') > > if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > if ! grep -E -q > '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > 2>/dev/null ; then > echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > > /etc/krb5.conf.ipanew > cat /etc/krb5.conf >> /etc/krb5.conf.ipanew > mv /etc/krb5.conf.ipanew /etc/krb5.conf > /sbin/restorecon /etc/krb5.conf > fi > fi > ... > > > This particular update is more difficult as not a first line needs to > be changed. Without adding ipa client update tool with some > reasonable krb5.conf parser, we could do something along the lines of > > sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = > 0/g' /etc/krb5.conf > > (tested), but it is not pretty. What happen the next time you run it again ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 7 13:26:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 14:26:06 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141107082006.1d2543c5@willson.usersys.redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> Message-ID: <545CC86E.9020702@redhat.com> On 11/07/2014 02:20 PM, Simo Sorce wrote: > On Fri, 07 Nov 2014 08:02:02 +0100 > Martin Kosek wrote: > >> On 11/07/2014 01:46 AM, Simo Sorce wrote: >>> On Thu, 06 Nov 2014 18:00:21 -0500 >>> Nathaniel McCallum wrote: >>> >>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>> Patch attached. >>>>>> >>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>> second timeouts and re-transmits when OTP is in place? >>>>>> >>>>>> What is the expected performance impact? Could it be configured >>>>>> for OTP separately - somehow? (I guess that it is not possible >>>>>> now ...) >>>>> >>>>> It benefits also communication of large packets (when large MS-PAC >>>>> or CAMMAC AD Data are attached), so it is a better choice for IPA >>>>> in general. Especially given we have multiple KDC processes >>>>> configured we do not want clients wasting KDC resources by making >>>>> multiple processes do the same operation. >>>> >>>> So apparently this patch never got reviewed over a year ago. >>>> >>>> It was related to a bug which was opened in SSSD. However, when it >>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was >>>> closed but no corresponding FreeIPA bug was opened. The patch then >>>> fell through the cracks. >> >> Right - without an associated ticket tracking the patch, it is too >> easy to loose it unless the author prods people to review it. >> >>>> Without this patch, if OTP validation runs long we get retransmits >>>> and failures. >>>> >>>> One question I have is how to handle this for upgrades since (I >>>> think) this patch only handles new installs. >>>> >>>> Anyway, this patch is somewhat urgent now. So help is appreciated. >>>> >>>> I have attached a rebased version which has no other changes. >>>> >>>> Nathaniel >>> >>> I am not sure we can do much on updates, we do not have a >>> client-update tool, I would just document it I guess. >>> Otherwise we'd have to go back to sssd which can inject additional >>> values in krb5.conf, however I am not sure it would be ok to set >>> something like this in the sssd's pubconf includes ... >> >> Agreed, pubconf update does not sound right. >> >> However, we already update krb5.conf on client updates, in %post: >> >> %post client >> if [ $1 -gt 1 ] ; then >> # Has the client been configured? >> restore=0 >> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && >> restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | >> awk '{print $1}') >> >> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >> if ! grep -E -q >> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >> 2>/dev/null ; then >> echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > >> /etc/krb5.conf.ipanew >> cat /etc/krb5.conf >> /etc/krb5.conf.ipanew >> mv /etc/krb5.conf.ipanew /etc/krb5.conf >> /sbin/restorecon /etc/krb5.conf >> fi >> fi >> ... >> >> >> This particular update is more difficult as not a first line needs to >> be changed. Without adding ipa client update tool with some >> reasonable krb5.conf parser, we could do something along the lines of >> >> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = >> 0/g' /etc/krb5.conf >> >> (tested), but it is not pretty. > > What happen the next time you run it again ? > > Simo. > It would of course be added again, you would need to first grep for presence of udp_preference_limit setting. Question is if this approach is safe enough to be in our client %post upgrade. We already upgrade krb5.conf here, just the change is much easier as we just add a line to the beginning of the file. Martin From dkupka at redhat.com Fri Nov 7 13:28:29 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 07 Nov 2014 14:28:29 +0100 Subject: [Freeipa-devel] [PATCH 0157] Fix installer adds invalid zonemgr email In-Reply-To: <545CBC27.9080703@redhat.com> References: <545CBC27.9080703@redhat.com> Message-ID: <545CC8FD.300@redhat.com> On 11/07/2014 01:33 PM, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4707 > Patch attached > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > I think that it would be better to use relative value (e.g.: "hostmaster" instead of "hostmaster.my.example.zone."). But this works, ACK. -- David Kupka From mkosek at redhat.com Fri Nov 7 13:41:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 14:41:54 +0100 Subject: [Freeipa-devel] Gaps in upstream tests Message-ID: <545CCC22.9040501@redhat.com> FreeIPA team will soon grow with a new member focusing on upstream QE tests. I would like to collect ideas what are the biggest gaps in the current upstream test suite from your POV. Existing requests are tracked here: https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Tests&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=milestone&group=milestone&order=priority First idea that I head proposed are Upgrade tests. These are often done manually. I think that upgrade test from currently supported FreeIPA/Fedora version would go a long way (like 3.3.5 on F20 upgraded built RPMs and running unit tests). Second, it would be nice to try testing FreeIPA server in a container. Not only it would verify our container efforts, but it may also allow easy multi-master tests on one Jenkins VM or local host instead of expensive VM orchestration. Any other areas worth focusing on (besides of course testing newly developed features)? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From ssorce at redhat.com Fri Nov 7 13:51:29 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 7 Nov 2014 08:51:29 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <545CC86E.9020702@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> Message-ID: <20141107085129.77573940@willson.usersys.redhat.com> On Fri, 07 Nov 2014 14:26:06 +0100 Martin Kosek wrote: > On 11/07/2014 02:20 PM, Simo Sorce wrote: > > On Fri, 07 Nov 2014 08:02:02 +0100 > > Martin Kosek wrote: > > > >> On 11/07/2014 01:46 AM, Simo Sorce wrote: > >>> On Thu, 06 Nov 2014 18:00:21 -0500 > >>> Nathaniel McCallum wrote: > >>> > >>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>>> Patch attached. > >>>>>> > >>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>>> second timeouts and re-transmits when OTP is in place? > >>>>>> > >>>>>> What is the expected performance impact? Could it be configured > >>>>>> for OTP separately - somehow? (I guess that it is not possible > >>>>>> now ...) > >>>>> > >>>>> It benefits also communication of large packets (when large > >>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better > >>>>> choice for IPA in general. Especially given we have multiple > >>>>> KDC processes configured we do not want clients wasting KDC > >>>>> resources by making multiple processes do the same operation. > >>>> > >>>> So apparently this patch never got reviewed over a year ago. > >>>> > >>>> It was related to a bug which was opened in SSSD. However, when > >>>> it became clear we wanted to solve this in FreeIPA, the SSSD bug > >>>> was closed but no corresponding FreeIPA bug was opened. The > >>>> patch then fell through the cracks. > >> > >> Right - without an associated ticket tracking the patch, it is too > >> easy to loose it unless the author prods people to review it. > >> > >>>> Without this patch, if OTP validation runs long we get > >>>> retransmits and failures. > >>>> > >>>> One question I have is how to handle this for upgrades since (I > >>>> think) this patch only handles new installs. > >>>> > >>>> Anyway, this patch is somewhat urgent now. So help is > >>>> appreciated. > >>>> > >>>> I have attached a rebased version which has no other changes. > >>>> > >>>> Nathaniel > >>> > >>> I am not sure we can do much on updates, we do not have a > >>> client-update tool, I would just document it I guess. > >>> Otherwise we'd have to go back to sssd which can inject additional > >>> values in krb5.conf, however I am not sure it would be ok to set > >>> something like this in the sssd's pubconf includes ... > >> > >> Agreed, pubconf update does not sound right. > >> > >> However, we already update krb5.conf on client updates, in %post: > >> > >> %post client > >> if [ $1 -gt 1 ] ; then > >> # Has the client been configured? > >> restore=0 > >> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && > >> restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | > >> awk '{print $1}') > >> > >> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > >> if ! grep -E -q > >> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > >> 2>/dev/null ; then > >> echo > >> "includedir /var/lib/sss/pubconf/krb5.include.d/" > >> > /etc/krb5.conf.ipanew cat /etc/krb5.conf >> /etc/krb5.conf.ipanew > >> mv /etc/krb5.conf.ipanew /etc/krb5.conf > >> /sbin/restorecon /etc/krb5.conf > >> fi > >> fi > >> ... > >> > >> > >> This particular update is more difficult as not a first line needs > >> to be changed. Without adding ipa client update tool with some > >> reasonable krb5.conf parser, we could do something along the lines > >> of > >> > >> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = > >> 0/g' /etc/krb5.conf > >> > >> (tested), but it is not pretty. > > > > What happen the next time you run it again ? > > > > Simo. > > > > It would of course be added again, you would need to first grep for > presence of udp_preference_limit setting. Question is if this > approach is safe enough to be in our client %post upgrade. We already > upgrade krb5.conf here, just the change is much easier as we just add > a line to the beginning of the file. Well the concern (aside of duplication) is that an admin may "correct" the krb5.conf file to remove that option (for example because his clients also connect to a differen (older) KDC and must use UDP in preference. But now we end up messing with its krb5.conf every time an update is released. An update tool that keep tracks of whether a specific update has already been applied and does not retry every time would be needed IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 7 13:53:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 14:53:17 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141107085129.77573940@willson.usersys.redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> Message-ID: <545CCECD.3040205@redhat.com> On 11/07/2014 02:51 PM, Simo Sorce wrote: > On Fri, 07 Nov 2014 14:26:06 +0100 > Martin Kosek wrote: > >> On 11/07/2014 02:20 PM, Simo Sorce wrote: >>> On Fri, 07 Nov 2014 08:02:02 +0100 >>> Martin Kosek wrote: >>> >>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: >>>>> On Thu, 06 Nov 2014 18:00:21 -0500 >>>>> Nathaniel McCallum wrote: >>>>> >>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>> Patch attached. >>>>>>>> >>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>> >>>>>>>> What is the expected performance impact? Could it be configured >>>>>>>> for OTP separately - somehow? (I guess that it is not possible >>>>>>>> now ...) >>>>>>> >>>>>>> It benefits also communication of large packets (when large >>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better >>>>>>> choice for IPA in general. Especially given we have multiple >>>>>>> KDC processes configured we do not want clients wasting KDC >>>>>>> resources by making multiple processes do the same operation. >>>>>> >>>>>> So apparently this patch never got reviewed over a year ago. >>>>>> >>>>>> It was related to a bug which was opened in SSSD. However, when >>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD bug >>>>>> was closed but no corresponding FreeIPA bug was opened. The >>>>>> patch then fell through the cracks. >>>> >>>> Right - without an associated ticket tracking the patch, it is too >>>> easy to loose it unless the author prods people to review it. >>>> >>>>>> Without this patch, if OTP validation runs long we get >>>>>> retransmits and failures. >>>>>> >>>>>> One question I have is how to handle this for upgrades since (I >>>>>> think) this patch only handles new installs. >>>>>> >>>>>> Anyway, this patch is somewhat urgent now. So help is >>>>>> appreciated. >>>>>> >>>>>> I have attached a rebased version which has no other changes. >>>>>> >>>>>> Nathaniel >>>>> >>>>> I am not sure we can do much on updates, we do not have a >>>>> client-update tool, I would just document it I guess. >>>>> Otherwise we'd have to go back to sssd which can inject additional >>>>> values in krb5.conf, however I am not sure it would be ok to set >>>>> something like this in the sssd's pubconf includes ... >>>> >>>> Agreed, pubconf update does not sound right. >>>> >>>> However, we already update krb5.conf on client updates, in %post: >>>> >>>> %post client >>>> if [ $1 -gt 1 ] ; then >>>> # Has the client been configured? >>>> restore=0 >>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && >>>> restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | >>>> awk '{print $1}') >>>> >>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >>>> if ! grep -E -q >>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >>>> 2>/dev/null ; then >>>> echo >>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" >>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf >> /etc/krb5.conf.ipanew >>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf >>>> /sbin/restorecon /etc/krb5.conf >>>> fi >>>> fi >>>> ... >>>> >>>> >>>> This particular update is more difficult as not a first line needs >>>> to be changed. Without adding ipa client update tool with some >>>> reasonable krb5.conf parser, we could do something along the lines >>>> of >>>> >>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = >>>> 0/g' /etc/krb5.conf >>>> >>>> (tested), but it is not pretty. >>> >>> What happen the next time you run it again ? >>> >>> Simo. >>> >> >> It would of course be added again, you would need to first grep for >> presence of udp_preference_limit setting. Question is if this >> approach is safe enough to be in our client %post upgrade. We already >> upgrade krb5.conf here, just the change is much easier as we just add >> a line to the beginning of the file. > > Well the concern (aside of duplication) is that an admin may "correct" > the krb5.conf file to remove that option (for example because his > clients also connect to a differen (older) KDC and must use UDP in > preference. But now we end up messing with its krb5.conf every time an > update is released. An update tool that keep tracks of whether a > specific update has already been applied and does not retry every time > would be needed IMO. > > Simo. In 4.1.x (as there is not much time to develop a separate client update tool), we could grep just for "udp_preference_limit" presence so that if admin changes it's value or comment it, it would not be added again. Martin From tbordaz at redhat.com Fri Nov 7 14:02:00 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 07 Nov 2014 15:02:00 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415117855.3318.3.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> Message-ID: <545CD0D8.9040903@redhat.com> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>> This patch gives the administrator variables to control the size of >>>>>> the authentication and synchronization windows for OTP tokens. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>> >>>>>> NOTE: There is one known issue with this patch which I don't know how to >>>>>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. >>>>>> On an upgrade, all of the new attributeTypes appear correctly. However, >>>>>> the modifications to the pre-existing objectClass do not show up on the >>>>>> server. What am I doing wrong? >>>>>> >>>>>> After modifying ipaGuiConfig manually, everything in this patch works >>>>>> just fine. >>>>> This new version takes into account the new (proper) OIDs and attribute >>>>> names. >>>> Thanks Nathaniel! >>>> >>>>> The above known issue still remains. >>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list extension >>>> should work just fine, AFAIK. >>> You added a blank line to the LDIF file. This is an entry separator, so >>> the objectClasses after the blank line don't belong to cn=schema, so >>> they aren't considered in the update. >>> Without the blank line it works fine. >> Thanks for the catch! >> >> Here is a version without the blank line. > I forgot to remove the old steps defines. This patch performs this > cleanup. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Few comments on the review: * in authcfg o in string_to_types, I would prefer you set the last element of 'map' to { NULL, 0 }. o in entry_to_window, you may declare the 'defaults' array as 'static const' o Would use define for "ipaUserAuthType","ipaHOTPAuthWindow", "ipaTOTPAuthWindow", "ipaHOTPSyncWindow","ipaTOTPSyncWindow" that are present multiple times o suffix_to_config: cfg is set (and returned) calling entry_to_config(entry). Now the entry_to_config returns a structure on the stack so it is not valid to access outside of the entry_to_config o authcfg_fini free the configs. config->cfg should have been allocated and must be freed (be care that configs->cfg may contains DEFAULTS) o authcfg_get_auth_types:322 should it return 'gbl' or AUTHCFG_AUTH_TYPE_PASSWORD o authcfg_get_auth_window/authcfg_get_sync_window returns a window structure that is on the stack. It is not valid outside of those functions thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Nov 7 14:03:11 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 7 Nov 2014 09:03:11 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <545CCECD.3040205@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> Message-ID: <20141107090311.6c430c54@willson.usersys.redhat.com> On Fri, 07 Nov 2014 14:53:17 +0100 Martin Kosek wrote: > On 11/07/2014 02:51 PM, Simo Sorce wrote: > > On Fri, 07 Nov 2014 14:26:06 +0100 > > Martin Kosek wrote: > > > >> On 11/07/2014 02:20 PM, Simo Sorce wrote: > >>> On Fri, 07 Nov 2014 08:02:02 +0100 > >>> Martin Kosek wrote: > >>> > >>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > >>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > >>>>> Nathaniel McCallum wrote: > >>>>> > >>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>>>>> Patch attached. > >>>>>>>> > >>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>>>>> second timeouts and re-transmits when OTP is in place? > >>>>>>>> > >>>>>>>> What is the expected performance impact? Could it be > >>>>>>>> configured for OTP separately - somehow? (I guess that it is > >>>>>>>> not possible now ...) > >>>>>>> > >>>>>>> It benefits also communication of large packets (when large > >>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better > >>>>>>> choice for IPA in general. Especially given we have multiple > >>>>>>> KDC processes configured we do not want clients wasting KDC > >>>>>>> resources by making multiple processes do the same operation. > >>>>>> > >>>>>> So apparently this patch never got reviewed over a year ago. > >>>>>> > >>>>>> It was related to a bug which was opened in SSSD. However, when > >>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD > >>>>>> bug was closed but no corresponding FreeIPA bug was opened. The > >>>>>> patch then fell through the cracks. > >>>> > >>>> Right - without an associated ticket tracking the patch, it is > >>>> too easy to loose it unless the author prods people to review it. > >>>> > >>>>>> Without this patch, if OTP validation runs long we get > >>>>>> retransmits and failures. > >>>>>> > >>>>>> One question I have is how to handle this for upgrades since (I > >>>>>> think) this patch only handles new installs. > >>>>>> > >>>>>> Anyway, this patch is somewhat urgent now. So help is > >>>>>> appreciated. > >>>>>> > >>>>>> I have attached a rebased version which has no other changes. > >>>>>> > >>>>>> Nathaniel > >>>>> > >>>>> I am not sure we can do much on updates, we do not have a > >>>>> client-update tool, I would just document it I guess. > >>>>> Otherwise we'd have to go back to sssd which can inject > >>>>> additional values in krb5.conf, however I am not sure it would > >>>>> be ok to set something like this in the sssd's pubconf > >>>>> includes ... > >>>> > >>>> Agreed, pubconf update does not sound right. > >>>> > >>>> However, we already update krb5.conf on client updates, in %post: > >>>> > >>>> %post client > >>>> if [ $1 -gt 1 ] ; then > >>>> # Has the client been configured? > >>>> restore=0 > >>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' > >>>> && restore=$(wc -l > >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print > >>>> $1}') > >>>> > >>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > >>>> if ! grep -E -q > >>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > >>>> 2>/dev/null ; then > >>>> echo > >>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > >>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > >>>>> >> /etc/krb5.conf.ipanew > >>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > >>>> /sbin/restorecon /etc/krb5.conf > >>>> fi > >>>> fi > >>>> ... > >>>> > >>>> > >>>> This particular update is more difficult as not a first line > >>>> needs to be changed. Without adding ipa client update tool with > >>>> some reasonable krb5.conf parser, we could do something along > >>>> the lines of > >>>> > >>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = > >>>> 0/g' /etc/krb5.conf > >>>> > >>>> (tested), but it is not pretty. > >>> > >>> What happen the next time you run it again ? > >>> > >>> Simo. > >>> > >> > >> It would of course be added again, you would need to first grep for > >> presence of udp_preference_limit setting. Question is if this > >> approach is safe enough to be in our client %post upgrade. We > >> already upgrade krb5.conf here, just the change is much easier as > >> we just add a line to the beginning of the file. > > > > Well the concern (aside of duplication) is that an admin may > > "correct" the krb5.conf file to remove that option (for example > > because his clients also connect to a differen (older) KDC and must > > use UDP in preference. But now we end up messing with its krb5.conf > > every time an update is released. An update tool that keep tracks > > of whether a specific update has already been applied and does not > > retry every time would be needed IMO. > > > > Simo. > > In 4.1.x (as there is not much time to develop a separate client > update tool), we could grep just for "udp_preference_limit" presence > so that if admin changes it's value or comment it, it would not be > added again. Ok then maybe we add this: # The following value has been added by a freeipa client update # if you want to disable it, please comment it, do not delete it # or it will be re-added on the next update udp_preference_limit = 0 What do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Nov 7 14:15:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 15:15:51 +0100 Subject: [Freeipa-devel] [PATCH 0159] FIX: DNS policy upgrade raises assertion error Message-ID: <545CD417.5040707@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4708 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0159-Fix-DNS-policy-upgrade-raises-asertion-error.patch Type: text/x-patch Size: 1005 bytes Desc: not available URL: From rcritten at redhat.com Fri Nov 7 14:19:12 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 Nov 2014 09:19:12 -0500 Subject: [Freeipa-devel] Gaps in upstream tests In-Reply-To: <545CCC22.9040501@redhat.com> References: <545CCC22.9040501@redhat.com> Message-ID: <545CD4E0.4070402@redhat.com> Martin Kosek wrote: > FreeIPA team will soon grow with a new member focusing on upstream QE > tests. I would like to collect ideas what are the biggest gaps in the > current upstream test suite from your POV. > > Existing requests are tracked here: > https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Tests&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=milestone&group=milestone&order=priority > > > First idea that I head proposed are Upgrade tests. These are often done > manually. I think that upgrade test from currently supported > FreeIPA/Fedora version would go a long way (like 3.3.5 on F20 upgraded > built RPMs and running unit tests). > > Second, it would be nice to try testing FreeIPA server in a container. > Not only it would verify our container efforts, but it may also allow > easy multi-master tests on one Jenkins VM or local host instead of > expensive VM orchestration. > > Any other areas worth focusing on (besides of course testing newly > developed features)? > Testing access control as non-admin. rob From mkosek at redhat.com Fri Nov 7 14:21:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 15:21:04 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141107090311.6c430c54@willson.usersys.redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> Message-ID: <545CD550.9090405@redhat.com> On 11/07/2014 03:03 PM, Simo Sorce wrote: > On Fri, 07 Nov 2014 14:53:17 +0100 > Martin Kosek wrote: > >> On 11/07/2014 02:51 PM, Simo Sorce wrote: >>> On Fri, 07 Nov 2014 14:26:06 +0100 >>> Martin Kosek wrote: >>> >>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: >>>>> On Fri, 07 Nov 2014 08:02:02 +0100 >>>>> Martin Kosek wrote: >>>>> >>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: >>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 >>>>>>> Nathaniel McCallum wrote: >>>>>>> >>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>>>> >>>>>>>>>> What is the expected performance impact? Could it be >>>>>>>>>> configured for OTP separately - somehow? (I guess that it is >>>>>>>>>> not possible now ...) >>>>>>>>> >>>>>>>>> It benefits also communication of large packets (when large >>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better >>>>>>>>> choice for IPA in general. Especially given we have multiple >>>>>>>>> KDC processes configured we do not want clients wasting KDC >>>>>>>>> resources by making multiple processes do the same operation. >>>>>>>> >>>>>>>> So apparently this patch never got reviewed over a year ago. >>>>>>>> >>>>>>>> It was related to a bug which was opened in SSSD. However, when >>>>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD >>>>>>>> bug was closed but no corresponding FreeIPA bug was opened. The >>>>>>>> patch then fell through the cracks. >>>>>> >>>>>> Right - without an associated ticket tracking the patch, it is >>>>>> too easy to loose it unless the author prods people to review it. >>>>>> >>>>>>>> Without this patch, if OTP validation runs long we get >>>>>>>> retransmits and failures. >>>>>>>> >>>>>>>> One question I have is how to handle this for upgrades since (I >>>>>>>> think) this patch only handles new installs. >>>>>>>> >>>>>>>> Anyway, this patch is somewhat urgent now. So help is >>>>>>>> appreciated. >>>>>>>> >>>>>>>> I have attached a rebased version which has no other changes. >>>>>>>> >>>>>>>> Nathaniel >>>>>>> >>>>>>> I am not sure we can do much on updates, we do not have a >>>>>>> client-update tool, I would just document it I guess. >>>>>>> Otherwise we'd have to go back to sssd which can inject >>>>>>> additional values in krb5.conf, however I am not sure it would >>>>>>> be ok to set something like this in the sssd's pubconf >>>>>>> includes ... >>>>>> >>>>>> Agreed, pubconf update does not sound right. >>>>>> >>>>>> However, we already update krb5.conf on client updates, in %post: >>>>>> >>>>>> %post client >>>>>> if [ $1 -gt 1 ] ; then >>>>>> # Has the client been configured? >>>>>> restore=0 >>>>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>>> && restore=$(wc -l >>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print >>>>>> $1}') >>>>>> >>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >>>>>> if ! grep -E -q >>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >>>>>> 2>/dev/null ; then >>>>>> echo >>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" >>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf >>>>>>>>> /etc/krb5.conf.ipanew >>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf >>>>>> /sbin/restorecon /etc/krb5.conf >>>>>> fi >>>>>> fi >>>>>> ... >>>>>> >>>>>> >>>>>> This particular update is more difficult as not a first line >>>>>> needs to be changed. Without adding ipa client update tool with >>>>>> some reasonable krb5.conf parser, we could do something along >>>>>> the lines of >>>>>> >>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = >>>>>> 0/g' /etc/krb5.conf >>>>>> >>>>>> (tested), but it is not pretty. >>>>> >>>>> What happen the next time you run it again ? >>>>> >>>>> Simo. >>>>> >>>> >>>> It would of course be added again, you would need to first grep for >>>> presence of udp_preference_limit setting. Question is if this >>>> approach is safe enough to be in our client %post upgrade. We >>>> already upgrade krb5.conf here, just the change is much easier as >>>> we just add a line to the beginning of the file. >>> >>> Well the concern (aside of duplication) is that an admin may >>> "correct" the krb5.conf file to remove that option (for example >>> because his clients also connect to a differen (older) KDC and must >>> use UDP in preference. But now we end up messing with its krb5.conf >>> every time an update is released. An update tool that keep tracks >>> of whether a specific update has already been applied and does not >>> retry every time would be needed IMO. >>> >>> Simo. >> >> In 4.1.x (as there is not much time to develop a separate client >> update tool), we could grep just for "udp_preference_limit" presence >> so that if admin changes it's value or comment it, it would not be >> added again. > > Ok then maybe we add this: > > # The following value has been added by a freeipa client update > # if you want to disable it, please comment it, do not delete it > # or it will be re-added on the next update > udp_preference_limit = 0 > > What do you think ? > Simo. > Sure, this could work (though it is quite lengthy). From mbasti at redhat.com Fri Nov 7 14:22:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 07 Nov 2014 15:22:40 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration Message-ID: <545CD5B0.3050002@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0158-Fix-upgrade-referint-plugin.patch Type: text/x-patch Size: 6108 bytes Desc: not available URL: From dkupka at redhat.com Fri Nov 7 14:26:24 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 07 Nov 2014 15:26:24 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. Message-ID: <545CD690.5030703@redhat.com> https://fedorahosted.org/freeipa/ticket/4611 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0027-Produce-better-error-in-group-add-command.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: From dkupka at redhat.com Fri Nov 7 14:28:17 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 07 Nov 2014 15:28:17 +0100 Subject: [Freeipa-devel] [PATCH] 0028 Remove unneeded internal methods. Move code to public, methods. Message-ID: <545CD701.5030909@redhat.com> -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0028-Remove-unneeded-internal-methods.-Move-code-to-publi.patch Type: text/x-patch Size: 2657 bytes Desc: not available URL: From npmccallum at redhat.com Fri Nov 7 14:28:57 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 7 Nov 2014 09:28:57 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <545CD550.9090405@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> Message-ID: <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> > On Nov 7, 2014, at 9:21 AM, Martin Kosek wrote: > > On 11/07/2014 03:03 PM, Simo Sorce wrote: >> On Fri, 07 Nov 2014 14:53:17 +0100 >> Martin Kosek wrote: >> >>> On 11/07/2014 02:51 PM, Simo Sorce wrote: >>>> On Fri, 07 Nov 2014 14:26:06 +0100 >>>> Martin Kosek wrote: >>>> >>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: >>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 >>>>>> Martin Kosek wrote: >>>>>> >>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: >>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 >>>>>>>> Nathaniel McCallum wrote: >>>>>>>> >>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>>>>> Patch attached. >>>>>>>>>>> >>>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>>>>> >>>>>>>>>>> What is the expected performance impact? Could it be >>>>>>>>>>> configured for OTP separately - somehow? (I guess that it is >>>>>>>>>>> not possible now ...) >>>>>>>>>> >>>>>>>>>> It benefits also communication of large packets (when large >>>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better >>>>>>>>>> choice for IPA in general. Especially given we have multiple >>>>>>>>>> KDC processes configured we do not want clients wasting KDC >>>>>>>>>> resources by making multiple processes do the same operation. >>>>>>>>> >>>>>>>>> So apparently this patch never got reviewed over a year ago. >>>>>>>>> >>>>>>>>> It was related to a bug which was opened in SSSD. However, when >>>>>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD >>>>>>>>> bug was closed but no corresponding FreeIPA bug was opened. The >>>>>>>>> patch then fell through the cracks. >>>>>>> >>>>>>> Right - without an associated ticket tracking the patch, it is >>>>>>> too easy to loose it unless the author prods people to review it. >>>>>>> >>>>>>>>> Without this patch, if OTP validation runs long we get >>>>>>>>> retransmits and failures. >>>>>>>>> >>>>>>>>> One question I have is how to handle this for upgrades since (I >>>>>>>>> think) this patch only handles new installs. >>>>>>>>> >>>>>>>>> Anyway, this patch is somewhat urgent now. So help is >>>>>>>>> appreciated. >>>>>>>>> >>>>>>>>> I have attached a rebased version which has no other changes. >>>>>>>>> >>>>>>>>> Nathaniel >>>>>>>> >>>>>>>> I am not sure we can do much on updates, we do not have a >>>>>>>> client-update tool, I would just document it I guess. >>>>>>>> Otherwise we'd have to go back to sssd which can inject >>>>>>>> additional values in krb5.conf, however I am not sure it would >>>>>>>> be ok to set something like this in the sssd's pubconf >>>>>>>> includes ... >>>>>>> >>>>>>> Agreed, pubconf update does not sound right. >>>>>>> >>>>>>> However, we already update krb5.conf on client updates, in %post: >>>>>>> >>>>>>> %post client >>>>>>> if [ $1 -gt 1 ] ; then >>>>>>> # Has the client been configured? >>>>>>> restore=0 >>>>>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>>>> && restore=$(wc -l >>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print >>>>>>> $1}') >>>>>>> >>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >>>>>>> if ! grep -E -q >>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >>>>>>> 2>/dev/null ; then >>>>>>> echo >>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" >>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf >>>>>>>>>> /etc/krb5.conf.ipanew >>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf >>>>>>> /sbin/restorecon /etc/krb5.conf >>>>>>> fi >>>>>>> fi >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> This particular update is more difficult as not a first line >>>>>>> needs to be changed. Without adding ipa client update tool with >>>>>>> some reasonable krb5.conf parser, we could do something along >>>>>>> the lines of >>>>>>> >>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = >>>>>>> 0/g' /etc/krb5.conf >>>>>>> >>>>>>> (tested), but it is not pretty. >>>>>> >>>>>> What happen the next time you run it again ? >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> It would of course be added again, you would need to first grep for >>>>> presence of udp_preference_limit setting. Question is if this >>>>> approach is safe enough to be in our client %post upgrade. We >>>>> already upgrade krb5.conf here, just the change is much easier as >>>>> we just add a line to the beginning of the file. >>>> >>>> Well the concern (aside of duplication) is that an admin may >>>> "correct" the krb5.conf file to remove that option (for example >>>> because his clients also connect to a differen (older) KDC and must >>>> use UDP in preference. But now we end up messing with its krb5.conf >>>> every time an update is released. An update tool that keep tracks >>>> of whether a specific update has already been applied and does not >>>> retry every time would be needed IMO. >>>> >>>> Simo. >>> >>> In 4.1.x (as there is not much time to develop a separate client >>> update tool), we could grep just for "udp_preference_limit" presence >>> so that if admin changes it's value or comment it, it would not be >>> added again. >> >> Ok then maybe we add this: >> >> # The following value has been added by a freeipa client update >> # if you want to disable it, please comment it, do not delete it >> # or it will be re-added on the next update >> udp_preference_limit = 0 >> >> What do you think ? >> Simo. >> > > Sure, this could work (though it is quite lengthy). I think it would be sufficient to only perform the addition of udp_preference_limit if it does not already exist and if the version number of the package we are upgrading from is less than the one where we introduced the change. Nathaniel From dkupka at redhat.com Fri Nov 7 14:29:36 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 07 Nov 2014 15:29:36 +0100 Subject: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link. Message-ID: <545CD750.5050207@redhat.com> Depends on freeipa-dkupka-0028. https://fedorahosted.org/freeipa/ticket/4658 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0029-Remove-service-file-even-if-it-isn-t-link.patch Type: text/x-patch Size: 1369 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 7 14:34:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 15:34:17 +0100 Subject: [Freeipa-devel] [PATCH 0307] Send DNS NOTIFY message after any modification to the zone Message-ID: <545CD869.5010402@redhat.com> Hello, Send DNS NOTIFY message after any modification to the zone. https://fedorahosted.org/bind-dyndb-ldap/ticket/144 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0307-Send-DNS-NOTIFY-message-after-any-modification-to-th.patch Type: text/x-patch Size: 3044 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 7 14:39:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Nov 2014 15:39:57 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> Message-ID: <545CD9BD.2090601@redhat.com> On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek wrote: >> >> On 11/07/2014 03:03 PM, Simo Sorce wrote: >>> On Fri, 07 Nov 2014 14:53:17 +0100 >>> Martin Kosek wrote: >>> >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 >>>>> Martin Kosek wrote: >>>>> >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 >>>>>>> Martin Kosek wrote: >>>>>>> >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 >>>>>>>>> Nathaniel McCallum wrote: >>>>>>>>> >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>>>>>> Patch attached. >>>>>>>>>>>> >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>>>>>> >>>>>>>>>>>> What is the expected performance impact? Could it be >>>>>>>>>>>> configured for OTP separately - somehow? (I guess that it is >>>>>>>>>>>> not possible now ...) >>>>>>>>>>> >>>>>>>>>>> It benefits also communication of large packets (when large >>>>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better >>>>>>>>>>> choice for IPA in general. Especially given we have multiple >>>>>>>>>>> KDC processes configured we do not want clients wasting KDC >>>>>>>>>>> resources by making multiple processes do the same operation. >>>>>>>>>> >>>>>>>>>> So apparently this patch never got reviewed over a year ago. >>>>>>>>>> >>>>>>>>>> It was related to a bug which was opened in SSSD. However, when >>>>>>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD >>>>>>>>>> bug was closed but no corresponding FreeIPA bug was opened. The >>>>>>>>>> patch then fell through the cracks. >>>>>>>> >>>>>>>> Right - without an associated ticket tracking the patch, it is >>>>>>>> too easy to loose it unless the author prods people to review it. >>>>>>>> >>>>>>>>>> Without this patch, if OTP validation runs long we get >>>>>>>>>> retransmits and failures. >>>>>>>>>> >>>>>>>>>> One question I have is how to handle this for upgrades since (I >>>>>>>>>> think) this patch only handles new installs. >>>>>>>>>> >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is >>>>>>>>>> appreciated. >>>>>>>>>> >>>>>>>>>> I have attached a rebased version which has no other changes. >>>>>>>>>> >>>>>>>>>> Nathaniel >>>>>>>>> >>>>>>>>> I am not sure we can do much on updates, we do not have a >>>>>>>>> client-update tool, I would just document it I guess. >>>>>>>>> Otherwise we'd have to go back to sssd which can inject >>>>>>>>> additional values in krb5.conf, however I am not sure it would >>>>>>>>> be ok to set something like this in the sssd's pubconf >>>>>>>>> includes ... >>>>>>>> >>>>>>>> Agreed, pubconf update does not sound right. >>>>>>>> >>>>>>>> However, we already update krb5.conf on client updates, in %post: >>>>>>>> >>>>>>>> %post client >>>>>>>> if [ $1 -gt 1 ] ; then >>>>>>>> # Has the client been configured? >>>>>>>> restore=0 >>>>>>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>>>>> && restore=$(wc -l >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print >>>>>>>> $1}') >>>>>>>> >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >>>>>>>> if ! grep -E -q >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >>>>>>>> 2>/dev/null ; then >>>>>>>> echo >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf >>>>>>>>>>> /etc/krb5.conf.ipanew >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf >>>>>>>> /sbin/restorecon /etc/krb5.conf >>>>>>>> fi >>>>>>>> fi >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> This particular update is more difficult as not a first line >>>>>>>> needs to be changed. Without adding ipa client update tool with >>>>>>>> some reasonable krb5.conf parser, we could do something along >>>>>>>> the lines of >>>>>>>> >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = >>>>>>>> 0/g' /etc/krb5.conf >>>>>>>> >>>>>>>> (tested), but it is not pretty. >>>>>>> >>>>>>> What happen the next time you run it again ? >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> It would of course be added again, you would need to first grep for >>>>>> presence of udp_preference_limit setting. Question is if this >>>>>> approach is safe enough to be in our client %post upgrade. We >>>>>> already upgrade krb5.conf here, just the change is much easier as >>>>>> we just add a line to the beginning of the file. >>>>> >>>>> Well the concern (aside of duplication) is that an admin may >>>>> "correct" the krb5.conf file to remove that option (for example >>>>> because his clients also connect to a differen (older) KDC and must >>>>> use UDP in preference. But now we end up messing with its krb5.conf >>>>> every time an update is released. An update tool that keep tracks >>>>> of whether a specific update has already been applied and does not >>>>> retry every time would be needed IMO. >>>>> >>>>> Simo. >>>> >>>> In 4.1.x (as there is not much time to develop a separate client >>>> update tool), we could grep just for "udp_preference_limit" presence >>>> so that if admin changes it's value or comment it, it would not be >>>> added again. >>> >>> Ok then maybe we add this: >>> >>> # The following value has been added by a freeipa client update >>> # if you want to disable it, please comment it, do not delete it >>> # or it will be re-added on the next update >>> udp_preference_limit = 0 >>> >>> What do you think ? >>> Simo. >>> >> >> Sure, this could work (though it is quite lengthy). > > I think it would be sufficient to only perform the addition of udp_preference_limit if it does not already exist and if the version number of the package we are upgrading from is less than the one where we introduced the change. > > Nathaniel > Or to simply call python and get the value of our state store keeping track what was done on upgrades. This would work: # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" # echo $? 0 # python2 -c "from ipaserver.install import sysupgrade; sysupgrade.set_upgrade_state('krb5.conf', 'udp_preference_limit_set', True)" # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" # echo $? 1 You would just need to come up with something that's present on the client, this is just on the server sub package. Martin From pvoborni at redhat.com Fri Nov 7 15:44:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 07 Nov 2014 16:44:41 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <545C7BC0.80205@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> Message-ID: <545CE8E9.2030009@redhat.com> On 7.11.2014 08:58, Martin Kosek wrote: > On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>> This patch gives the administrator variables to control the size of >>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>> >>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>> how to >>>>>>> solve. This patch changes the schema in >>>>>>> install/share/60ipaconfig.ldif. >>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>> However, >>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>> on the >>>>>>> server. What am I doing wrong? >>>>>>> >>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>> works >>>>>>> just fine. >>>>>> >>>>>> This new version takes into account the new (proper) OIDs and >>>>>> attribute >>>>>> names. >>>>> >>>>> Thanks Nathaniel! >>>>> >>>>>> The above known issue still remains. >>>>> >>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>> extension >>>>> should work just fine, AFAIK. >>>> >>>> You added a blank line to the LDIF file. This is an entry separator, so >>>> the objectClasses after the blank line don't belong to cn=schema, so >>>> they aren't considered in the update. >>>> Without the blank line it works fine. >>> >>> Thanks for the catch! >>> >>> Here is a version without the blank line. >> >> I forgot to remove the old steps defines. This patch performs this >> cleanup. > > I am now wondering, is the global config object really the nest place to > add these OTP specific settings? > > I would prefer not to overload the object and instead: > - create new ipaOTPConfig objectclass > - add it to cn=otp,$SUFFIX > - create otpconfig-mod and otpconfig-show commands to follow an example > of dnsconfig-* and trustconfig-* commands > > IMO, this would allow more flexibility for the OTP settings and would > also scale better for the future updates. +1 I will comment the patch as if ^^ would not exist because it will still be needed in the new plugin. Because of ^^ I did not test, just read. 1. Got: install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not recommended in array initializers Please run: jsl -nofilelisting -nosummary -nologo -conf jsl.conf in install/ui directory The goal is no have no warnings and errors. 2. new attrs should be added to 'System: Read Global Configuration' managed permission -- Petr Vobornik From npmccallum at redhat.com Fri Nov 7 15:51:18 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 07 Nov 2014 10:51:18 -0500 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location Message-ID: <1415375478.8166.1.camel@redhat.com> https://fedorahosted.org/freeipa/ticket/4693 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0079-Catch-USBError-during-YubiKey-location.patch Type: text/x-patch Size: 1132 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 7 15:55:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 07 Nov 2014 16:55:14 +0100 Subject: [Freeipa-devel] [PATCH 0021] Fix minimal version of BIND for Fedora 20 and 21 Message-ID: <545CEB62.1010606@redhat.com> Hello, Fix minimal version of BIND for Fedora 20 and 21. We should build new mkosek/freeipa COPR package ASAP to solve conflicts on upgrade. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0021-Fix-minimal-version-of-BIND-for-Fedora-20-and-21.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: From npmccallum at redhat.com Fri Nov 7 15:57:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 07 Nov 2014 10:57:23 -0500 Subject: [Freeipa-devel] [PATCH 0021] Fix minimal version of BIND for Fedora 20 and 21 In-Reply-To: <545CEB62.1010606@redhat.com> References: <545CEB62.1010606@redhat.com> Message-ID: <1415375843.8166.2.camel@redhat.com> On Fri, 2014-11-07 at 16:55 +0100, Petr Spacek wrote: > Hello, > > Fix minimal version of BIND for Fedora 20 and 21. > > We should build new mkosek/freeipa COPR package ASAP to solve conflicts on > upgrade. ACK From pvoborni at redhat.com Fri Nov 7 16:14:32 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 07 Nov 2014 17:14:32 +0100 Subject: [Freeipa-devel] [PATCH 0021] Fix minimal version of BIND for Fedora 20 and 21 In-Reply-To: <1415375843.8166.2.camel@redhat.com> References: <545CEB62.1010606@redhat.com> <1415375843.8166.2.camel@redhat.com> Message-ID: <545CEFE8.6060008@redhat.com> On 7.11.2014 16:57, Nathaniel McCallum wrote: > On Fri, 2014-11-07 at 16:55 +0100, Petr Spacek wrote: >> Hello, >> >> Fix minimal version of BIND for Fedora 20 and 21. >> >> We should build new mkosek/freeipa COPR package ASAP to solve conflicts on >> upgrade. > > ACK > Pushed to: ipa-4-1: 4662f28750e5d68cc268a090d5612d6cfb51e3e1 master: 74e0a8cebca251bf89144597f521440407a469ba -- Petr Vobornik From redhatrises at gmail.com Fri Nov 7 16:18:09 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 7 Nov 2014 09:18:09 -0700 Subject: [Freeipa-devel] [PATCH 0035] fix misleading Directory Manager --help output Message-ID: Hello. Fix for https://fedorahosted.org/freeipa/ticket/4694 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0035-ipa-server-install-Directory-Manager-help-incorrect.patch Type: text/x-patch Size: 1179 bytes Desc: not available URL: From npmccallum at redhat.com Fri Nov 7 16:40:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 07 Nov 2014 11:40:17 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <545CD0D8.9040903@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545CD0D8.9040903@redhat.com> Message-ID: <1415378417.8166.4.camel@redhat.com> On Fri, 2014-11-07 at 15:02 +0100, thierry bordaz wrote: > On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > > > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > > > On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > > > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > > > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > > > > > On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > > > > > > This patch gives the administrator variables to control the size of > > > > > > > the authentication and synchronization windows for OTP tokens. > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/4511 > > > > > > > > > > > > > > NOTE: There is one known issue with this patch which I don't know how to > > > > > > > solve. This patch changes the schema in install/share/60ipaconfig.ldif. > > > > > > > On an upgrade, all of the new attributeTypes appear correctly. However, > > > > > > > the modifications to the pre-existing objectClass do not show up on the > > > > > > > server. What am I doing wrong? > > > > > > > > > > > > > > After modifying ipaGuiConfig manually, everything in this patch works > > > > > > > just fine. > > > > > > This new version takes into account the new (proper) OIDs and attribute > > > > > > names. > > > > > Thanks Nathaniel! > > > > > > > > > > > The above known issue still remains. > > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list extension > > > > > should work just fine, AFAIK. > > > > You added a blank line to the LDIF file. This is an entry separator, so > > > > the objectClasses after the blank line don't belong to cn=schema, so > > > > they aren't considered in the update. > > > > Without the blank line it works fine. > > > Thanks for the catch! > > > > > > Here is a version without the blank line. > > I forgot to remove the old steps defines. This patch performs this > > cleanup. > > > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello Nathaniel, > > Few comments on the review: > * in authcfg > * in string_to_types, I would prefer you set the > last element of 'map' to { NULL, 0 }. Why? What I have is perfectly legal ISO C and is exactly the equivalent of your code. In a structure initializer, undefined structure elements are zero'd. > * in entry_to_window, you may declare the > 'defaults' array as 'static const' Fixed. > * Would use define for > "ipaUserAuthType","ipaHOTPAuthWindow", > "ipaTOTPAuthWindow", > "ipaHOTPSyncWindow","ipaTOTPSyncWindow" that > are present multiple times Fixed. > * suffix_to_config: cfg is set (and returned) > calling entry_to_config(entry). Now the > entry_to_config returns a structure on the > stack so it is not valid to access outside of > the entry_to_config Nope. We are not passing by reference but by copy. This is perfectly valid C. > * authcfg_fini free the configs. config->cfg > should have been allocated and must be freed > (be care that configs->cfg may contains > DEFAULTS) Nope. The config->cfg structure is allocated and freed when config is. This is assignment by copy not by reference. > * authcfg_get_auth_types:322 should it return > 'gbl' or AUTHCFG_AUTH_TYPE_PASSWORD If both the global and per-user auth type is unset, the default is AUTHCFG_AUTH_TYPE_PASSWORD. We special case this here so that we don't have to special case it everywhere else in the code. The code is correct as stands. > * authcfg_get_auth_window/authcfg_get_sync_window returns a window structure that is on the stack. It is not valid outside of those functions Nope. Structure return by copy is perfectly legal ISO C. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0074.4-Make-token-window-sizes-configurable.patch Type: text/x-patch Size: 38126 bytes Desc: not available URL: From tbordaz at redhat.com Fri Nov 7 17:50:02 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 07 Nov 2014 18:50:02 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415378417.8166.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545CD0D8.9040903@redhat.com> <1415378417.8166.4.camel@redhat.com> Message-ID: <545D064A.5050209@redhat.com> On 11/07/2014 05:40 PM, Nathaniel McCallum wrote: > On Fri, 2014-11-07 at 15:02 +0100, thierry bordaz wrote: >> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >> >>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>> >>>>>>>> NOTE: There is one known issue with this patch which I don't know how to >>>>>>>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. >>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. However, >>>>>>>> the modifications to the pre-existing objectClass do not show up on the >>>>>>>> server. What am I doing wrong? >>>>>>>> >>>>>>>> After modifying ipaGuiConfig manually, everything in this patch works >>>>>>>> just fine. >>>>>>> This new version takes into account the new (proper) OIDs and attribute >>>>>>> names. >>>>>> Thanks Nathaniel! >>>>>> >>>>>>> The above known issue still remains. >>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list extension >>>>>> should work just fine, AFAIK. >>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>> they aren't considered in the update. >>>>> Without the blank line it works fine. >>>> Thanks for the catch! >>>> >>>> Here is a version without the blank line. >>> I forgot to remove the old steps defines. This patch performs this >>> cleanup. >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello Nathaniel, >> >> Few comments on the review: >> * in authcfg >> * in string_to_types, I would prefer you set the >> last element of 'map' to { NULL, 0 }. > Why? What I have is perfectly legal ISO C and is exactly the equivalent > of your code. In a structure initializer, undefined structure elements > are zero'd. > >> * in entry_to_window, you may declare the >> 'defaults' array as 'static const' > Fixed. > >> * Would use define for >> "ipaUserAuthType","ipaHOTPAuthWindow", >> "ipaTOTPAuthWindow", >> "ipaHOTPSyncWindow","ipaTOTPSyncWindow" that >> are present multiple times > Fixed. > >> * suffix_to_config: cfg is set (and returned) >> calling entry_to_config(entry). Now the >> entry_to_config returns a structure on the >> stack so it is not valid to access outside of >> the entry_to_config > Nope. We are not passing by reference but by copy. This is perfectly > valid C. > >> * authcfg_fini free the configs. config->cfg >> should have been allocated and must be freed >> (be care that configs->cfg may contains >> DEFAULTS) > Nope. The config->cfg structure is allocated and freed when config is. > This is assignment by copy not by reference. > >> * authcfg_get_auth_types:322 should it return >> 'gbl' or AUTHCFG_AUTH_TYPE_PASSWORD > If both the global and per-user auth type is unset, the default is > AUTHCFG_AUTH_TYPE_PASSWORD. We special case this here so that we don't > have to special case it everywhere else in the code. The code is correct > as stands. > >> * authcfg_get_auth_window/authcfg_get_sync_window returns a window structure that is on the stack. It is not valid outside of those functions > Nope. Structure return by copy is perfectly legal ISO C. Hi Nathaniel, You are right, I am not use to structure assignment and all these assignments are valid. Sorry for the noise. The patch is fine for me. thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Nov 8 13:43:38 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 8 Nov 2014 14:43:38 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <5445175E.3090905@redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> Message-ID: <20141108134338.GA19510@mail.corp.redhat.com> On (20/10/14 16:08), Martin Kosek wrote: >On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>> >>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>> be usable on F20). >> >> And RHEL 7 / CentOS 7? > >For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >"mkosek/freeipa" repo. > It is almost 3 weeks from this mail and freeipa-server cannot be installed from "mkosek/freeipa" repo on RHEL/CentOS 7.0. bash-4.2# yum install freeipa-server //snip ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch --> Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) Requires: jackson-jaxrs-json-provider You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest There were some promises on freeipa-users but nothing has changed. Is somebody working on this problem? Maybe it is another candidate for inegtation tests. LS From mkosek at redhat.com Sun Nov 9 09:09:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Sun, 09 Nov 2014 10:09:09 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <20141108134338.GA19510@mail.corp.redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> <20141108134338.GA19510@mail.corp.redhat.com> Message-ID: <545F2F35.7050807@redhat.com> On 11/08/2014 02:43 PM, Lukas Slebodnik wrote: > On (20/10/14 16:08), Martin Kosek wrote: >> On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >>> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>>> >>>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>>> be usable on F20). >>> >>> And RHEL 7 / CentOS 7? >> >> For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >> "mkosek/freeipa" repo. >> > It is almost 3 weeks from this mail and freeipa-server cannot be installed from > "mkosek/freeipa" repo on RHEL/CentOS 7.0. > > bash-4.2# yum install freeipa-server > //snip > > ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed > --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch > --> Finished Dependency Resolution > Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) > Requires: jackson-jaxrs-json-provider > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > There were some promises on freeipa-users but nothing has changed. > > Is somebody working on this problem? > Maybe it is another candidate for inegtation tests. > > LS This problem is known, but it is not simple one to solve. jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the package set on EL 7.0 which however brings a lot of and other build/runtime dependencies. Question is how to solve this properly, this still needs some work and discussion to happen as current approach obviously do not scale, as you noticed. For now, the biggest priority for the team is to work on FreeIPA 4.1.x stabilization release and fix any remaining issues for Fedora 21. Martin From jcholast at redhat.com Mon Nov 10 07:14:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:14:04 +0100 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location In-Reply-To: <1415375478.8166.1.camel@redhat.com> References: <1415375478.8166.1.camel@redhat.com> Message-ID: <546065BC.1010607@redhat.com> Hi, Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a): > https://fedorahosted.org/freeipa/ticket/4693 Is it good enough to just say "No YubiKey found"? Would it make sense to log the original message, for the sake of debugging why the yubikey was not found? Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 10 07:20:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:20:32 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. In-Reply-To: <545CD690.5030703@redhat.com> References: <545CD690.5030703@redhat.com> Message-ID: <54606740.7070104@redhat.com> Hi, Dne 7.11.2014 v 15:26 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4611 I think you should use MutuallyExclusiveError. Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 10 07:21:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:21:32 +0100 Subject: [Freeipa-devel] [PATCH] 0028 Remove unneeded internal methods. Move code to public, methods. In-Reply-To: <545CD701.5030909@redhat.com> References: <545CD701.5030909@redhat.com> Message-ID: <5460677C.1050303@redhat.com> Hi, ACK. -- Jan Cholasta From jcholast at redhat.com Mon Nov 10 07:25:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:25:23 +0100 Subject: [Freeipa-devel] [PATCH 0035] fix misleading Directory Manager --help output In-Reply-To: References: Message-ID: <54606863.4050807@redhat.com> Hi, Dne 7.11.2014 v 17:18 Gabe Alford napsal(a): > Hello. > > Fix for https://fedorahosted.org/freeipa/ticket/4694 > > Thanks, > > Gabe ACK. Honza -- Jan Cholasta From mkosek at redhat.com Mon Nov 10 07:28:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 08:28:50 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <545CE8E9.2030009@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> Message-ID: <54606932.1030809@redhat.com> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > On 7.11.2014 08:58, Martin Kosek wrote: >> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>> >>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>> how to >>>>>>>> solve. This patch changes the schema in >>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>> However, >>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>> on the >>>>>>>> server. What am I doing wrong? >>>>>>>> >>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>> works >>>>>>>> just fine. >>>>>>> >>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>> attribute >>>>>>> names. >>>>>> >>>>>> Thanks Nathaniel! >>>>>> >>>>>>> The above known issue still remains. >>>>>> >>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>> extension >>>>>> should work just fine, AFAIK. >>>>> >>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>> they aren't considered in the update. >>>>> Without the blank line it works fine. >>>> >>>> Thanks for the catch! >>>> >>>> Here is a version without the blank line. >>> >>> I forgot to remove the old steps defines. This patch performs this >>> cleanup. >> >> I am now wondering, is the global config object really the nest place to >> add these OTP specific settings? >> >> I would prefer not to overload the object and instead: >> - create new ipaOTPConfig objectclass >> - add it to cn=otp,$SUFFIX >> - create otpconfig-mod and otpconfig-show commands to follow an example >> of dnsconfig-* and trustconfig-* commands >> >> IMO, this would allow more flexibility for the OTP settings and would >> also scale better for the future updates. > > +1 > > I will comment the patch as if ^^ would not exist because it will still be > needed in the new plugin. > > Because of ^^ I did not test, just read. > > 1. Got: > install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > recommended in array initializers > > Please run: > jsl -nofilelisting -nosummary -nologo -conf jsl.conf > in install/ui directory > > The goal is no have no warnings and errors. > > 2. new attrs should be added to 'System: Read Global Configuration' managed > permission +1. Though if we go with OTP config, it should be called System: Read OTP Configuration Martin From jcholast at redhat.com Mon Nov 10 07:30:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:30:05 +0100 Subject: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link. In-Reply-To: <545CD750.5050207@redhat.com> References: <545CD750.5050207@redhat.com> Message-ID: <5460697D.3030902@redhat.com> Hi, Dne 7.11.2014 v 15:29 David Kupka napsal(a): > Depends on freeipa-dkupka-0028. > https://fedorahosted.org/freeipa/ticket/4658 ACK. Honza -- Jan Cholasta From abokovoy at redhat.com Mon Nov 10 07:31:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Nov 2014 09:31:23 +0200 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location In-Reply-To: <546065BC.1010607@redhat.com> References: <1415375478.8166.1.camel@redhat.com> <546065BC.1010607@redhat.com> Message-ID: <20141110073123.GE4107@redhat.com> On Mon, 10 Nov 2014, Jan Cholasta wrote: >Hi, > >Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a): >>https://fedorahosted.org/freeipa/ticket/4693 > >Is it good enough to just say "No YubiKey found"? Would it make sense >to log the original message, for the sake of debugging why the yubikey >was not found? This is logged on the client side so it only would be visible if you would run 'ipa' tool with -v. Perhaps useful but my practice with yubikeys says that most of issues are basically permission-related: you've inserted the key and udev rules didn't change access to allow getting to it via libusb. In this case our debugging will hardly be helpful beyond 'yes, it is not accessible' which is already conveyed by the original message. -- / Alexander Bokovoy From jcholast at redhat.com Mon Nov 10 07:36:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:36:33 +0100 Subject: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them In-Reply-To: <1414182086.13428.7.camel@redhat.com> References: <1414182086.13428.7.camel@redhat.com> Message-ID: <54606B01.1000202@redhat.com> Hi, Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): > https://fedorahosted.org/freeipa/ticket/4642 please use "userobj.handle_not_found(owner)" instead of raising NotFound manually. Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 10 07:44:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 08:44:00 +0100 Subject: [Freeipa-devel] [PATCH 0077] Improve otptoken help messages In-Reply-To: <1415305490.3273.6.camel@redhat.com> References: <1415305490.3273.6.camel@redhat.com> Message-ID: <54606CC0.8060803@redhat.com> Hi, Dne 6.11.2014 v 21:24 Nathaniel McCallum napsal(a): > https://fedorahosted.org/freeipa/ticket/4689 we don't usually use the "Set the" prefix in doc kwargs, so IMO it should not be used here as well. Honza -- Jan Cholasta From mkosek at redhat.com Mon Nov 10 08:08:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 09:08:40 +0100 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location In-Reply-To: <20141110073123.GE4107@redhat.com> References: <1415375478.8166.1.camel@redhat.com> <546065BC.1010607@redhat.com> <20141110073123.GE4107@redhat.com> Message-ID: <54607288.7040009@redhat.com> On 11/10/2014 08:31 AM, Alexander Bokovoy wrote: > On Mon, 10 Nov 2014, Jan Cholasta wrote: >> Hi, >> >> Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4693 >> >> Is it good enough to just say "No YubiKey found"? Would it make sense to log >> the original message, for the sake of debugging why the yubikey was not found? > This is logged on the client side so it only would be visible if you > would run 'ipa' tool with -v. Perhaps useful but my practice with > yubikeys says that most of issues are basically permission-related: > you've inserted the key and udev rules didn't change access to allow > getting to it via libusb. In this case our debugging will hardly be > helpful beyond 'yes, it is not accessible' which is already conveyed by > the original message. Ok. Though IMO, passing the USBError string to the error would still be a good thing to do - unless we have a strong reason to hide it. Error stating "Access denied (insufficient permissions)" would steer the person closer to the root cause that just "No YubiKey found". From mkosek at redhat.com Mon Nov 10 08:36:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 09:36:43 +0100 Subject: [Freeipa-devel] [PATCH 0021] Fix minimal version of BIND for Fedora 20 and 21 In-Reply-To: <545CEFE8.6060008@redhat.com> References: <545CEB62.1010606@redhat.com> <1415375843.8166.2.camel@redhat.com> <545CEFE8.6060008@redhat.com> Message-ID: <5460791B.40001@redhat.com> On 11/07/2014 05:14 PM, Petr Vobornik wrote: > On 7.11.2014 16:57, Nathaniel McCallum wrote: >> On Fri, 2014-11-07 at 16:55 +0100, Petr Spacek wrote: >>> Hello, >>> >>> Fix minimal version of BIND for Fedora 20 and 21. >>> >>> We should build new mkosek/freeipa COPR package ASAP to solve conflicts on >>> upgrade. >> >> ACK >> > > Pushed to: > ipa-4-1: 4662f28750e5d68cc268a090d5612d6cfb51e3e1 > master: 74e0a8cebca251bf89144597f521440407a469ba I added this patch to F21&rawhide and fired a new build in the COPR. Martin From lslebodn at redhat.com Mon Nov 10 09:09:26 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 10 Nov 2014 10:09:26 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <545F2F35.7050807@redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> <20141108134338.GA19510@mail.corp.redhat.com> <545F2F35.7050807@redhat.com> Message-ID: <20141110090926.GB9637@mail.corp.redhat.com> On (09/11/14 10:09), Martin Kosek wrote: >On 11/08/2014 02:43 PM, Lukas Slebodnik wrote: >>On (20/10/14 16:08), Martin Kosek wrote: >>>On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >>>>On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>>>> >>>>>The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>>>>go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>>>>be usable on F20). >>>> >>>>And RHEL 7 / CentOS 7? >>> >>>For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >>>"mkosek/freeipa" repo. >>> >>It is almost 3 weeks from this mail and freeipa-server cannot be installed from >>"mkosek/freeipa" repo on RHEL/CentOS 7.0. >> >>bash-4.2# yum install freeipa-server >>//snip >> >>---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed >>--> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch >>--> Finished Dependency Resolution >>Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) >> Requires: jackson-jaxrs-json-provider >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >>There were some promises on freeipa-users but nothing has changed. >> >>Is somebody working on this problem? >>Maybe it is another candidate for inegtation tests. >> >>LS > >This problem is known, but it is not simple one to solve. >jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the >package set on EL 7.0 which however brings a lot of and other build/runtime >dependencies. > Agree. I just want to find solution and help desperate users on CentOS 7. >Question is how to solve this properly, this still needs some work and >discussion to happen as current approach obviously do not scale, as you >noticed. > IMHO, the best solution would be to separate dogtag from freeipa yum repo. Pros: * It would reduce dependency in freeipa repo * dogtag team would maintain separate COPR repo for older distributions. (they know better about new dependencies and java packaging) Cons: Two COPR repositories would need to be enabled for installing latest freeipa. LS From mkosek at redhat.com Mon Nov 10 09:18:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 10:18:45 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <20141110090926.GB9637@mail.corp.redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> <20141108134338.GA19510@mail.corp.redhat.com> <545F2F35.7050807@redhat.com> <20141110090926.GB9637@mail.corp.redhat.com> Message-ID: <546082F5.6070501@redhat.com> On 11/10/2014 10:09 AM, Lukas Slebodnik wrote: > On (09/11/14 10:09), Martin Kosek wrote: >> On 11/08/2014 02:43 PM, Lukas Slebodnik wrote: >>> On (20/10/14 16:08), Martin Kosek wrote: >>>> On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >>>>> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>>>>> >>>>>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>>>>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>>>>> be usable on F20). >>>>> >>>>> And RHEL 7 / CentOS 7? >>>> >>>> For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >>>> "mkosek/freeipa" repo. >>>> >>> It is almost 3 weeks from this mail and freeipa-server cannot be installed from >>> "mkosek/freeipa" repo on RHEL/CentOS 7.0. >>> >>> bash-4.2# yum install freeipa-server >>> //snip >>> >>> ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed >>> --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch >>> --> Finished Dependency Resolution >>> Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) >>> Requires: jackson-jaxrs-json-provider >>> You could try using --skip-broken to work around the problem >>> You could try running: rpm -Va --nofiles --nodigest >>> >>> There were some promises on freeipa-users but nothing has changed. >>> >>> Is somebody working on this problem? >>> Maybe it is another candidate for inegtation tests. >>> >>> LS >> >> This problem is known, but it is not simple one to solve. >> jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the >> package set on EL 7.0 which however brings a lot of and other build/runtime >> dependencies. >> > Agree. > I just want to find solution and help desperate users on CentOS 7. +1, me too. >> Question is how to solve this properly, this still needs some work and >> discussion to happen as current approach obviously do not scale, as you >> noticed. >> > IMHO, the best solution would be to separate dogtag from freeipa yum repo. > Pros: > * It would reduce dependency in freeipa repo > * dogtag team would maintain separate COPR repo for older distributions. > (they know better about new dependencies and java packaging) That makes sense, yes. I was thinking along these lines yesterday too. > Cons: > Two COPR repositories would need to be enabled for installing latest > freeipa. Exactly. With multiple required repos, those may quickly get out of sync with regards to suppoted architectures or expectations about these repos. However, if we agree on the expectations with the PKI team, could IPA own cronjob that would watch PKI Copr repo on specified arches and rebuild it for the common one using PKI team SRPMs? Martin From mkosek at redhat.com Mon Nov 10 11:07:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 12:07:46 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan Message-ID: <54609C82.7070403@redhat.com> Hi guys, Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a target to have the latest greatest FreeIPA available for older arches (read - RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20) try FreeIPA 4.0+ releases which brought in several dependencies. So far this was a more ad hoc approach, I think a more firm plan and tools are due. I see several questions that needs to be decided: 1) What Copr repos do we want to maintain and what should be the expectations? My take: a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? Does it fit your needs? b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and greatest release, would it make sense to have a Copr repo with *releases* per supported branch to give users a choice? I.e. * mkosek/freeipa-4.1 * mkosek/freeipa-4.0 These repos are there already, but not used consistently. I do not think we should build all the dependency chain (too much overhead) for older systems (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for these systems if it uses "mkosek/freeipa" as additional build root in Copr. c) Daily repos Should we deprecate old John's repos (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to maintain and replace them with Copr ones? I.e. to have common repo (e.g. mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM) including dependencies? Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across projects "mkosek/freeipa-master", "someone/sssd-master", "someone/389-ds-base-master? Second option may scale better better, the list of such repos may be maintained somewhere (freeipa.org wiki). 2) We will need to have some tool chain and Jenkins CI jobs watching these repos to make sure the build & run deps are OK. So far I used the attached 2 clumsy bash scripts to handle the repos build and one for analysis. But we will need something better. 3) Scalability of the approach Some dependencies are more difficult to maintain than the others. Especially the PKI ones often required custom Java packaging (resteasy-base) or a complicated dependency chain (the latest jackson-jaxrs-json-provider). It would be great if PKI team helps with this effort, as Lukas proposed. Downside is that mkosek/freeipa installation would require 2 Copr repos. But maybe we could have a job syncing the PKI build/runtime dependencies directly to FreeIPA copr. Whatever works and scale. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: build-srpms.sh Type: application/x-sh Size: 443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check-status.py Type: text/x-python Size: 3069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prep-srpms.sh Type: application/x-sh Size: 1998 bytes Desc: not available URL: From dkupka at redhat.com Mon Nov 10 12:24:49 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 10 Nov 2014 13:24:49 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. In-Reply-To: <54606740.7070104@redhat.com> References: <545CD690.5030703@redhat.com> <54606740.7070104@redhat.com> Message-ID: <5460AE91.2010204@redhat.com> On 11/10/2014 08:20 AM, Jan Cholasta wrote: > Hi, > > Dne 7.11.2014 v 15:26 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4611 > > I think you should use MutuallyExclusiveError. > > Honza > Thanks, that's the error class I was searching for. Unfortunately, I didn't know this one so I used more abstract error class. Fixed patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0027-2-Produce-better-error-in-group-add-command.patch Type: text/x-patch Size: 1083 bytes Desc: not available URL: From jhrozek at redhat.com Mon Nov 10 12:49:35 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Nov 2014 13:49:35 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <54609C82.7070403@redhat.com> References: <54609C82.7070403@redhat.com> Message-ID: <20141110124935.GG5577@hendrix.brq.redhat.com> On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote: > Hi guys, > > Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a > target to have the latest greatest FreeIPA available for older arches (read - > RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20) > try FreeIPA 4.0+ releases which brought in several dependencies. > > So far this was a more ad hoc approach, I think a more firm plan and tools are > due. I see several questions that needs to be decided: > > 1) What Copr repos do we want to maintain and what should be the expectations? > My take: > > a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, > EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? > Does it fit your needs? +1 > > b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and > greatest release, would it make sense to have a Copr repo with *releases* per > supported branch to give users a choice? I.e. > * mkosek/freeipa-4.1 > * mkosek/freeipa-4.0 > These repos are there already, but not used consistently. I do not think we > should build all the dependency chain (too much overhead) for older systems > (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for > these systems if it uses "mkosek/freeipa" as additional build root in Copr. Is it worth it? Is the older supported branch some kind of LTM or just happens to be alive because of some Fedora or RHEL release using it? I think there is value in providing early access to RHEL/CentOS users prior to dumping the RPMs onto them, but maintaining the repos is hard, I think we should only commit to this work if there is a use-case. > > c) Daily repos > Should we deprecate old John's repos > (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to > maintain and replace them with Copr ones? I.e. to have common repo (e.g. > mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM) > including dependencies? Is there a build script or other infrastructure that would make the new repo easy to maintain (easier than John's repo)? In general I think there is quite a bit of value in the daily builds -- we can ask users if their problem goes away with the latest builds and we could even use this for some CI setups and we know early if something breaks. > > Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, > 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across > projects "mkosek/freeipa-master", "someone/sssd-master", > "someone/389-ds-base-master? Second option may scale better better, the list of > such repos may be maintained somewhere (freeipa.org wiki). I think I might be missing something, but why do you think separate repos are better? > > > 2) We will need to have some tool chain and Jenkins CI jobs watching these > repos to make sure the build & run deps are OK. So far I used the attached 2 > clumsy bash scripts to handle the repos build and one for analysis. But we will > need something better. > > > 3) Scalability of the approach > Some dependencies are more difficult to maintain than the others. Especially > the PKI ones often required custom Java packaging (resteasy-base) or a > complicated dependency chain (the latest jackson-jaxrs-json-provider). It would > be great if PKI team helps with this effort, as Lukas proposed. Downside is > that mkosek/freeipa installation would require 2 Copr repos. But maybe we could > have a job syncing the PKI build/runtime dependencies directly to FreeIPA copr. > Whatever works and scale. I thought you could 'include' one repo in another with COPR? Wouldn't that solve the problem? From jdennis at redhat.com Mon Nov 10 12:53:34 2014 From: jdennis at redhat.com (John Dennis) Date: Mon, 10 Nov 2014 07:53:34 -0500 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <54609C82.7070403@redhat.com> References: <54609C82.7070403@redhat.com> Message-ID: <5460B54E.70700@redhat.com> On 11/10/2014 06:07 AM, Martin Kosek wrote: > c) Daily repos Should we deprecate old John's repos > (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is > difficult to maintain and replace them with Copr ones? I.e. to have > common repo (e.g. mkosek/freeipa-daily) built for the supported > Fedoras (F20, F21, rawhide ATM) including dependencies? Nalin does the actual builds, I noticed he wasn't on the CC list so I just added Nalin to this reply. >From what I know of Copr it's a better tool than our homegrown solution. If you're already doing Copr builds then I don't see much logic in keeping the old system. It makes sense to me there should be 1 entity pumping out the builds using the same technology, why duplicate efforts? Let's use the better technology. > Should it contain daily master builds for all tracked projects > (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let > distribute it across projects "mkosek/freeipa-master", > "someone/sssd-master", "someone/389-ds-base-master? Second option may > scale better better, the list of such repos may be maintained > somewhere (freeipa.org wiki). > 3) Scalability of the approach Some dependencies are more difficult > to maintain than the others. Especially the PKI ones often required > custom Java packaging (resteasy-base) or a complicated dependency > chain (the latest jackson-jaxrs-json-provider). It would be great if > PKI team helps with this effort, as Lukas proposed. Downside is that > mkosek/freeipa installation would require 2 Copr repos. But maybe we > could have a job syncing the PKI build/runtime dependencies directly > to FreeIPA copr. Whatever works and scale. I'm not sure I'm a fan of the scattered repo approach simply because it's hard for end users, too many yum repo configs to manage. One thing I think did work well with the old setup is the repo contained all the necessary dependencies which could not be satisfied from the system repos. I recognize the difficulty of trying to be a build master for a collection of difficult to build packages. What were we doing with the old system was to pull packages built elsewhere (i.e. Kevin did the CS builds) and merge them into the repo thus a user needed only point to one user, but we weren't responsible for doing builds for everything, just integrating, this makes the most sense to me. -- John From lslebodn at redhat.com Mon Nov 10 13:04:34 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 10 Nov 2014 14:04:34 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <5460B54E.70700@redhat.com> References: <54609C82.7070403@redhat.com> <5460B54E.70700@redhat.com> Message-ID: <20141110130433.GF9637@mail.corp.redhat.com> On (10/11/14 07:53), John Dennis wrote: >On 11/10/2014 06:07 AM, Martin Kosek wrote: > >> c) Daily repos Should we deprecate old John's repos >> (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is >> difficult to maintain and replace them with Copr ones? I.e. to have >> common repo (e.g. mkosek/freeipa-daily) built for the supported >> Fedoras (F20, F21, rawhide ATM) including dependencies? > >Nalin does the actual builds, I noticed he wasn't on the CC list so I >just added Nalin to this reply. > >From what I know of Copr it's a better tool than our homegrown solution. >If you're already doing Copr builds then I don't see much logic in >keeping the old system. It makes sense to me there should be 1 entity >pumping out the builds using the same technology, why duplicate efforts? >Let's use the better technology. > >> Should it contain daily master builds for all tracked projects >> (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let >> distribute it across projects "mkosek/freeipa-master", >> "someone/sssd-master", "someone/389-ds-base-master? Second option may >> scale better better, the list of such repos may be maintained >> somewhere (freeipa.org wiki). > >> 3) Scalability of the approach Some dependencies are more difficult >> to maintain than the others. Especially the PKI ones often required >> custom Java packaging (resteasy-base) or a complicated dependency >> chain (the latest jackson-jaxrs-json-provider). It would be great if >> PKI team helps with this effort, as Lukas proposed. Downside is that >> mkosek/freeipa installation would require 2 Copr repos. But maybe we >> could have a job syncing the PKI build/runtime dependencies directly >> to FreeIPA copr. Whatever works and scale. > >I'm not sure I'm a fan of the scattered repo approach simply because mkosek/freeipa contains 44 different packages. and approximately 1/4 of them are related just to dogtag for rhel7 >it's hard for end users, too many yum repo configs to manage. One thing >I think did work well with the old setup is the repo contained all the >necessary dependencies which could not be satisfied from the system >repos. I recognize the difficulty of trying to be a build master for a >collection of difficult to build packages. What were we doing with the >old system was to pull packages built elsewhere (i.e. Kevin did the CS >builds) and merge them into the repo thus a user needed only point to It *is not* possible to merge one COPR repo into another. It is possible to add another yum repo into build dependencies in COPR but it usually mean you will need to enable 2nd repo for installation of freeipa as well. LS From jdennis at redhat.com Mon Nov 10 13:46:55 2014 From: jdennis at redhat.com (John Dennis) Date: Mon, 10 Nov 2014 08:46:55 -0500 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <20141110130433.GF9637@mail.corp.redhat.com> References: <54609C82.7070403@redhat.com> <5460B54E.70700@redhat.com> <20141110130433.GF9637@mail.corp.redhat.com> Message-ID: <5460C1CF.5080906@redhat.com> > It *is not* possible to merge one COPR repo into another. > It is possible to add another yum repo into build dependencies in COPR > but it usually mean you will need to enable 2nd repo for installation of > freeipa as well. The script I wrote to manage the IPA repo entire purpose is to pull packages from diverse locations and merge them into one single unified repo. We call this the repo builder. The way this system currently works is the repo builder listens for messages from any number of builders, when it receives a message a new build is available it merges the new package into the repo. To be more precise it actually merges all the different OS versions, arches, debuginfo, multilib etc. to produce one single repo whose layout is identical to a Fedora repo. This is how we get a one-stop shopping repo for users to point to. My contribution to this process does not include doing any builds, instead my repo and the script that drives it assembles a unified repo from builds others do. I though Copr was capable of doing essentially the same thing, but at the same time doing the actual builds. If Copr cannot assemble an entire repo tree of OS's, arches, debuginfo, multilib, etc, then that is a big missing piece which already implemented and has been working well. -- John From pviktori at redhat.com Mon Nov 10 13:52:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Nov 2014 14:52:21 +0100 Subject: [Freeipa-devel] [PATCH] 0671 ipa-restore: Don't crash if AD trust is not installed Message-ID: <5460C315.4060200@redhat.com> This is a fix for: https://fedorahosted.org/freeipa/ticket/4668 -- Petr? From jhrozek at redhat.com Mon Nov 10 14:10:19 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 10 Nov 2014 15:10:19 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <20141110130433.GF9637@mail.corp.redhat.com> References: <54609C82.7070403@redhat.com> <5460B54E.70700@redhat.com> <20141110130433.GF9637@mail.corp.redhat.com> Message-ID: <20141110141019.GJ5577@hendrix.brq.redhat.com> On Mon, Nov 10, 2014 at 02:04:34PM +0100, Lukas Slebodnik wrote: > It *is not* possible to merge one COPR repo into another. > It is possible to add another yum repo into build dependencies in COPR Ah, right. Adding the build dependencies allows you to add another SRPM, to be built though.. > but it usually mean you will need to enable 2nd repo for installation of > freeipa as well. > > LS From mbasti at redhat.com Mon Nov 10 14:21:59 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Nov 2014 15:21:59 +0100 Subject: [Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade Message-ID: <5460CA07.9070101@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4680 Entry dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX must be updated before dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX Patch attached Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0160-Upgrade-fix-trusts-objectclass-violationi.patch Type: text/x-patch Size: 2420 bytes Desc: not available URL: From simo at redhat.com Mon Nov 10 15:22:37 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 10 Nov 2014 10:22:37 -0500 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <54609C82.7070403@redhat.com> References: <54609C82.7070403@redhat.com> Message-ID: <20141110102237.69d7ed4d@willson.usersys.redhat.com> On Mon, 10 Nov 2014 12:07:46 +0100 Martin Kosek wrote: > 3) Scalability of the approach > Some dependencies are more difficult to maintain than the others. > Especially the PKI ones often required custom Java packaging > (resteasy-base) or a complicated dependency chain (the latest > jackson-jaxrs-json-provider). It would be great if PKI team helps > with this effort, as Lukas proposed. Downside is that mkosek/freeipa > installation would require 2 Copr repos. But maybe we could have a > job syncing the PKI build/runtime dependencies directly to FreeIPA > copr. Whatever works and scale. Do we use the REST interface ? Would it be possible to simply build dogtag w/o it and avoid this massive set of annoying dependencies ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Nov 10 15:26:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 16:26:26 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <20141110124935.GG5577@hendrix.brq.redhat.com> References: <54609C82.7070403@redhat.com> <20141110124935.GG5577@hendrix.brq.redhat.com> Message-ID: <5460D922.3050109@redhat.com> On 11/10/2014 01:49 PM, Jakub Hrozek wrote: > On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote: >> Hi guys, >> >> Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a >> target to have the latest greatest FreeIPA available for older arches (read - >> RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20) >> try FreeIPA 4.0+ releases which brought in several dependencies. >> >> So far this was a more ad hoc approach, I think a more firm plan and tools are >> due. I see several questions that needs to be decided: >> >> 1) What Copr repos do we want to maintain and what should be the expectations? >> My take: >> >> a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, >> EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? >> Does it fit your needs? > > +1 > >> >> b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and >> greatest release, would it make sense to have a Copr repo with *releases* per >> supported branch to give users a choice? I.e. >> * mkosek/freeipa-4.1 >> * mkosek/freeipa-4.0 >> These repos are there already, but not used consistently. I do not think we >> should build all the dependency chain (too much overhead) for older systems >> (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for >> these systems if it uses "mkosek/freeipa" as additional build root in Copr. > > Is it worth it? Is the older supported branch some kind of LTM or just > happens to be alive because of some Fedora or RHEL release using it? > > I think there is value in providing early access to RHEL/CentOS users > prior to dumping the RPMs onto them, but maintaining the repos is hard, > I think we should only commit to this work if there is a use-case. In this particular case we wanted to have a repo to build FreeIPA 4.0.x given that mkosek/freeipa repo already contained 4.1. The purpose was to provide option to people who do not want to update to early 4.1.0 yet. >> c) Daily repos >> Should we deprecate old John's repos >> (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to >> maintain and replace them with Copr ones? I.e. to have common repo (e.g. >> mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM) >> including dependencies? > > Is there a build script or other infrastructure that would make the new > repo easy to maintain (easier than John's repo)? In general I think there > is quite a bit of value in the daily builds -- we can ask users if their > problem goes away with the latest builds and we could even use this for > some CI setups and we know early if something breaks. There seems to be a traction to use a single supported way of building RPMs and not maintain 2 systems - see John Dennis' response. >> Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, >> 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across >> projects "mkosek/freeipa-master", "someone/sssd-master", >> "someone/389-ds-base-master? Second option may scale better better, the list of >> such repos may be maintained somewhere (freeipa.org wiki). > > I think I might be missing something, but why do you think separate > repos are better? My idea was to decentralize it - to not overload FreeIPA developers with maintaining nightly devel builds and it's potentially new dependencies but to let domain experts from different teams to maintain it. Also, people interested in nightly builds may not be interested in nightly builds for all these packages, but maybe just SSSD. So they would just download SSSD yum repo and enable it. But if there is a value in having a united repo with nightly builds of all these packages, maybe there could simply be a cron script merging all the distributed Copr repos RPMs and placing them on fedorapeople. Martin From mkosek at redhat.com Mon Nov 10 15:28:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 16:28:32 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <20141110102237.69d7ed4d@willson.usersys.redhat.com> References: <54609C82.7070403@redhat.com> <20141110102237.69d7ed4d@willson.usersys.redhat.com> Message-ID: <5460D9A0.1070807@redhat.com> On 11/10/2014 04:22 PM, Simo Sorce wrote: > On Mon, 10 Nov 2014 12:07:46 +0100 > Martin Kosek wrote: > >> 3) Scalability of the approach >> Some dependencies are more difficult to maintain than the others. >> Especially the PKI ones often required custom Java packaging >> (resteasy-base) or a complicated dependency chain (the latest >> jackson-jaxrs-json-provider). It would be great if PKI team helps >> with this effort, as Lukas proposed. Downside is that mkosek/freeipa >> installation would require 2 Copr repos. But maybe we could have a >> job syncing the PKI build/runtime dependencies directly to FreeIPA >> copr. Whatever works and scale. > > Do we use the REST interface ? Yes: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=462beacc9d13968128fa320d155016df2d72a20a And we plan to leverage it even more: https://fedorahosted.org/freeipa/ticket/3473 IMO it is the right way instead of current HTML parsing approach. > Would it be possible to simply build dogtag w/o it and avoid this > massive set of annoying dependencies ? Given above, unfortunately not. Martin From mkosek at redhat.com Mon Nov 10 15:36:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Nov 2014 16:36:06 +0100 Subject: [Freeipa-devel] [PATCH] 0671 ipa-restore: Don't crash if AD trust is not installed In-Reply-To: <5460C315.4060200@redhat.com> References: <5460C315.4060200@redhat.com> Message-ID: <5460DB66.5020800@redhat.com> On 11/10/2014 02:52 PM, Petr Viktorin wrote: > This is a fix for: https://fedorahosted.org/freeipa/ticket/4668 > And the patch is...? From tbordaz at redhat.com Mon Nov 10 16:27:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 10 Nov 2014 17:27:05 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <5460D922.3050109@redhat.com> References: <54609C82.7070403@redhat.com> <20141110124935.GG5577@hendrix.brq.redhat.com> <5460D922.3050109@redhat.com> Message-ID: <5460E759.20409@redhat.com> On 11/10/2014 04:26 PM, Martin Kosek wrote: > On 11/10/2014 01:49 PM, Jakub Hrozek wrote: >> On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote: >>> Hi guys, >>> >>> Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a >>> target to have the latest greatest FreeIPA available for older arches (read - >>> RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20) >>> try FreeIPA 4.0+ releases which brought in several dependencies. >>> >>> So far this was a more ad hoc approach, I think a more firm plan and tools are >>> due. I see several questions that needs to be decided: >>> >>> 1) What Copr repos do we want to maintain and what should be the expectations? >>> My take: >>> >>> a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, >>> EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? >>> Does it fit your needs? >> +1 >> >>> b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and >>> greatest release, would it make sense to have a Copr repo with *releases* per >>> supported branch to give users a choice? I.e. >>> * mkosek/freeipa-4.1 >>> * mkosek/freeipa-4.0 >>> These repos are there already, but not used consistently. I do not think we >>> should build all the dependency chain (too much overhead) for older systems >>> (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for >>> these systems if it uses "mkosek/freeipa" as additional build root in Copr. >> Is it worth it? Is the older supported branch some kind of LTM or just >> happens to be alive because of some Fedora or RHEL release using it? >> >> I think there is value in providing early access to RHEL/CentOS users >> prior to dumping the RPMs onto them, but maintaining the repos is hard, >> I think we should only commit to this work if there is a use-case. > In this particular case we wanted to have a repo to build FreeIPA 4.0.x given > that mkosek/freeipa repo already contained 4.1. The purpose was to provide > option to people who do not want to update to early 4.1.0 yet. DS is building the latest and greatest release in copr. I am using this DS repo to test it against IPA 4.0.x and IPA 4.1.x latests. Currently I am building IPA latests (srpms+rpms) on my own copr repos, so with a risk of taking wrong dependencies. I would prefer to have a global per supported branches copr repos, like mkosek/freeipa-4-0... thanks thierry > >>> c) Daily repos >>> Should we deprecate old John's repos >>> (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to >>> maintain and replace them with Copr ones? I.e. to have common repo (e.g. >>> mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM) >>> including dependencies? >> Is there a build script or other infrastructure that would make the new >> repo easy to maintain (easier than John's repo)? In general I think there >> is quite a bit of value in the daily builds -- we can ask users if their >> problem goes away with the latest builds and we could even use this for >> some CI setups and we know early if something breaks. > There seems to be a traction to use a single supported way of building RPMs and > not maintain 2 systems - see John Dennis' response. > >>> Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, >>> 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across >>> projects "mkosek/freeipa-master", "someone/sssd-master", >>> "someone/389-ds-base-master? Second option may scale better better, the list of >>> such repos may be maintained somewhere (freeipa.org wiki). >> I think I might be missing something, but why do you think separate >> repos are better? > My idea was to decentralize it - to not overload FreeIPA developers with > maintaining nightly devel builds and it's potentially new dependencies but to > let domain experts from different teams to maintain it. > > Also, people interested in nightly builds may not be interested in nightly > builds for all these packages, but maybe just SSSD. So they would just download > SSSD yum repo and enable it. > > But if there is a value in having a united repo with nightly builds of all > these packages, maybe there could simply be a cron script merging all the > distributed Copr repos RPMs and placing them on fedorapeople. > > 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 jcholast at redhat.com Mon Nov 10 16:46:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 17:46:46 +0100 Subject: [Freeipa-devel] [PATCH] 365 Fix CA certificate backup and restore Message-ID: <5460EBF6.30700@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-365-Fix-CA-certificate-backup-and-restore.patch Type: text/x-patch Size: 7891 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 10 18:25:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Nov 2014 19:25:03 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes Message-ID: <546102FF.9080307@redhat.com> Hi, the attached patches provide additional fixes for . I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, please check them carefully. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-366-Remove-redefinition-of-LOG-from-ipa-otp-lasttoken.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-367-Unload-P11_Helper-object-s-library-when-it-is-finali.patch Type: text/x-patch Size: 2407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-368-Fix-Kerberos-error-handling-in-ipa-sam.patch Type: text/x-patch Size: 919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-369-Fix-unchecked-return-value-in-ipa-kdb.patch Type: text/x-patch Size: 939 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-370-Fix-unchecked-return-values-in-ipa-winsync.patch Type: text/x-patch Size: 5652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-371-Fix-unchecked-return-value-in-ipa-join.patch Type: text/x-patch Size: 936 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-372-Fix-unchecked-return-value-in-krb5-common-utils.patch Type: text/x-patch Size: 779 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 11 08:02:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 09:02:53 +0100 Subject: [Freeipa-devel] [PATCH] 354 Modififed NSSConnection not to shutdown existing database. In-Reply-To: <54501612.8060701@redhat.com> References: <5447BC13.6010500@redhat.com> <54501612.8060701@redhat.com> Message-ID: <5461C2AD.7000909@redhat.com> Hi, Dne 28.10.2014 v 23:17 Endi Sukma Dewata napsal(a): > On 10/22/2014 9:15 AM, Endi Sukma Dewata wrote: >> The NSSConnection class has been modified not to shutdown the >> existing NSS database if the database is already opened to >> establish an SSL connection, or is already opened by another >> code that uses an NSS database without establishing an SSL >> connection such as vault CLIs. >> >> Ticket #4638 > > New patch attached. It's identical except for the ticket URL in the > commit log. ACK. Honza -- Jan Cholasta From pviktori at redhat.com Tue Nov 11 08:08:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 09:08:07 +0100 Subject: [Freeipa-devel] [PATCH] 0671 ipa-restore: Don't crash if AD trust is not installed In-Reply-To: <5460DB66.5020800@redhat.com> References: <5460C315.4060200@redhat.com> <5460DB66.5020800@redhat.com> Message-ID: <5461C3E7.7050002@redhat.com> On 11/10/2014 04:36 PM, Martin Kosek wrote: > On 11/10/2014 02:52 PM, Petr Viktorin wrote: >> This is a fix for: https://fedorahosted.org/freeipa/ticket/4668 >> > > And the patch is...? > Here, sorry. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0671-ipa-restore-Don-t-crash-if-AD-trust-is-not-installed.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 11 08:12:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 09:12:26 +0100 Subject: [Freeipa-devel] [PATCH] 354 Modififed NSSConnection not to shutdown existing database. In-Reply-To: <5461C2AD.7000909@redhat.com> References: <5447BC13.6010500@redhat.com> <54501612.8060701@redhat.com> <5461C2AD.7000909@redhat.com> Message-ID: <5461C4EA.1040207@redhat.com> On 11/11/2014 09:02 AM, Jan Cholasta wrote: > Hi, > > Dne 28.10.2014 v 23:17 Endi Sukma Dewata napsal(a): >> On 10/22/2014 9:15 AM, Endi Sukma Dewata wrote: >>> The NSSConnection class has been modified not to shutdown the >>> existing NSS database if the database is already opened to >>> establish an SSL connection, or is already opened by another >>> code that uses an NSS database without establishing an SSL >>> connection such as vault CLIs. >>> >>> Ticket #4638 >> >> New patch attached. It's identical except for the ticket URL in the >> commit log. > > ACK. > > Honza > Pushed to master: 80a8df3f193aa800740f1627a269e6973f57aa0a -- Petr? From pviktori at redhat.com Tue Nov 11 08:16:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 09:16:52 +0100 Subject: [Freeipa-devel] [PATCH 0035] fix misleading Directory Manager --help output In-Reply-To: <54606863.4050807@redhat.com> References: <54606863.4050807@redhat.com> Message-ID: <5461C5F4.7010103@redhat.com> On 11/10/2014 08:25 AM, Jan Cholasta wrote: > Hi, > > Dne 7.11.2014 v 17:18 Gabe Alford napsal(a): >> Hello. >> >> Fix for https://fedorahosted.org/freeipa/ticket/4694 >> >> Thanks, >> >> Gabe > > ACK. > > Honza > Pushed to: master: d95d557ce5dc8c9c0a629af90bf7ae2224de0eb0 ipa-4-1: 488c10e9208957baa8171ddbf8a10aaed220b011 -- Petr? From pviktori at redhat.com Tue Nov 11 08:19:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 09:19:15 +0100 Subject: [Freeipa-devel] [PATCH] 0028 Remove unneeded internal methods. Move code to public, methods. In-Reply-To: <5460677C.1050303@redhat.com> References: <545CD701.5030909@redhat.com> <5460677C.1050303@redhat.com> Message-ID: <5461C683.50004@redhat.com> On 11/10/2014 08:21 AM, Jan Cholasta wrote: > Hi, ACK. > Pushed to master: 82c3c2b242c3f2b8113c2021cf4d17cab54c2a86 -- Petr? From jcholast at redhat.com Tue Nov 11 08:52:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 09:52:11 +0100 Subject: [Freeipa-devel] [PATCH] 365 Fix CA certificate backup and restore In-Reply-To: <5460EBF6.30700@redhat.com> References: <5460EBF6.30700@redhat.com> Message-ID: <5461CE3B.3020803@redhat.com> Dne 10.11.2014 v 17:46 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes . > > Honza Forgot to include /etc/pki/ca-trust/source/anchors/ipa-ca.crt in backup. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-365.1-Fix-CA-certificate-backup-and-restore.patch Type: text/x-patch Size: 7930 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 11 09:48:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Nov 2014 10:48:48 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <20141108134338.GA19510@mail.corp.redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> <20141108134338.GA19510@mail.corp.redhat.com> Message-ID: <5461DB80.5060803@redhat.com> On 8.11.2014 14:43, Lukas Slebodnik wrote: > On (20/10/14 16:08), Martin Kosek wrote: >> On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >>> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>>> >>>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>>> be usable on F20). >>> >>> And RHEL 7 / CentOS 7? >> >> For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >> "mkosek/freeipa" repo. >> > It is almost 3 weeks from this mail and freeipa-server cannot be installed from > "mkosek/freeipa" repo on RHEL/CentOS 7.0. > > bash-4.2# yum install freeipa-server > //snip > > ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed > --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch > --> Finished Dependency Resolution > Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) > Requires: jackson-jaxrs-json-provider > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > There were some promises on freeipa-users but nothing has changed. > > Is somebody working on this problem? BTW I tried to build few missing packages but I gave it up, the dependency tree is pretty long. Anyway, nothing prevents you from grabbing SRPMs from Koji, editing them as appropriate and rebuilding them in mkosek's COPR :-) > Maybe it is another candidate for inegtation tests. -- Petr^2 Spacek From jcholast at redhat.com Tue Nov 11 09:55:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 10:55:44 +0100 Subject: [Freeipa-devel] [PATCH] 0671 ipa-restore: Don't crash if AD trust is not installed In-Reply-To: <5461C3E7.7050002@redhat.com> References: <5460C315.4060200@redhat.com> <5460DB66.5020800@redhat.com> <5461C3E7.7050002@redhat.com> Message-ID: <5461DD20.4090601@redhat.com> Dne 11.11.2014 v 09:08 Petr Viktorin napsal(a): > On 11/10/2014 04:36 PM, Martin Kosek wrote: >> On 11/10/2014 02:52 PM, Petr Viktorin wrote: >>> This is a fix for: https://fedorahosted.org/freeipa/ticket/4668 >>> >> >> And the patch is...? >> > > Here, sorry. Thanks, ACK. Pushed to: master: a8e2a242bec1ce68d6b14be27e1b5b8d94f0deb9 ipa-4-1: d6b79a3ce7dd253737c41854e81273b01bc4a4c4 Honza -- Jan Cholasta From mkosek at redhat.com Tue Nov 11 09:58:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Nov 2014 10:58:54 +0100 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <5461DB80.5060803@redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> <5445175E.3090905@redhat.com> <20141108134338.GA19510@mail.corp.redhat.com> <5461DB80.5060803@redhat.com> Message-ID: <5461DDDE.5000504@redhat.com> On 11/11/2014 10:48 AM, Petr Spacek wrote: > On 8.11.2014 14:43, Lukas Slebodnik wrote: >> On (20/10/14 16:08), Martin Kosek wrote: >>> On 10/20/2014 04:00 PM, Jan Pazdziora wrote: >>>> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >>>>> >>>>> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >>>>> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >>>>> be usable on F20). >>>> >>>> And RHEL 7 / CentOS 7? >>> >>> For now, I would only maintain RHEL/CentOS 7.0 compatibility for main >>> "mkosek/freeipa" repo. >>> >> It is almost 3 weeks from this mail and freeipa-server cannot be installed from >> "mkosek/freeipa" repo on RHEL/CentOS 7.0. >> >> bash-4.2# yum install freeipa-server >> //snip >> >> ---> Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed >> --> Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch >> --> Finished Dependency Resolution >> Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa) >> Requires: jackson-jaxrs-json-provider >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> There were some promises on freeipa-users but nothing has changed. >> >> Is somebody working on this problem? > BTW I tried to build few missing packages but I gave it up, the dependency > tree is pretty long. > > Anyway, nothing prevents you from grabbing SRPMs from Koji, editing them as > appropriate and rebuilding them in mkosek's COPR :-) Right. I tried to follow up on Petr's attempts, did some progress but stopped with this dependency: http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/epel-7-x86_64/jackson-dataformat-smile-2.2.2-2.fc20/build.log I asked Dogtag team to help with the packaging as this Java dependency hell is outside of our reach. Martin From jcholast at redhat.com Tue Nov 11 10:13:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 11:13:18 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <546102FF.9080307@redhat.com> References: <546102FF.9080307@redhat.com> Message-ID: <5461E13E.2080605@redhat.com> Dne 10.11.2014 v 19:25 Jan Cholasta napsal(a): > Hi, > > the attached patches provide additional fixes for > . > > I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, > please check them carefully. > > Honza Changed the ticket to . Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-366.1-Remove-redefinition-of-LOG-from-ipa-otp-lasttoken.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-367.1-Unload-P11_Helper-object-s-library-when-it-is-finali.patch Type: text/x-patch Size: 2407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-368.1-Fix-Kerberos-error-handling-in-ipa-sam.patch Type: text/x-patch Size: 919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-369.1-Fix-unchecked-return-value-in-ipa-kdb.patch Type: text/x-patch Size: 939 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-370.1-Fix-unchecked-return-values-in-ipa-winsync.patch Type: text/x-patch Size: 5652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-371.1-Fix-unchecked-return-value-in-ipa-join.patch Type: text/x-patch Size: 936 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-372.1-Fix-unchecked-return-value-in-krb5-common-utils.patch Type: text/x-patch Size: 779 bytes Desc: not available URL: From abokovoy at redhat.com Tue Nov 11 10:32:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 12:32:18 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <20141111103218.GB19156@redhat.com> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>From 7ca2b25b93f1e3bff1e4c54ef1794cad462e533a Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 17:40:35 +0000 >Subject: [PATCH 3/7] Fix Kerberos error handling in ipa-sam > >https://fedorahosted.org/freeipa/ticket/4713 >--- > daemons/ipa-sam/ipa_sam.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c >index 3b69f9e..e711299 100644 >--- a/daemons/ipa-sam/ipa_sam.c >+++ b/daemons/ipa-sam/ipa_sam.c >@@ -4233,7 +4233,7 @@ static int bind_callback(LDAP *ldap_struct, struct smbldap_state *ldap_state, vo > krb5_free_principal(data.context, in_creds.server); > krb5_free_principal(data.context, in_creds.client); > >- if (rc) { >+ if (rc != 0 && rc != KRB5KRB_AP_ERR_TKT_NYV && rc != KRB5KRB_AP_ERR_TKT_EXPIRED) { > rc = bind_callback_obtain_creds(&data); > if (rc) { > bind_callback_cleanup(&data, rc); ACK -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 11 10:40:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Nov 2014 12:40:25 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <20141111104025.GC19156@redhat.com> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 18:10:27 +0000 >Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb > >https://fedorahosted.org/freeipa/ticket/4713 >--- > daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index c8f6c76..debcd1b 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > ipactx->kdc_hostname, strlen(ipactx->kdc_hostname), > NULL, NULL, &result) == 0) { > kerr = ipadb_reinit_mspac(ipactx, true); >+ if (kerr != 0 && kerr != ENOENT) { >+ goto done; >+ } > } > } > I'm not sure we should drop the sign_authdata request here. If we were able to re-initialize our view of trusted domains, we simply cannot re-sign incoming PAC but this is handled in ipadb_verify_pac() and ipadb_sign_pac() and if the former returns NULL value for PAC, we exit with a return code of 0 while this change will fail a cross-realm TGT request unconditionally. -- / Alexander Bokovoy From tbabej at redhat.com Tue Nov 11 11:13:20 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 11 Nov 2014 12:13:20 +0100 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <5458C0F1.2070508@redhat.com> References: <543E6685.8000704@redhat.com> <5447EBE0.4080203@redhat.com> <5448BEBB.6030609@redhat.com> <544A583C.3060601@redhat.com> <5458C0F1.2070508@redhat.com> Message-ID: <5461EF50.3040805@redhat.com> On 11/04/2014 01:05 PM, Petr Vobornik wrote: >>>> On 10/15/2014 02:20 PM, Petr Vobornik wrote: >>>>> ticket: https://fedorahosted.org/freeipa/ticket/4221 >>>>> > > updated version of patch 773 attached. Fixes issue in > interactive_prompt_callback. > > Not related to this ticket: > - should we show interactive prompt for domain name when user > specifies --type=ipa-adtrust or ipa-adtrust-posix? Atm it will prompt > for values related to local range. ACK for the whole patchset, works in my testing. Pushed to ipa-4-1: c2ac4a88775274e2cb8f199d104a1393a1d4a81e Pushed to master: 8248f696275e2e63dab860a25467e2868aa17036 Regarding the issue, yes, I agree, prompting for values for the local ranges should not happen. I think the most reasonable behaviour is as follows: - first value that intractive callback asks for should be type, if not specified or cannot be derived explicitly from used parameters (and after the range's name) - after that, the interactive prompt should ask for relevant attributes only. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Tue Nov 11 11:22:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Nov 2014 12:22:20 +0100 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <5461EF50.3040805@redhat.com> References: <543E6685.8000704@redhat.com> <5447EBE0.4080203@redhat.com> <5448BEBB.6030609@redhat.com> <544A583C.3060601@redhat.com> <5458C0F1.2070508@redhat.com> <5461EF50.3040805@redhat.com> Message-ID: <5461F16C.7030201@redhat.com> On 11.11.2014 12:13, Tomas Babej wrote: > > On 11/04/2014 01:05 PM, Petr Vobornik wrote: >>>>> On 10/15/2014 02:20 PM, Petr Vobornik wrote: >>>>>> ticket: https://fedorahosted.org/freeipa/ticket/4221 >>>>>> >> >> updated version of patch 773 attached. Fixes issue in >> interactive_prompt_callback. >> >> Not related to this ticket: >> - should we show interactive prompt for domain name when user >> specifies --type=ipa-adtrust or ipa-adtrust-posix? Atm it will prompt >> for values related to local range. > > ACK for the whole patchset, works in my testing. > > Pushed to ipa-4-1: c2ac4a88775274e2cb8f199d104a1393a1d4a81e > Pushed to master: 8248f696275e2e63dab860a25467e2868aa17036 > > Regarding the issue, yes, I agree, prompting for values for the local > ranges should not happen. I think the most reasonable behaviour is as > follows: > - first value that intractive callback asks for should be type, if not > specified or cannot be derived explicitly from used parameters (and > after the range's name) > - after that, the interactive prompt should ask for relevant attributes > only. > +1 https://fedorahosted.org/freeipa/ticket/4714 -- Petr Vobornik From jcholast at redhat.com Tue Nov 11 11:27:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 12:27:21 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <20141111104025.GC19156@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> Message-ID: <5461F299.1080801@redhat.com> Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a): > On Tue, 11 Nov 2014, Jan Cholasta wrote: >>> From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001 >> From: Jan Cholasta >> Date: Mon, 10 Nov 2014 18:10:27 +0000 >> Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb >> >> https://fedorahosted.org/freeipa/ticket/4713 >> --- >> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >> b/daemons/ipa-kdb/ipa_kdb_mspac.c >> index c8f6c76..debcd1b 100644 >> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >> @@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context >> context, >> ipactx->kdc_hostname, >> strlen(ipactx->kdc_hostname), >> NULL, NULL, &result) == 0) { >> kerr = ipadb_reinit_mspac(ipactx, true); >> + if (kerr != 0 && kerr != ENOENT) { >> + goto done; >> + } >> } >> } >> > I'm not sure we should drop the sign_authdata request here. If we were > able to re-initialize our view of trusted domains, we simply cannot > re-sign incoming PAC but this is handled in ipadb_verify_pac() and > ipadb_sign_pac() and if the former returns NULL value for PAC, we exit > with a return code of 0 while this change will fail a cross-realm TGT > request unconditionally. > OK, what would be a proper fix? Just ignore the return value of ipadb_reinit_mspac here? -- Jan Cholasta From tscherf at redhat.com Tue Nov 11 12:37:12 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 11 Nov 2014 13:37:12 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli Message-ID: <20141111123711.GU1849@tscherf.redhat.com> The ipa-server-install man page is more descriptive on how to configure multiple DNS forwarders than the cli help. The cli help is more verbose now. https://fedorahosted.org//ticket/4465 Cheers, Thorsten -------------- next part -------------- From 11dcf90ba36f00f9c4ee74a33c6aa6f8773210ff Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 11 Nov 2014 13:30:44 +0100 Subject: [PATCH] Add help string on how to configure multiple DNS forwards on cli The ipa-server-install man page is more descriptive on how to configure multiple DNS forwarders than the cli help. This cli help is more verbose now. https://fedorahosted.org//ticket/4465 --- install/tools/ipa-server-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb79cfbbc09966950f4e5fb51984008b20600143..1280b631db4f7b6ad69d1151d047a8190ca5215a 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -282,7 +282,7 @@ def parse_options(): dns_group.add_option("--setup-dns", dest="setup_dns", action="store_true", default=False, help="configure bind with our zone") dns_group.add_option("--forwarder", dest="forwarders", action="append", - type="ip", help="Add a DNS forwarder") + type="ip", help="Add a DNS forwarder. This option can be used multiple times") dns_group.add_option("--no-forwarders", dest="no_forwarders", action="store_true", default=False, help="Do not add any DNS forwarders, use root servers instead") dns_group.add_option("--reverse-zone", dest="reverse_zones", help="The reverse DNS zone to use", -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 11 12:57:41 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 13:57:41 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli In-Reply-To: <20141111123711.GU1849@tscherf.redhat.com> References: <20141111123711.GU1849@tscherf.redhat.com> Message-ID: <546207C5.1080603@redhat.com> On 11/11/14 13:37, Thorsten Scherf wrote: > The ipa-server-install man page is more descriptive on how to configure > multiple DNS forwarders than the cli help. The cli help is more verbose > now. > > https://fedorahosted.org//ticket/4465 > > Cheers, > Thorsten > > Hello, thanks for patch, but I have a few objections. 1) Trac link in commit is corrupted 2) The forwarder option is in more installation scripts: * ipa-dns-install * ipa-replica-install * ipa-server-install Martin^2 -- Martin Basti From redhatrises at gmail.com Tue Nov 11 14:21:35 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 11 Nov 2014 07:21:35 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0036-Add-missing-python-files-to-Makefiles.patch Type: text/x-patch Size: 2423 bytes Desc: not available URL: From tscherf at redhat.com Tue Nov 11 14:42:39 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 11 Nov 2014 15:42:39 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli In-Reply-To: <546207C5.1080603@redhat.com> References: <20141111123711.GU1849@tscherf.redhat.com> <546207C5.1080603@redhat.com> Message-ID: <20141111144239.GZ1849@tscherf.redhat.com> On [Tue, 11.11.2014 13:57], Martin Basti wrote: >On 11/11/14 13:37, Thorsten Scherf wrote: >>The ipa-server-install man page is more descriptive on how to configure >>multiple DNS forwarders than the cli help. The cli help is more verbose >>now. >> >>https://fedorahosted.org//ticket/4465 >> >>Cheers, >>Thorsten >> >> >Hello, > >thanks for patch, but I have a few objections. > >1) Trac link in commit is corrupted >2) The forwarder option is in more installation scripts: >* ipa-dns-install >* ipa-replica-install >* ipa-server-install Please find the new patch attached. https://fedorahosted.org/freeipa/ticket/4465 Cheers, Thorsten -------------- next part -------------- From 64faa16b953190d60e06598eeceef928afeaefe3 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Tue, 11 Nov 2014 15:38:01 +0100 Subject: [PATCH] Add help string on how to configure multiple DNS forwards for various cli tools The man pages for various FreeIPA setup tools are more descriptive on how to configure multiple DNS forwarders than the corresponding cli help. This patch makes the cli help more verbose now for the following tools: * ipa-dns-install * ipa-replica-install * ipa-server-install https://fedorahosted.org/freeipa/ticket/4465 --- install/tools/ipa-dns-install | 2 +- install/tools/ipa-replica-install | 2 +- install/tools/ipa-server-install | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install index 73afadf56a1b6594d11fd87b0efdeb6cc179bc0d..7d9bf6a8b223b586e7923137abec557036f650da 100755 --- a/install/tools/ipa-dns-install +++ b/install/tools/ipa-dns-install @@ -47,7 +47,7 @@ def parse_options(): default=[], action="append", type="ip", ip_local=True, help="Master Server IP Address") parser.add_option("--forwarder", dest="forwarders", action="append", - type="ip", help="Add a DNS forwarder") + type="ip", help="Add a DNS forwarder. This option can be used multiple times") parser.add_option("--no-forwarders", dest="no_forwarders", action="store_true", default=False, help="Do not add any DNS forwarders, use root servers instead") parser.add_option("--reverse-zone", dest="reverse_zones", diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index 8f0ce86667b3603cb2a72fbc9b78e074db73cdd9..409f1f61b42ccb2a4f2053689a7452f4fe344b4d 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -109,7 +109,7 @@ def parse_options(): dns_group.add_option("--setup-dns", dest="setup_dns", action="store_true", default=False, help="configure bind with our zone") dns_group.add_option("--forwarder", dest="forwarders", action="append", - type="ip", help="Add a DNS forwarder") + type="ip", help="Add a DNS forwarder. This option can be used multiple times") dns_group.add_option("--no-forwarders", dest="no_forwarders", action="store_true", default=False, help="Do not add any DNS forwarders, use root servers instead") dns_group.add_option("--reverse-zone", dest="reverse_zones", default=[], diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb79cfbbc09966950f4e5fb51984008b20600143..1280b631db4f7b6ad69d1151d047a8190ca5215a 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -282,7 +282,7 @@ def parse_options(): dns_group.add_option("--setup-dns", dest="setup_dns", action="store_true", default=False, help="configure bind with our zone") dns_group.add_option("--forwarder", dest="forwarders", action="append", - type="ip", help="Add a DNS forwarder") + type="ip", help="Add a DNS forwarder. This option can be used multiple times") dns_group.add_option("--no-forwarders", dest="no_forwarders", action="store_true", default=False, help="Do not add any DNS forwarders, use root servers instead") dns_group.add_option("--reverse-zone", dest="reverse_zones", help="The reverse DNS zone to use", -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 11 15:15:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 16:15:02 +0100 Subject: [Freeipa-devel] [PATCH] 365 Fix CA certificate backup and restore In-Reply-To: <5461CE3B.3020803@redhat.com> References: <5460EBF6.30700@redhat.com> <5461CE3B.3020803@redhat.com> Message-ID: <546227F6.5020401@redhat.com> On 11/11/2014 09:52 AM, Jan Cholasta wrote: > Dne 10.11.2014 v 17:46 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch fixes . >> >> Honza > > Forgot to include /etc/pki/ca-trust/source/anchors/ipa-ca.crt in backup. > > Updated patch attached. Looks good ACK, pushed to: master: 2639997dfee43d66e94ef9b5441289816c465e7d ipa-4-1: 7c2aad17da8bd5f50b9c1409f91c413bc454ce28 -- Petr? From mbasti at redhat.com Tue Nov 11 15:22:20 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 16:22:20 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission Message-ID: <546229AC.9040809@redhat.com> Using specfile to create file doesn't work if named user is not on system. Appropriate permission have to be set during ipa-dns installation. Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0161-Fix-named-working-directory-permissions.patch Type: text/x-patch Size: 4581 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 11 15:29:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Nov 2014 16:29:51 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services Message-ID: <54622B6F.3080101@redhat.com> Hello, this thread is about RFE "IPA servers when installed should register themselves in the external DNS" https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case ======== FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers "just for FreeIPA". High-level idea =============== - Transform dns* commands from FreeIPA framework to equivalent "nsupdate" commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework =================================== First of all, we need to decide if "external DNS integration" can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. In other words, the question is if current "dns.py" plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands ---------------------------------------------- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... Advantages: - You can use external & integrated DNS at the same time. b) Replace dns.py with another implementation of current dnszone-* & dnsrecord-* API. --------------------------------------------------------------------- This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to "standard" ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*->nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated & external DNS at the same time (but I don't think it justifies the added complexity). Petr^3 or anyone else, what do you propose? 2) Authentication to external DNS server/keys ============================================= This is separate problem from FreeIPA framework integration. We will have to somehow store raw symmetric keys (for DNS TSIG) or keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so every replica can update DNS records as necessary. This will be the funny part because in case of AD trusts we have chicken-egg problem. You need to establish trust to get ticket for DNS/dc1.ad.example at AD principal but you can't (I guess) establish trust until proper DNS records are in place ... For 'experimental' phase I would go with pre-populated CCcache, i.e. admin will manually do kinit Administrator at AD and then run FreeIPA installer. Maybe we can re-use trust secret somehow? I don't know, I will reach out to AD experts with questions. This area needs more research but for now it seems feasible to re-use DNSSEC key distribution system for TSIG keys and keytabs so "only" the chicken-egg problem is left. This will need new LDAP schema but I will propose something when I'm done with investigation. -- Petr^2 Spacek From mbasti at redhat.com Tue Nov 11 15:50:33 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Nov 2014 16:50:33 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli In-Reply-To: <20141111144239.GZ1849@tscherf.redhat.com> References: <20141111123711.GU1849@tscherf.redhat.com> <546207C5.1080603@redhat.com> <20141111144239.GZ1849@tscherf.redhat.com> Message-ID: <54623049.3010509@redhat.com> On 11/11/14 15:42, Thorsten Scherf wrote: > On [Tue, 11.11.2014 13:57], Martin Basti wrote: >> On 11/11/14 13:37, Thorsten Scherf wrote: >>> The ipa-server-install man page is more descriptive on how to configure >>> multiple DNS forwarders than the cli help. The cli help is more verbose >>> now. >>> >>> https://fedorahosted.org//ticket/4465 >>> >>> Cheers, >>> Thorsten >>> >>> >> Hello, >> >> thanks for patch, but I have a few objections. >> >> 1) Trac link in commit is corrupted >> 2) The forwarder option is in more installation scripts: >> * ipa-dns-install >> * ipa-replica-install >> * ipa-server-install > > Please find the new patch attached. > > https://fedorahosted.org/freeipa/ticket/4465 > > Cheers, > Thorsten > > Thank you, ACK. Please read how to format a patch for future. http://www.freeipa.org/page/Contribute/Patch_Format -- Martin Basti From jcholast at redhat.com Tue Nov 11 15:58:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Nov 2014 16:58:05 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <546229AC.9040809@redhat.com> References: <546229AC.9040809@redhat.com> Message-ID: <5462320D.2050802@redhat.com> Hi, Dne 11.11.2014 v 16:22 Martin Basti napsal(a): > Using specfile to create file doesn't work if named user is not on system. > Appropriate permission have to be set during ipa-dns installation. > > Patch attached > Why is the directory set up in dnskeysyncinstance instead of bindinstance? The original patch was released with 4.1.1, shouldn't there be update in ipa-upgradeconfig? Honza -- Jan Cholasta From pviktori at redhat.com Tue Nov 11 16:03:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Nov 2014 17:03:30 +0100 Subject: [Freeipa-devel] [PATCH] 0672 - ipaplatform: Use the dirsrv service, not target Message-ID: <54623352.2000300@redhat.com> https://fedorahosted.org/freeipa/ticket/4709 With this patch, IPA should no longer call systemctl on dirsrv.tagret, but rather on its concrete service. Since systemctl stop waits for shutdown of services (but not targets), we can assume dirsrv will be down (and the database unlocked) after stop() is done. There's a DS ticket [0] to explicitly tell systemd which process to wait on, but in my experience, systemd guesses correctly even without that fix. [0] https://fedorahosted.org/389/ticket/47951 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0672-ipaplatform-Always-use-dirsrv-instance-service-not-t.patch Type: text/x-patch Size: 1391 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 12 07:58:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Nov 2014 08:58:32 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461F299.1080801@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> Message-ID: <54631328.7030204@redhat.com> On 11.11.2014 12:27, Jan Cholasta wrote: > Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a): >> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>>> From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001 >>> From: Jan Cholasta >>> Date: Mon, 10 Nov 2014 18:10:27 +0000 >>> Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb >>> >>> https://fedorahosted.org/freeipa/ticket/4713 >>> --- >>> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>> b/daemons/ipa-kdb/ipa_kdb_mspac.c >>> index c8f6c76..debcd1b 100644 >>> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>> @@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context >>> context, >>> ipactx->kdc_hostname, >>> strlen(ipactx->kdc_hostname), >>> NULL, NULL, &result) == 0) { >>> kerr = ipadb_reinit_mspac(ipactx, true); >>> + if (kerr != 0 && kerr != ENOENT) { >>> + goto done; >>> + } >>> } >>> } >>> >> I'm not sure we should drop the sign_authdata request here. If we were >> able to re-initialize our view of trusted domains, we simply cannot >> re-sign incoming PAC but this is handled in ipadb_verify_pac() and >> ipadb_sign_pac() and if the former returns NULL value for PAC, we exit >> with a return code of 0 while this change will fail a cross-realm TGT >> request unconditionally. >> > > OK, what would be a proper fix? Just ignore the return value of > ipadb_reinit_mspac here? Guys, I did not see the code but all instances of "ignore return code" I have seen were wrong, including cases where code comment explicitly said "we ignore return code on purpose" :-) At least log an error message if you can't think of anything better ... -- Petr^2 Spacek From mbasti at redhat.com Wed Nov 12 12:33:41 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Nov 2014 13:33:41 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <5462320D.2050802@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> Message-ID: <546353A5.505@redhat.com> On 11/11/14 16:58, Jan Cholasta wrote: > Hi, > > Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >> Using specfile to create file doesn't work if named user is not on >> system. >> Appropriate permission have to be set during ipa-dns installation. >> >> Patch attached >> > > Why is the directory set up in dnskeysyncinstance instead of > bindinstance? Because, dnskeysyncinstance is the daemon which requires permission change. (dir is created by dyndb-ldap plugin) > > The original patch was released with 4.1.1, shouldn't there be update > in ipa-upgradeconfig? Cases: 1) fresh RPM install, no named user during RPM install -> named doesn't start, user had to fix it immediately, can't wait until next release. 2) fresh RPM install, named user -> no impact 3) upgrade IPA with DNS -> no impact 4) upgrade IPA without DNS -> after DNS installation, same as 1) 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not work (If user doesnt use DNSSEC) Only 5) looks serious for me, so here is updated patch. Martin^2 > > Honza > -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0161.2-Fix-named-working-directory-permissions.patch Type: text/x-patch Size: 6551 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 12 12:43:53 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Nov 2014 13:43:53 +0100 Subject: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once Message-ID: <54635609.3010601@redhat.com> Hello, masking named service is executed more than once, following patch fixes it. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0162-Upgrade-fix-masking-named-should-be-executed-only-on.patch Type: text/x-patch Size: 2183 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 12 12:44:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Nov 2014 13:44:57 +0100 Subject: [Freeipa-devel] FreeIPA translations Message-ID: <54635649.1070201@redhat.com> Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. If no, we need to find something better. If yes, we will need to make sure the process is well documented on the FreeIPA.org wiki + integrated to our Release process so that it can be handed to someone else. (volunteers? :) Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From jdennis at redhat.com Wed Nov 12 14:22:56 2014 From: jdennis at redhat.com (John Dennis) Date: Wed, 12 Nov 2014 09:22:56 -0500 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <54635649.1070201@redhat.com> References: <54635649.1070201@redhat.com> Message-ID: <54636D40.8010902@redhat.com> On 11/12/2014 07:44 AM, Martin Kosek wrote: > Hi folks, > > With Petr changing focus out of FreeIPA, somebody will need to replace his work > as the person behind FreeIPA Transifex translation. > > I think this is now the right time and place to ask - Is Transifex still the > translation tool we want to continue supporting? I know there were objections > in the past it is not completely open source. But AFAIK, it is one of the most > used ones, even OpenStack uses it. I have not been following it closely but there was talk of both Fedora and Openstack moving from Transifex to Zanata http://zanata.org/ As a matter of fact there was recent emails concerning the new Fedora Zanta instance "Move to Zanata Stage 1 - fedora.zanata instance available now!" https://lists.fedoraproject.org/pipermail/trans/2014-November/011717.html Like I said, I haven't followed this closely but it seems like Zanata is the future. > > If no, we need to find something better. If yes, we will need to make sure the > process is well documented on the FreeIPA.org wiki + integrated to our Release > process so that it can be handed to someone else. (volunteers? :) > > Thanks. > -- John From pspacek at redhat.com Wed Nov 12 14:30:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Nov 2014 15:30:55 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <53D0CB27.7090203@redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> Message-ID: <54636F1F.6090701@redhat.com> On 24.7.2014 11:00, Petr Spacek wrote: > On 27.2.2014 15:19, Lukas Slebodnik wrote: >> ehlo, >> >> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying >> to export special CFLAGS for bind9 header files. It can be automatically >> detected in configure script using utility isc-config. >> >> Attached patch should improve this and CFLAGS needn't be exported. > > Kind NACK. It would be valuable to test if isc/errno2result.h header is > present and throw appropriate error. > > Current check with isc-config.sh only will pass if you have bind-devel package > installed but you are missing bind-lite-devel package. > > > I have a question: How > +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 > works? > > Will it take user-defined CFLAGS into account? I would like to place > user-defined flags at the end of the list so you can easily override settings > given by autotools. > > Thank you for clarification :-) > > > I will be really happy to commit complete fix. Thank you for cleaning this > autotools mess! This version actually works. Previous version did not take CFLAGS from isc-config.sh into account during libdns version check so it actually did not work at all :-) Please review it (and send me a modified patch if you see a problem). Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-lslebodn-0001-2-AUTOCONF-Improve-detection-of-bind9-header-files.patch Type: text/x-patch Size: 3227 bytes Desc: not available URL: From jfenal at gmail.com Wed Nov 12 14:35:40 2014 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 12 Nov 2014 15:35:40 +0100 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <54636D40.8010902@redhat.com> References: <54635649.1070201@redhat.com> <54636D40.8010902@redhat.com> Message-ID: 2014-11-12 15:22 GMT+01:00 John Dennis : > On 11/12/2014 07:44 AM, Martin Kosek wrote: >> Hi folks, >> >> With Petr changing focus out of FreeIPA, somebody will need to replace his work >> as the person behind FreeIPA Transifex translation. >> >> I think this is now the right time and place to ask - Is Transifex still the >> translation tool we want to continue supporting? I know there were objections >> in the past it is not completely open source. But AFAIK, it is one of the most >> used ones, even OpenStack uses it. > > I have not been following it closely but there was talk of both Fedora > and Openstack moving from Transifex to Zanata > > http://zanata.org/ > > As a matter of fact there was recent emails concerning the new Fedora > Zanta instance > > "Move to Zanata Stage 1 - fedora.zanata instance available now!" > https://lists.fedoraproject.org/pipermail/trans/2014-November/011717.html > > Like I said, I haven't followed this closely but it seems like Zanata is > the future. +1 The Fedora Zanata instance is the place to go. Regards, J. -- J?r?me Fenal From mbasti at redhat.com Wed Nov 12 14:55:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Nov 2014 15:55:30 +0100 Subject: [Freeipa-devel] [PATCH 0163] Fix compiler warning for pk11helper module Message-ID: <546374E2.2040205@redhat.com> Part of ticket: https://fedorahosted.org/freeipa/ticket/4657 -- Martin Basti From pspacek at redhat.com Wed Nov 12 15:11:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Nov 2014 16:11:07 +0100 Subject: [Freeipa-devel] [PATCH 0308] Improve detection of BIND 9 isc__errno2result header file Message-ID: <5463788B.3060107@redhat.com> Hello, Improve detection of BIND 9 isc__errno2result header file. This header file is not in standard distribution so normal isc-config.sh detection is not enough. With this patch, ./configure should work even without explicit CFLAGS and it should also detect that bind-devel or bind-lite-devel packages are missing. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0308-Improve-detection-of-BIND-9-isc__errno2result-header.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From pvoborni at redhat.com Wed Nov 12 15:17:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Nov 2014 16:17:33 +0100 Subject: [Freeipa-devel] [PATCH] 784-786 webui: offer suffixes of trusted domains for overrides Message-ID: <54637A0D.80703@redhat.com> https://fedorahosted.org/freeipa/ticket/4554 [PATCH] 784 webui: refactor combobox search to support search providers Comboboxe's search logic was moved into a separate object - a search provider. This change makes Entity Select a regular combobox with a special provider. new JointCBSearchProvider allows to combine results of two providers into a single result. [PATCH] 785 webui: offer suffixes of trusted domains for overrides [PATCH] 786 webui: unable to select single value in CB by enter key Fix: If editable combobox has one value, the value is selected and changed by hand, it can't be re-selected by enter key. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0785-webui-offer-suffixes-of-trusted-domains-for-override.patch Type: text/x-patch Size: 5453 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0786-webui-unable-to-select-single-value-in-CB-by-enter-k.patch Type: text/x-patch Size: 1029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0784-webui-refactor-combobox-search-to-support-search-pro.patch Type: text/x-patch Size: 16976 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 12 15:34:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Nov 2014 16:34:54 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <20140225140540.GA6432@mail.corp.redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> Message-ID: <54637E1E.8090009@redhat.com> On 25.2.2014 15:05, Lukas Slebodnik wrote: > On (25/02/14 09:54), Petr Spacek wrote: >> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>> On (24/02/14 16:48), Petr Spacek wrote: >>>> Hello, >>>> >>>> Drop unnecessary #define _BSD_SOURCE. >>>> >>>> -- >>>> Petr^2 Spacek >>> >>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>> From: Petr Spacek >>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>> >>>> Signed-off-by: Petr Spacek >>>> --- >>>> src/krb5_helper.c | 2 -- >>>> 1 file changed, 2 deletions(-) >>>> >>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>> --- a/src/krb5_helper.c >>>> +++ b/src/krb5_helper.c >>>> @@ -15,8 +15,6 @@ >>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>> */ >>>> >>>> -#define _BSD_SOURCE >>>> - >>>> #include >>>> #include >>>> #include >>>> -- >>>> 1.8.5.3 >>>> >>> >>> Simo is an author (according to git blame) >>> He defined this macro due to function setenv >>> >> >from man setenv: >>> NAME >>> setenv - change or add an environment variable >>> >>> SYNOPSIS >>> #include >>> >>> int setenv(const char *name, const char *value, int overwrite); >>> >>> int unsetenv(const char *name); >>> >>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>> >>> setenv(), unsetenv(): >>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>> ---------------------------------------------------------------------------- >>> >>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>> header file . I tested only on fedora 20. It can be used >>> on the other distributions. >>> >>> I would rather let this macro as is. >> >> Wow, I didn't expect that somebody will spend time on this :-) >> >> See build logs from Fedora 21 >> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log > > You should have noticed this in the 1st mail. Because it is difference between > removing unnecessary macro and depprecated usage of macro. > > /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE > are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" > >> Patches with 'the right' solution are welcome. I'm not going to spend >> more time on this. Attached patch should fix the warning in the 'proper' way, I hope. Without this patch the warning constantly pops up on Fedora 21. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0228-2-Replace-obsolete-BSD-SOURCE.patch Type: text/x-patch Size: 801 bytes Desc: not available URL: From dkupka at redhat.com Wed Nov 12 15:55:16 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 12 Nov 2014 16:55:16 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <545CD5B0.3050002@redhat.com> References: <545CD5B0.3050002@redhat.com> Message-ID: <546382E4.6020706@redhat.com> On 11/07/2014 03:22 PM, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4622 > Patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > LGTM, please rebase to ipa-4-0. -- David Kupka From mbasti at redhat.com Wed Nov 12 15:58:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Nov 2014 16:58:35 +0100 Subject: [Freeipa-devel] Gaps in upstream tests In-Reply-To: <545CCC22.9040501@redhat.com> References: <545CCC22.9040501@redhat.com> Message-ID: <546383AB.4090502@redhat.com> On 07/11/14 14:41, Martin Kosek wrote: > FreeIPA team will soon grow with a new member focusing on upstream QE > tests. I would like to collect ideas what are the biggest gaps in the > current upstream test suite from your POV. > > Existing requests are tracked here: > https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Tests&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=milestone&group=milestone&order=priority > > > First idea that I head proposed are Upgrade tests. These are often > done manually. I think that upgrade test from currently supported > FreeIPA/Fedora version would go a long way (like 3.3.5 on F20 upgraded > built RPMs and running unit tests). > > Second, it would be nice to try testing FreeIPA server in a container. > Not only it would verify our container efforts, but it may also allow > easy multi-master tests on one Jenkins VM or local host instead of > expensive VM orchestration. > > Any other areas worth focusing on (besides of course testing newly > developed features)? > 1) DNS: We should testing more "complicated" DNS toplogy with forwarders, testing if a forward zone forwards data as expected (we had regression), test if DNS (named) works as expected with various configurations. Currently the wait_for_dns option tests if record is resolvable, but we should test if the record is correct in better way. Test installation with various DNS options (or non DNS as well) 2) Upgrade tests: +1000 Martin^2 -- Martin Basti From npmccallum at redhat.com Wed Nov 12 22:37:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 12 Nov 2014 17:37:40 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <54606932.1030809@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> Message-ID: <1415831860.3363.4.camel@redhat.com> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > On 11/07/2014 04:44 PM, Petr Vobornik wrote: > > On 7.11.2014 08:58, Martin Kosek wrote: > >> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>> This patch gives the administrator variables to control the size of > >>>>>>>> the authentication and synchronization windows for OTP tokens. > >>>>>>>> > >>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>> > >>>>>>>> NOTE: There is one known issue with this patch which I don't know > >>>>>>>> how to > >>>>>>>> solve. This patch changes the schema in > >>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. > >>>>>>>> However, > >>>>>>>> the modifications to the pre-existing objectClass do not show up > >>>>>>>> on the > >>>>>>>> server. What am I doing wrong? > >>>>>>>> > >>>>>>>> After modifying ipaGuiConfig manually, everything in this patch > >>>>>>>> works > >>>>>>>> just fine. > >>>>>>> > >>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>> attribute > >>>>>>> names. > >>>>>> > >>>>>> Thanks Nathaniel! > >>>>>> > >>>>>>> The above known issue still remains. > >>>>>> > >>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list > >>>>>> extension > >>>>>> should work just fine, AFAIK. > >>>>> > >>>>> You added a blank line to the LDIF file. This is an entry separator, so > >>>>> the objectClasses after the blank line don't belong to cn=schema, so > >>>>> they aren't considered in the update. > >>>>> Without the blank line it works fine. > >>>> > >>>> Thanks for the catch! > >>>> > >>>> Here is a version without the blank line. > >>> > >>> I forgot to remove the old steps defines. This patch performs this > >>> cleanup. > >> > >> I am now wondering, is the global config object really the nest place to > >> add these OTP specific settings? > >> > >> I would prefer not to overload the object and instead: > >> - create new ipaOTPConfig objectclass > >> - add it to cn=otp,$SUFFIX > >> - create otpconfig-mod and otpconfig-show commands to follow an example > >> of dnsconfig-* and trustconfig-* commands > >> > >> IMO, this would allow more flexibility for the OTP settings and would > >> also scale better for the future updates. > > > > +1 > > > > I will comment the patch as if ^^ would not exist because it will still be > > needed in the new plugin. > > > > Because of ^^ I did not test, just read. > > > > 1. Got: > > install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > > recommended in array initializers > > > > Please run: > > jsl -nofilelisting -nosummary -nologo -conf jsl.conf > > in install/ui directory > > > > The goal is no have no warnings and errors. > > > > 2. new attrs should be added to 'System: Read Global Configuration' managed > > permission > > +1. Though if we go with OTP config, it should be called > > System: Read OTP Configuration > > Martin Attached is a new set of patches that replaces this single patch. This now fixes multiple issues. I now create two new entries: * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX There are two corresponding CLI commands: * totpconfig-(show|mod) * hotpconfig-(show|mod) There is no UI support for this yet (pointers welcome). This is designed so that eventually tokens can grow a per-token override, but I have not yet implemented this feature (it should be easy in the future). Additionally, I had to do some shared refactoring to address issues in ipa-otp-lasttoken, which is why all of these are now merged into a single patch set. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Make-token-auth-and-sync-windows-configurable.patch Type: text/x-patch Size: 39877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Enable-last-token-deletion-when-password-auth-type-i.patch Type: text/x-patch Size: 10624 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Move-authentication-configuration-cache-into-libotp.patch Type: text/x-patch Size: 38558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Preliminary-refactoring-of-libotp-files.patch Type: text/x-patch Size: 24468 bytes Desc: not available URL: From tbabej at redhat.com Wed Nov 12 23:35:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Nov 2014 00:35:41 +0100 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <54635649.1070201@redhat.com> References: <54635649.1070201@redhat.com> Message-ID: <5463EECD.8010504@redhat.com> On 11/12/2014 01:44 PM, Martin Kosek wrote: > Hi folks, > > With Petr changing focus out of FreeIPA, somebody will need to replace his work > as the person behind FreeIPA Transifex translation. > > I think this is now the right time and place to ask - Is Transifex still the > translation tool we want to continue supporting? I know there were objections > in the past it is not completely open source. But AFAIK, it is one of the most > used ones, even OpenStack uses it. > > If no, we need to find something better. If yes, we will need to make sure the > process is well documented on the FreeIPA.org wiki + integrated to our Release > process so that it can be handed to someone else. (volunteers? :) > > Thanks. > I'll gladly take the translations, I've translated several projects, and Zanata looks interesting too learn to work with. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From npmccallum at redhat.com Thu Nov 13 06:39:38 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 01:39:38 -0500 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location In-Reply-To: <54607288.7040009@redhat.com> References: <1415375478.8166.1.camel@redhat.com> <546065BC.1010607@redhat.com> <20141110073123.GE4107@redhat.com> <54607288.7040009@redhat.com> Message-ID: <1415860778.9222.0.camel@redhat.com> On Mon, 2014-11-10 at 09:08 +0100, Martin Kosek wrote: > On 11/10/2014 08:31 AM, Alexander Bokovoy wrote: > > On Mon, 10 Nov 2014, Jan Cholasta wrote: > >> Hi, > >> > >> Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a): > >>> https://fedorahosted.org/freeipa/ticket/4693 > >> > >> Is it good enough to just say "No YubiKey found"? Would it make sense to log > >> the original message, for the sake of debugging why the yubikey was not found? > > This is logged on the client side so it only would be visible if you > > would run 'ipa' tool with -v. Perhaps useful but my practice with > > yubikeys says that most of issues are basically permission-related: > > you've inserted the key and udev rules didn't change access to allow > > getting to it via libusb. In this case our debugging will hardly be > > helpful beyond 'yes, it is not accessible' which is already conveyed by > > the original message. > > Ok. Though IMO, passing the USBError string to the error would still be a good > thing to do - unless we have a strong reason to hide it. Error stating "Access > denied (insufficient permissions)" would steer the person closer to the root > cause that just "No YubiKey found". It took a bit to figure out exactly how to handle the errors, but the attached patch passes the error codes through. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0079.1-Catch-USBError-during-YubiKey-location.patch Type: text/x-patch Size: 1262 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 13 06:45:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 01:45:22 -0500 Subject: [Freeipa-devel] [PATCH 0077] Improve otptoken help messages In-Reply-To: <54606CC0.8060803@redhat.com> References: <1415305490.3273.6.camel@redhat.com> <54606CC0.8060803@redhat.com> Message-ID: <1415861122.9222.1.camel@redhat.com> On Mon, 2014-11-10 at 08:44 +0100, Jan Cholasta wrote: > Hi, > > Dne 6.11.2014 v 21:24 Nathaniel McCallum napsal(a): > > https://fedorahosted.org/freeipa/ticket/4689 > > we don't usually use the "Set the" prefix in doc kwargs, so IMO it > should not be used here as well. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0077.1-Improve-otptoken-help-messages.patch Type: text/x-patch Size: 4371 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 13 06:51:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 01:51:08 -0500 Subject: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them In-Reply-To: <54606B01.1000202@redhat.com> References: <1414182086.13428.7.camel@redhat.com> <54606B01.1000202@redhat.com> Message-ID: <1415861468.9222.2.camel@redhat.com> On Mon, 2014-11-10 at 08:36 +0100, Jan Cholasta wrote: > Hi, > > Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): > > https://fedorahosted.org/freeipa/ticket/4642 > > please use "userobj.handle_not_found(owner)" instead of raising NotFound > manually. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0075.1-Ensure-users-exist-when-assigning-tokens-to-them.patch Type: text/x-patch Size: 1128 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 13 06:53:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 01:53:59 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1415306034.3273.8.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> Message-ID: <1415861639.9222.3.camel@redhat.com> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: > This is possible because python-qrcode's output now fits in a standard > terminal. Also, update ipa-otp-import and otptoken-add-yubikey to > disable QR code output as it doesn't make sense in these contexts. > > https://fedorahosted.org/freeipa/ticket/4703 I removed the period from the doc string to maintain consistency with the rest of the plugin. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0078.1-Enable-QR-code-display-by-default-in-otptoken-add.patch Type: text/x-patch Size: 3096 bytes Desc: not available URL: From mkosek at redhat.com Thu Nov 13 07:48:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Nov 2014 08:48:38 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415831860.3363.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> Message-ID: <54646256.5090908@redhat.com> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>> On 7.11.2014 08:58, Martin Kosek wrote: >>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>> >>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>> how to >>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>> However, >>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>> on the >>>>>>>>>> server. What am I doing wrong? >>>>>>>>>> >>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>> works >>>>>>>>>> just fine. >>>>>>>>> >>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>> attribute >>>>>>>>> names. >>>>>>>> >>>>>>>> Thanks Nathaniel! >>>>>>>> >>>>>>>>> The above known issue still remains. >>>>>>>> >>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>> extension >>>>>>>> should work just fine, AFAIK. >>>>>>> >>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>> they aren't considered in the update. >>>>>>> Without the blank line it works fine. >>>>>> >>>>>> Thanks for the catch! >>>>>> >>>>>> Here is a version without the blank line. >>>>> >>>>> I forgot to remove the old steps defines. This patch performs this >>>>> cleanup. >>>> >>>> I am now wondering, is the global config object really the nest place to >>>> add these OTP specific settings? >>>> >>>> I would prefer not to overload the object and instead: >>>> - create new ipaOTPConfig objectclass >>>> - add it to cn=otp,$SUFFIX >>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>> of dnsconfig-* and trustconfig-* commands >>>> >>>> IMO, this would allow more flexibility for the OTP settings and would >>>> also scale better for the future updates. >>> >>> +1 >>> >>> I will comment the patch as if ^^ would not exist because it will still be >>> needed in the new plugin. >>> >>> Because of ^^ I did not test, just read. >>> >>> 1. Got: >>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>> recommended in array initializers >>> >>> Please run: >>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>> in install/ui directory >>> >>> The goal is no have no warnings and errors. >>> >>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>> permission >> >> +1. Though if we go with OTP config, it should be called >> >> System: Read OTP Configuration >> >> Martin > > Attached is a new set of patches that replaces this single patch. This > now fixes multiple issues. > > I now create two new entries: > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > There are two corresponding CLI commands: > * totpconfig-(show|mod) > * hotpconfig-(show|mod) > > There is no UI support for this yet (pointers welcome). > > This is designed so that eventually tokens can grow a per-token > override, but I have not yet implemented this feature (it should be easy > in the future). > > Additionally, I had to do some shared refactoring to address issues in > ipa-otp-lasttoken, which is why all of these are now merged into a > single patch set. > > Nathaniel > Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want to make TOTP/HOTP token config as separate entries (to enable future per-token overrides), your approach should make sense. Rather adding Rob to CC for sanity. I am just not sure we should create them as separate plugins, I think the new commands should be rather added to otp plugin directly so that they show in "ipa help otptoken" instead of adding 2 new topics just for OTP config. Martin From npmccallum at redhat.com Thu Nov 13 07:51:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 02:51:23 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <54646256.5090908@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> Message-ID: <1415865083.9222.5.camel@redhat.com> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: > On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > >> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > >>> On 7.11.2014 08:58, Martin Kosek wrote: > >>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>>>> This patch gives the administrator variables to control the size of > >>>>>>>>>> the authentication and synchronization windows for OTP tokens. > >>>>>>>>>> > >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>>>> > >>>>>>>>>> NOTE: There is one known issue with this patch which I don't know > >>>>>>>>>> how to > >>>>>>>>>> solve. This patch changes the schema in > >>>>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. > >>>>>>>>>> However, > >>>>>>>>>> the modifications to the pre-existing objectClass do not show up > >>>>>>>>>> on the > >>>>>>>>>> server. What am I doing wrong? > >>>>>>>>>> > >>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch > >>>>>>>>>> works > >>>>>>>>>> just fine. > >>>>>>>>> > >>>>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>>>> attribute > >>>>>>>>> names. > >>>>>>>> > >>>>>>>> Thanks Nathaniel! > >>>>>>>> > >>>>>>>>> The above known issue still remains. > >>>>>>>> > >>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list > >>>>>>>> extension > >>>>>>>> should work just fine, AFAIK. > >>>>>>> > >>>>>>> You added a blank line to the LDIF file. This is an entry separator, so > >>>>>>> the objectClasses after the blank line don't belong to cn=schema, so > >>>>>>> they aren't considered in the update. > >>>>>>> Without the blank line it works fine. > >>>>>> > >>>>>> Thanks for the catch! > >>>>>> > >>>>>> Here is a version without the blank line. > >>>>> > >>>>> I forgot to remove the old steps defines. This patch performs this > >>>>> cleanup. > >>>> > >>>> I am now wondering, is the global config object really the nest place to > >>>> add these OTP specific settings? > >>>> > >>>> I would prefer not to overload the object and instead: > >>>> - create new ipaOTPConfig objectclass > >>>> - add it to cn=otp,$SUFFIX > >>>> - create otpconfig-mod and otpconfig-show commands to follow an example > >>>> of dnsconfig-* and trustconfig-* commands > >>>> > >>>> IMO, this would allow more flexibility for the OTP settings and would > >>>> also scale better for the future updates. > >>> > >>> +1 > >>> > >>> I will comment the patch as if ^^ would not exist because it will still be > >>> needed in the new plugin. > >>> > >>> Because of ^^ I did not test, just read. > >>> > >>> 1. Got: > >>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > >>> recommended in array initializers > >>> > >>> Please run: > >>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > >>> in install/ui directory > >>> > >>> The goal is no have no warnings and errors. > >>> > >>> 2. new attrs should be added to 'System: Read Global Configuration' managed > >>> permission > >> > >> +1. Though if we go with OTP config, it should be called > >> > >> System: Read OTP Configuration > >> > >> Martin > > > > Attached is a new set of patches that replaces this single patch. This > > now fixes multiple issues. > > > > I now create two new entries: > > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > > > There are two corresponding CLI commands: > > * totpconfig-(show|mod) > > * hotpconfig-(show|mod) > > > > There is no UI support for this yet (pointers welcome). > > > > This is designed so that eventually tokens can grow a per-token > > override, but I have not yet implemented this feature (it should be easy > > in the future). > > > > Additionally, I had to do some shared refactoring to address issues in > > ipa-otp-lasttoken, which is why all of these are now merged into a > > single patch set. > > > > Nathaniel > > > > Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want > to make TOTP/HOTP token config as separate entries (to enable future per-token > overrides), your approach should make sense. Rather adding Rob to CC for sanity. That would work too. I'm open to that. > I am just not sure we should create them as separate plugins, I think the new > commands should be rather added to otp plugin directly so that they show in > "ipa help otptoken" instead of adding 2 new topics just for OTP config. I can play with that. Nathaniel From mkosek at redhat.com Thu Nov 13 07:53:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Nov 2014 08:53:20 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415865083.9222.5.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> Message-ID: <54646370.1090304@redhat.com> On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: > On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: >> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>> >>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>>>> how to >>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>>>> However, >>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>>>> on the >>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>> >>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>>>> works >>>>>>>>>>>> just fine. >>>>>>>>>>> >>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>> attribute >>>>>>>>>>> names. >>>>>>>>>> >>>>>>>>>> Thanks Nathaniel! >>>>>>>>>> >>>>>>>>>>> The above known issue still remains. >>>>>>>>>> >>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>>>> extension >>>>>>>>>> should work just fine, AFAIK. >>>>>>>>> >>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>>>> they aren't considered in the update. >>>>>>>>> Without the blank line it works fine. >>>>>>>> >>>>>>>> Thanks for the catch! >>>>>>>> >>>>>>>> Here is a version without the blank line. >>>>>>> >>>>>>> I forgot to remove the old steps defines. This patch performs this >>>>>>> cleanup. >>>>>> >>>>>> I am now wondering, is the global config object really the nest place to >>>>>> add these OTP specific settings? >>>>>> >>>>>> I would prefer not to overload the object and instead: >>>>>> - create new ipaOTPConfig objectclass >>>>>> - add it to cn=otp,$SUFFIX >>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>>>> of dnsconfig-* and trustconfig-* commands >>>>>> >>>>>> IMO, this would allow more flexibility for the OTP settings and would >>>>>> also scale better for the future updates. >>>>> >>>>> +1 >>>>> >>>>> I will comment the patch as if ^^ would not exist because it will still be >>>>> needed in the new plugin. >>>>> >>>>> Because of ^^ I did not test, just read. >>>>> >>>>> 1. Got: >>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>>>> recommended in array initializers >>>>> >>>>> Please run: >>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>> in install/ui directory >>>>> >>>>> The goal is no have no warnings and errors. >>>>> >>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>>>> permission >>>> >>>> +1. Though if we go with OTP config, it should be called >>>> >>>> System: Read OTP Configuration >>>> >>>> Martin >>> >>> Attached is a new set of patches that replaces this single patch. This >>> now fixes multiple issues. >>> >>> I now create two new entries: >>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>> >>> There are two corresponding CLI commands: >>> * totpconfig-(show|mod) >>> * hotpconfig-(show|mod) >>> >>> There is no UI support for this yet (pointers welcome). >>> >>> This is designed so that eventually tokens can grow a per-token >>> override, but I have not yet implemented this feature (it should be easy >>> in the future). >>> >>> Additionally, I had to do some shared refactoring to address issues in >>> ipa-otp-lasttoken, which is why all of these are now merged into a >>> single patch set. >>> >>> Nathaniel >>> >> >> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want >> to make TOTP/HOTP token config as separate entries (to enable future per-token >> overrides), your approach should make sense. Rather adding Rob to CC for sanity. > > That would work too. I'm open to that. > >> I am just not sure we should create them as separate plugins, I think the new >> commands should be rather added to otp plugin directly so that they show in >> "ipa help otptoken" instead of adding 2 new topics just for OTP config. > > I can play with that. > > Nathaniel No worries ATM, you can wait for proper review. I was just looking at the new API to make sure we are on the same page - we seem to mostly are. Martin From pviktori at redhat.com Thu Nov 13 08:56:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Nov 2014 09:56:54 +0100 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <5463EECD.8010504@redhat.com> References: <54635649.1070201@redhat.com> <5463EECD.8010504@redhat.com> Message-ID: <54647256.5000606@redhat.com> On 11/13/2014 12:35 AM, Tomas Babej wrote: > > On 11/12/2014 01:44 PM, Martin Kosek wrote: >> Hi folks, >> >> With Petr changing focus out of FreeIPA, somebody will need to replace his work >> as the person behind FreeIPA Transifex translation. >> >> I think this is now the right time and place to ask - Is Transifex still the >> translation tool we want to continue supporting? I know there were objections >> in the past it is not completely open source. But AFAIK, it is one of the most >> used ones, even OpenStack uses it. >> >> If no, we need to find something better. If yes, we will need to make sure the >> process is well documented on the FreeIPA.org wiki + integrated to our Release >> process so that it can be handed to someone else. (volunteers? :) >> >> Thanks. >> > > I'll gladly take the translations, I've translated several projects, and > Zanata looks interesting too learn to work with. It would make sense to fix things up a bit when we move. Some notes: We probably don't want the ipa-2-2 resource any more. I don't know if Zanata has a more sane mechanism for versions. If not it would be nice to combine strings from all "active" releases and put that up for translation, so when the next IPA 4.1.x is released it can have the new translations. We might want to sort the strings in .po files in Git so the diffs aren't so big (use the --sort-output flag to msgattrib in strip-po). But still keep the source order for files uploaded to Zanata (the ones merge-po creates) ? the order is useful for translators. I keep a history of translations in a Git repo, as I don't trust clouds with my data. Might be useful: https://github.com/encukou/freeipa-translations Let me know if you have any questions regarding our translations setup. -- Petr? From mbasti at redhat.com Thu Nov 13 08:59:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 09:59:31 +0100 Subject: [Freeipa-devel] [PATCH 0163] Fix compiler warning for pk11helper module In-Reply-To: <546374E2.2040205@redhat.com> References: <546374E2.2040205@redhat.com> Message-ID: <546472F3.7000002@redhat.com> On 12/11/14 15:55, Martin Basti wrote: > Part of ticket: https://fedorahosted.org/freeipa/ticket/4657 > And here is the patch, sorry :-) -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0163-Fix-pk11helper-module-compiler-warnings.patch Type: text/x-patch Size: 3216 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 13 09:18:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 10:18:16 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <546382E4.6020706@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> Message-ID: <54647758.5030901@redhat.com> On 12/11/14 16:55, David Kupka wrote: > On 11/07/2014 03:22 PM, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >> Patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > LGTM, please rebase to ipa-4-0. > Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.0-mbasti-0158-Fix-upgrade-referint-plugin.patch Type: text/x-patch Size: 6085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.1-mbasti-0158-Fix-upgrade-referint-plugin.patch Type: text/x-patch Size: 6108 bytes Desc: not available URL: From jhrozek at redhat.com Thu Nov 13 09:28:49 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 13 Nov 2014 10:28:49 +0100 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <54647256.5000606@redhat.com> References: <54635649.1070201@redhat.com> <5463EECD.8010504@redhat.com> <54647256.5000606@redhat.com> Message-ID: <20141113092849.GC1920@hendrix.brq.redhat.com> On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: > On 11/13/2014 12:35 AM, Tomas Babej wrote: > > > >On 11/12/2014 01:44 PM, Martin Kosek wrote: > >>Hi folks, > >> > >>With Petr changing focus out of FreeIPA, somebody will need to replace his work > >>as the person behind FreeIPA Transifex translation. > >> > >>I think this is now the right time and place to ask - Is Transifex still the > >>translation tool we want to continue supporting? I know there were objections > >>in the past it is not completely open source. But AFAIK, it is one of the most > >>used ones, even OpenStack uses it. > >> > >>If no, we need to find something better. If yes, we will need to make sure the > >>process is well documented on the FreeIPA.org wiki + integrated to our Release > >>process so that it can be handed to someone else. (volunteers? :) > >> > >>Thanks. > >> > > > >I'll gladly take the translations, I've translated several projects, and > >Zanata looks interesting too learn to work with. > > It would make sense to fix things up a bit when we move. Some notes: > > We probably don't want the ipa-2-2 resource any more. I don't know if Zanata > has a more sane mechanism for versions. If not it would be nice to combine > strings from all "active" releases and put that up for translation, so when > the next IPA 4.1.x is released it can have the new translations. > We might want to sort the strings in .po files in Git so the diffs aren't so > big (use the --sort-output flag to msgattrib in strip-po). But still keep > the source order for files uploaded to Zanata (the ones merge-po creates) ? > the order is useful for translators. > I keep a history of translations in a Git repo, as I don't trust clouds with > my data. Might be useful: https://github.com/encukou/freeipa-translations > > Let me know if you have any questions regarding our translations setup. I'm curious, what is the reason you consider moving to Zanata? (Genuine question, SSSD is currently using Transifex and I admit I don't know much about the translation tools..) Feel free to point me to an older thread, but my quick search in freeipa-devel folder didn't turn up much.. From abokovoy at redhat.com Thu Nov 13 09:52:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Nov 2014 11:52:29 +0200 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <20141113092849.GC1920@hendrix.brq.redhat.com> References: <54635649.1070201@redhat.com> <5463EECD.8010504@redhat.com> <54647256.5000606@redhat.com> <20141113092849.GC1920@hendrix.brq.redhat.com> Message-ID: <20141113095229.GH3493@redhat.com> On Thu, 13 Nov 2014, Jakub Hrozek wrote: >On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: >> On 11/13/2014 12:35 AM, Tomas Babej wrote: >> > >> >On 11/12/2014 01:44 PM, Martin Kosek wrote: >> >>Hi folks, >> >> >> >>With Petr changing focus out of FreeIPA, somebody will need to replace his work >> >>as the person behind FreeIPA Transifex translation. >> >> >> >>I think this is now the right time and place to ask - Is Transifex still the >> >>translation tool we want to continue supporting? I know there were objections >> >>in the past it is not completely open source. But AFAIK, it is one of the most >> >>used ones, even OpenStack uses it. >> >> >> >>If no, we need to find something better. If yes, we will need to make sure the >> >>process is well documented on the FreeIPA.org wiki + integrated to our Release >> >>process so that it can be handed to someone else. (volunteers? :) >> >> >> >>Thanks. >> >> >> > >> >I'll gladly take the translations, I've translated several projects, and >> >Zanata looks interesting too learn to work with. >> >> It would make sense to fix things up a bit when we move. Some notes: >> >> We probably don't want the ipa-2-2 resource any more. I don't know if Zanata >> has a more sane mechanism for versions. If not it would be nice to combine >> strings from all "active" releases and put that up for translation, so when >> the next IPA 4.1.x is released it can have the new translations. >> We might want to sort the strings in .po files in Git so the diffs aren't so >> big (use the --sort-output flag to msgattrib in strip-po). But still keep >> the source order for files uploaded to Zanata (the ones merge-po creates) ? >> the order is useful for translators. >> I keep a history of translations in a Git repo, as I don't trust clouds with >> my data. Might be useful: https://github.com/encukou/freeipa-translations >> >> Let me know if you have any questions regarding our translations setup. > >I'm curious, what is the reason you consider moving to Zanata? (Genuine >question, SSSD is currently using Transifex and I admit I don't know >much about the translation tools..) > >Feel free to point me to an older thread, but my quick search in >freeipa-devel folder didn't turn up much.. Transifex is a commercial product that used to be a free software and not anymore. Old code on github has no resemblance to the current state of it. Zanata is a free software available under LGPL. It is actively supported by Red Hat as it is already used for JBoss family of projects. -- / Alexander Bokovoy From jcholast at redhat.com Thu Nov 13 10:24:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 11:24:32 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. In-Reply-To: <5460AE91.2010204@redhat.com> References: <545CD690.5030703@redhat.com> <54606740.7070104@redhat.com> <5460AE91.2010204@redhat.com> Message-ID: <546486E0.2060008@redhat.com> Dne 10.11.2014 v 13:24 David Kupka napsal(a): > On 11/10/2014 08:20 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 7.11.2014 v 15:26 David Kupka napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4611 >> >> I think you should use MutuallyExclusiveError. >> >> Honza >> > Thanks, that's the error class I was searching for. Unfortunately, I > didn't know this one so I used more abstract error class. > > Fixed patch attached. > Given the messages that are used for MutuallyExclusiveError everywhere else in the framework, I think a better message would be "gid cannot be set for external group". -- Jan Cholasta From jcholast at redhat.com Thu Nov 13 10:37:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 11:37:18 +0100 Subject: [Freeipa-devel] [PATCH 0157] Fix installer adds invalid zonemgr email In-Reply-To: <545CC8FD.300@redhat.com> References: <545CBC27.9080703@redhat.com> <545CC8FD.300@redhat.com> Message-ID: <546489DE.4080808@redhat.com> Dne 7.11.2014 v 14:28 David Kupka napsal(a): > On 11/07/2014 01:33 PM, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4707 >> Patch attached >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > I think that it would be better to use relative value (e.g.: > "hostmaster" instead of "hostmaster.my.example.zone."). > But this works, ACK. > Pushed to: master: a7162e7766150aa7577a42747a4d583a425f7271 ipa-4-1: 3ab75d70412921bf2362edefd6c9411cff7df92d -- Jan Cholasta From jcholast at redhat.com Thu Nov 13 10:49:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 11:49:42 +0100 Subject: [Freeipa-devel] [PATCH] 0672 - ipaplatform: Use the dirsrv service, not target In-Reply-To: <54623352.2000300@redhat.com> References: <54623352.2000300@redhat.com> Message-ID: <54648CC6.5040603@redhat.com> Hi, Dne 11.11.2014 v 17:03 Petr Viktorin napsal(a): > https://fedorahosted.org/freeipa/ticket/4709 > > With this patch, IPA should no longer call systemctl on dirsrv.tagret, > but rather on its concrete service. > > Since systemctl stop waits for shutdown of services (but not targets), > we can assume dirsrv will be down (and the database unlocked) after > stop() is done. > > There's a DS ticket [0] to explicitly tell systemd which process to wait > on, but in my experience, systemd guesses correctly even without that fix. > > [0] https://fedorahosted.org/389/ticket/47951 Thanks, ACK. Pushed to: master: e60ef1fe029594876bd0e075cd5efc0173743138 ipa-4-1: 082485c2832a51cf6018bc172881e67e979de69c Honza -- Jan Cholasta From tbordaz at redhat.com Thu Nov 13 11:02:50 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 13 Nov 2014 12:02:50 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <54647758.5030901@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> <54647758.5030901@redhat.com> Message-ID: <54648FDA.5070104@redhat.com> On 11/13/2014 10:18 AM, Martin Basti wrote: > On 12/11/14 16:55, David Kupka wrote: >> On 11/07/2014 03:22 PM, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >>> Patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> LGTM, please rebase to ipa-4-0. >> > Thanks. > Rebased patch for 4.0 attached. > Original patch for 4.1 and master attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, Just a novice question. If the RI config entry was something like: dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... nsslapd-pluginArg0: xxx nsslapd-pluginArg1: yyy nsslapd-pluginArg2: zzz nsslapd-pluginArg3: +++ Will it create an entry like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ or like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ nsslapd-pluginArg0: nsslapd-pluginArg1: nsslapd-pluginArg2: nsslapd-pluginArg3: Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 13 11:16:39 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 12:16:39 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <54648FDA.5070104@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> <54647758.5030901@redhat.com> <54648FDA.5070104@redhat.com> Message-ID: <54649317.1070002@redhat.com> On 13/11/14 12:02, thierry bordaz wrote: > On 11/13/2014 10:18 AM, Martin Basti wrote: >> On 12/11/14 16:55, David Kupka wrote: >>> On 11/07/2014 03:22 PM, Martin Basti wrote: >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >>>> Patch attached. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> LGTM, please rebase to ipa-4-0. >>> >> Thanks. >> Rebased patch for 4.0 attached. >> Original patch for 4.1 and master attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello, > > Just a novice question. If the RI config entry was something like: > > dn: cn=referential integrity postoperation,cn=plugins,cn=config > objectClass: top > ... > nsslapd-pluginArg0: xxx > nsslapd-pluginArg1: yyy > nsslapd-pluginArg2: zzz > nsslapd-pluginArg3: +++ > > Will it create an entry like > > dn: cn=referential integrity postoperation,cn=plugins,cn=config > objectClass: top > ... > > referint-update-delay: xxx > referint-logfile: yyy > referint-logchanges: zzz > referint-membership-attr: +++ > > or like > > dn: cn=referential integrity postoperation,cn=plugins,cn=config > objectClass: top > ... > > referint-update-delay: xxx > referint-logfile: yyy > referint-logchanges: zzz > referint-membership-attr: +++ > nsslapd-pluginArg0: > nsslapd-pluginArg1: > nsslapd-pluginArg2: > nsslapd-pluginArg3: > > Thanks > thierry > > Hello, It removes all nsslapd-pluginArg* referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ But I can check it again if you have any doubts. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Nov 13 11:17:26 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 13 Nov 2014 12:17:26 +0100 Subject: [Freeipa-devel] FreeIPA translations In-Reply-To: <20141113095229.GH3493@redhat.com> References: <54635649.1070201@redhat.com> <5463EECD.8010504@redhat.com> <54647256.5000606@redhat.com> <20141113092849.GC1920@hendrix.brq.redhat.com> <20141113095229.GH3493@redhat.com> Message-ID: <20141113111726.GJ1920@hendrix.brq.redhat.com> On Thu, Nov 13, 2014 at 11:52:29AM +0200, Alexander Bokovoy wrote: > On Thu, 13 Nov 2014, Jakub Hrozek wrote: > >On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: > >>On 11/13/2014 12:35 AM, Tomas Babej wrote: > >>> > >>>On 11/12/2014 01:44 PM, Martin Kosek wrote: > >>>>Hi folks, > >>>> > >>>>With Petr changing focus out of FreeIPA, somebody will need to replace his work > >>>>as the person behind FreeIPA Transifex translation. > >>>> > >>>>I think this is now the right time and place to ask - Is Transifex still the > >>>>translation tool we want to continue supporting? I know there were objections > >>>>in the past it is not completely open source. But AFAIK, it is one of the most > >>>>used ones, even OpenStack uses it. > >>>> > >>>>If no, we need to find something better. If yes, we will need to make sure the > >>>>process is well documented on the FreeIPA.org wiki + integrated to our Release > >>>>process so that it can be handed to someone else. (volunteers? :) > >>>> > >>>>Thanks. > >>>> > >>> > >>>I'll gladly take the translations, I've translated several projects, and > >>>Zanata looks interesting too learn to work with. > >> > >>It would make sense to fix things up a bit when we move. Some notes: > >> > >>We probably don't want the ipa-2-2 resource any more. I don't know if Zanata > >>has a more sane mechanism for versions. If not it would be nice to combine > >>strings from all "active" releases and put that up for translation, so when > >>the next IPA 4.1.x is released it can have the new translations. > >>We might want to sort the strings in .po files in Git so the diffs aren't so > >>big (use the --sort-output flag to msgattrib in strip-po). But still keep > >>the source order for files uploaded to Zanata (the ones merge-po creates) ? > >>the order is useful for translators. > >>I keep a history of translations in a Git repo, as I don't trust clouds with > >>my data. Might be useful: https://github.com/encukou/freeipa-translations > >> > >>Let me know if you have any questions regarding our translations setup. > > > >I'm curious, what is the reason you consider moving to Zanata? (Genuine > >question, SSSD is currently using Transifex and I admit I don't know > >much about the translation tools..) > > > >Feel free to point me to an older thread, but my quick search in > >freeipa-devel folder didn't turn up much.. > Transifex is a commercial product that used to be a free software and not > anymore. Old code on github has no resemblance to the current state of > it. I wasn't aware of this change. Thank you. > > Zanata is a free software available under LGPL. It is actively supported > by Red Hat as it is already used for JBoss family of projects. From mbasti at redhat.com Thu Nov 13 12:00:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 13:00:56 +0100 Subject: [Freeipa-devel] [PATCH 0159] FIX: DNS policy upgrade raises assertion error In-Reply-To: <545CD417.5040707@redhat.com> References: <545CD417.5040707@redhat.com> Message-ID: <54649D78.4020405@redhat.com> On 07/11/14 15:15, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4708 > Patch attached. > > As I and Honza discussed personally, the updated patch modifies place of the fix Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0159.2-Fix-DNS-policy-upgrade-raises-asertion-error.patch Type: text/x-patch Size: 1060 bytes Desc: not available URL: From dkupka at redhat.com Thu Nov 13 12:08:34 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 13 Nov 2014 13:08:34 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <54647758.5030901@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> <54647758.5030901@redhat.com> Message-ID: <54649F42.5020405@redhat.com> On 11/13/2014 10:18 AM, Martin Basti wrote: > On 12/11/14 16:55, David Kupka wrote: >> On 11/07/2014 03:22 PM, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >>> Patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> LGTM, please rebase to ipa-4-0. >> > Thanks. > Rebased patch for 4.0 attached. > Original patch for 4.1 and master attached. > Thanks, ACK. -- David Kupka From jcholast at redhat.com Thu Nov 13 12:13:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 13:13:06 +0100 Subject: [Freeipa-devel] [PATCH 0159] FIX: DNS policy upgrade raises assertion error In-Reply-To: <54649D78.4020405@redhat.com> References: <545CD417.5040707@redhat.com> <54649D78.4020405@redhat.com> Message-ID: <5464A052.10604@redhat.com> Hi, Dne 13.11.2014 v 13:00 Martin Basti napsal(a): > On 07/11/14 15:15, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4708 >> Patch attached. >> >> > As I and Honza discussed personally, the updated patch modifies place of > the fix > Updated patch attached > Thanks, ACK. Pushed to: ipa-4-0: e5ec47992cd641def024cc77c07f98ca66b7b673 ipa-4-1: 1b22a53717cd2ead8a8f3fec84d04dac698d8925 master: 40ea328a78bec511377b464700e3add09cedc2b9 Honza -- Jan Cholasta From pvoborni at redhat.com Thu Nov 13 12:13:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:13:43 +0100 Subject: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link. In-Reply-To: <5460697D.3030902@redhat.com> References: <545CD750.5050207@redhat.com> <5460697D.3030902@redhat.com> Message-ID: <5464A077.5070900@redhat.com> On 10.11.2014 08:30, Jan Cholasta wrote: > Hi, > > Dne 7.11.2014 v 15:29 David Kupka napsal(a): >> Depends on freeipa-dkupka-0028. >> https://fedorahosted.org/freeipa/ticket/4658 > > ACK. > > Honza > David, this patch doesn't apply on ipa-4-1 -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 12:16:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:16:48 +0100 Subject: [Freeipa-devel] [PATCH] 1110 fix search scope In-Reply-To: <1415310365.11046.1.camel@redhat.com> References: <545BE530.1090409@redhat.com> <1415310365.11046.1.camel@redhat.com> Message-ID: <5464A130.1010803@redhat.com> On 6.11.2014 22:46, Nathaniel McCallum wrote: > On Thu, 2014-11-06 at 16:16 -0500, Rob Crittenden wrote: >> The wrong search scope was being used to determine if a given master had >> a CA installed during ipa-csreplica-manage connect. > > ACK > Pushed to: master: c32ecbff8cfe219499c15afe34e617ec7a9297cf ipa-4-1: 606de21dd565cf0becc7f33e4d26565acf6940ae -- Petr Vobornik From tbordaz at redhat.com Thu Nov 13 12:16:36 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 13 Nov 2014 13:16:36 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <54649317.1070002@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> <54647758.5030901@redhat.com> <54648FDA.5070104@redhat.com> <54649317.1070002@redhat.com> Message-ID: <5464A124.6040803@redhat.com> On 11/13/2014 12:16 PM, Martin Basti wrote: > On 13/11/14 12:02, thierry bordaz wrote: >> On 11/13/2014 10:18 AM, Martin Basti wrote: >>> On 12/11/14 16:55, David Kupka wrote: >>>> On 11/07/2014 03:22 PM, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >>>>> Patch attached. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> LGTM, please rebase to ipa-4-0. >>>> >>> Thanks. >>> Rebased patch for 4.0 attached. >>> Original patch for 4.1 and master attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hello, >> >> Just a novice question. If the RI config entry was something like: >> >> dn: cn=referential integrity postoperation,cn=plugins,cn=config >> objectClass: top >> ... >> nsslapd-pluginArg0: xxx >> nsslapd-pluginArg1: yyy >> nsslapd-pluginArg2: zzz >> nsslapd-pluginArg3: +++ >> >> Will it create an entry like >> >> dn: cn=referential integrity postoperation,cn=plugins,cn=config >> objectClass: top >> ... >> >> referint-update-delay: xxx >> referint-logfile: yyy >> referint-logchanges: zzz >> referint-membership-attr: +++ >> >> or like >> >> dn: cn=referential integrity postoperation,cn=plugins,cn=config >> objectClass: top >> ... >> >> referint-update-delay: xxx >> referint-logfile: yyy >> referint-logchanges: zzz >> referint-membership-attr: +++ >> nsslapd-pluginArg0: >> nsslapd-pluginArg1: >> nsslapd-pluginArg2: >> nsslapd-pluginArg3: >> >> Thanks >> thierry >> >> > Hello, > > It removes all nsslapd-pluginArg* > referint-update-delay: xxx > referint-logfile: yyy > referint-logchanges: zzz > referint-membership-attr: +++ > > But I can check it again if you have any doubts. > Martin^2 > -- > Martin Basti Hi Martin, Thanks for the explanation. Reading generate_modlist(), I realize that it will do a mod/del on each 'nsslapd-pluginarg*' so they will be clearly removed. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Nov 13 12:17:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Nov 2014 13:17:47 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1415861639.9222.3.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> Message-ID: <5464A16B.7000307@redhat.com> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: > On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: >> This is possible because python-qrcode's output now fits in a standard >> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to >> disable QR code output as it doesn't make sense in these contexts. >> >> https://fedorahosted.org/freeipa/ticket/4703 > > I removed the period from the doc string to maintain consistency with > the rest of the plugin. > > Nathaniel > I am not reviewing, just curious. What is the purpose of --qrcode option with default=True? takes_options = LDAPCreate.takes_options + ( - Flag('qrcode?', label=_('Display QR code')), + Flag('qrcode', label=_('Display QR code'), default=True), ) How can user turn it off? Both passing no option and passing --qrcode will get the same result, no? :-) Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill qrcode=0 when it's enabled? (To achieve API compatibility with old clients). Martin From dkupka at redhat.com Thu Nov 13 12:20:29 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 13 Nov 2014 13:20:29 +0100 Subject: [Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade In-Reply-To: <5460CA07.9070101@redhat.com> References: <5460CA07.9070101@redhat.com> Message-ID: <5464A20D.40905@redhat.com> On 11/10/2014 03:21 PM, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4680 > > Entry > dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX > > must be updated before > dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX > > Patch attached > Martin^2 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK, thanks. -- David Kupka From pvoborni at redhat.com Thu Nov 13 12:28:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:28:42 +0100 Subject: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration In-Reply-To: <54649F42.5020405@redhat.com> References: <545CD5B0.3050002@redhat.com> <546382E4.6020706@redhat.com> <54647758.5030901@redhat.com> <54649F42.5020405@redhat.com> Message-ID: <5464A3FA.40900@redhat.com> On 13.11.2014 13:08, David Kupka wrote: > On 11/13/2014 10:18 AM, Martin Basti wrote: >> On 12/11/14 16:55, David Kupka wrote: >>> On 11/07/2014 03:22 PM, Martin Basti wrote: >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4622 >>>> Patch attached. >>>> >>> LGTM, please rebase to ipa-4-0. >>> >> Thanks. >> Rebased patch for 4.0 attached. >> Original patch for 4.1 and master attached. >> > > Thanks, ACK. > Pushed to: ipa-4-0: * 9a9eccb94bcade97edb8aa877aedc35c191745e5 Fix upgrade referint plugin ipa-4-1: * 65624c9d61ba0bf8a1e5e040357406712dd42245 Fix upgrade referint plugin master: * f62c7843ffeda1e841719cb35f9f773f186780a6 Fix upgrade referint plugin -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 12:32:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:32:56 +0100 Subject: [Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade In-Reply-To: <5464A20D.40905@redhat.com> References: <5460CA07.9070101@redhat.com> <5464A20D.40905@redhat.com> Message-ID: <5464A4F8.1000208@redhat.com> On 13.11.2014 13:20, David Kupka wrote: > On 11/10/2014 03:21 PM, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4680 >> >> Entry >> dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX >> >> must be updated before >> dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX >> >> Patch attached >> Martin^2 >> >> > Works for me, ACK, thanks. > Pushed to: master: * 2712b609cb1edb478aa6a55da1f6529befaa2edb Upgrade: fix trusts objectclass violationi ipa-4-1: * 60ff57b644e34b80784bd75c6c2da7a04d248b2c Upgrade: fix trusts objectclass violationi ipa-4-0: * ae9e6842736f785b8b6e24493540c520a89e95a8 Upgrade: fix trusts objectclass violationi -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 12:40:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:40:12 +0100 Subject: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis In-Reply-To: <5450F7A4.7030202@redhat.com> References: <20141028211136.GL26496@redhat.com> <5450DA21.6000009@redhat.com> <20141029132335.GA5100@redhat.com> <5450F7A4.7030202@redhat.com> Message-ID: <5464A6AC.9040102@redhat.com> On 29.10.2014 15:20, thierry bordaz wrote: > On 10/29/2014 02:23 PM, Alexander Bokovoy wrote: >> On Wed, 29 Oct 2014, thierry bordaz wrote: >>> The patches fixed the test case in >>> https://bugzilla.redhat.com/show_bug.cgi?id=1157989. >> > Hi Alexander, > > The patches are good to me. Ack > > thanks > thierry was pushed to master: * https://git.fedorahosted.org/cgit/slapi-nis.git/commit/?id=778c95866f28d894822e37223b69816981d29529 * https://git.fedorahosted.org/cgit/slapi-nis.git/commit/?id=c9c9d1413a6950344bc842024fda84212cc7322f part of slapi-nis-0.54.1 -- Petr Vobornik From dkupka at redhat.com Thu Nov 13 12:45:16 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 13 Nov 2014 13:45:16 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. In-Reply-To: <546486E0.2060008@redhat.com> References: <545CD690.5030703@redhat.com> <54606740.7070104@redhat.com> <5460AE91.2010204@redhat.com> <546486E0.2060008@redhat.com> Message-ID: <5464A7DC.1060808@redhat.com> On 11/13/2014 11:24 AM, Jan Cholasta wrote: > Dne 10.11.2014 v 13:24 David Kupka napsal(a): >> On 11/10/2014 08:20 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 7.11.2014 v 15:26 David Kupka napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4611 >>> >>> I think you should use MutuallyExclusiveError. >>> >>> Honza >>> >> Thanks, that's the error class I was searching for. Unfortunately, I >> didn't know this one so I used more abstract error class. >> >> Fixed patch attached. >> > > Given the messages that are used for MutuallyExclusiveError everywhere > else in the framework, I think a better message would be "gid cannot be > set for external group". > Fixed patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0027-3-Produce-better-error-in-group-add-command.patch Type: text/x-patch Size: 1061 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 13 12:52:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:52:12 +0100 Subject: [Freeipa-devel] [PATCH] 0028 Remove unneeded internal methods. Move code to public, methods. In-Reply-To: <5461C683.50004@redhat.com> References: <545CD701.5030909@redhat.com> <5460677C.1050303@redhat.com> <5461C683.50004@redhat.com> Message-ID: <5464A97C.3020201@redhat.com> On 11.11.2014 09:19, Petr Viktorin wrote: > On 11/10/2014 08:21 AM, Jan Cholasta wrote: >> Hi, ACK. >> > > Pushed to master: 82c3c2b242c3f2b8113c2021cf4d17cab54c2a86 > Pushed to ipa-4-1: 814479a5678741f106283b61666e4bd093852fa7 (required for David's patch #29) -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 12:55:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 13:55:21 +0100 Subject: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link. In-Reply-To: <5464A077.5070900@redhat.com> References: <545CD750.5050207@redhat.com> <5460697D.3030902@redhat.com> <5464A077.5070900@redhat.com> Message-ID: <5464AA39.2010508@redhat.com> On 13.11.2014 13:13, Petr Vobornik wrote: > On 10.11.2014 08:30, Jan Cholasta wrote: >> Hi, >> >> Dne 7.11.2014 v 15:29 David Kupka napsal(a): >>> Depends on freeipa-dkupka-0028. >>> https://fedorahosted.org/freeipa/ticket/4658 >> >> ACK. >> >> Honza >> > > David, > > this patch doesn't apply on ipa-4-1 prerequisite patch #28 was resolved on ipa-4-1. Patch #29 was pushed to: master: e28eb13907053ca9d49e4bf66cb32820f1a2ef1d ipa-4-1: 51795254b2384a4b12908804b53c3da56e70f946 -- Petr Vobornik From jcholast at redhat.com Thu Nov 13 12:59:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 13:59:20 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <546353A5.505@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> <546353A5.505@redhat.com> Message-ID: <5464AB28.5080405@redhat.com> Dne 12.11.2014 v 13:33 Martin Basti napsal(a): > On 11/11/14 16:58, Jan Cholasta wrote: >> Hi, >> >> Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >>> Using specfile to create file doesn't work if named user is not on >>> system. >>> Appropriate permission have to be set during ipa-dns installation. >>> >>> Patch attached >>> >> >> Why is the directory set up in dnskeysyncinstance instead of >> bindinstance? > Because, dnskeysyncinstance is the daemon which requires permission change. > (dir is created by dyndb-ldap plugin) OK. But please rename the method to something more suitable (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. Also please change the ticket link to (cloned from BZ). > >> >> The original patch was released with 4.1.1, shouldn't there be update >> in ipa-upgradeconfig? > Cases: > 1) fresh RPM install, no named user during RPM install -> named doesn't > start, user had to fix it immediately, can't wait until next release. > > 2) fresh RPM install, named user -> no impact > > 3) upgrade IPA with DNS -> no impact > > 4) upgrade IPA without DNS -> after DNS installation, same as 1) > > 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not > work (If user doesnt use DNSSEC) > > Only 5) looks serious for me, so here is updated patch. Could you do the update without the code duplication? In similar code an appropriate *instance method is usually called. > > Martin^2 >> >> Honza >> > > Honza -- Jan Cholasta From jcholast at redhat.com Thu Nov 13 13:07:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Nov 2014 14:07:54 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command. In-Reply-To: <5464A7DC.1060808@redhat.com> References: <545CD690.5030703@redhat.com> <54606740.7070104@redhat.com> <5460AE91.2010204@redhat.com> <546486E0.2060008@redhat.com> <5464A7DC.1060808@redhat.com> Message-ID: <5464AD2A.6040704@redhat.com> Dne 13.11.2014 v 13:45 David Kupka napsal(a): > On 11/13/2014 11:24 AM, Jan Cholasta wrote: >> Dne 10.11.2014 v 13:24 David Kupka napsal(a): >>> On 11/10/2014 08:20 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 7.11.2014 v 15:26 David Kupka napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4611 >>>> >>>> I think you should use MutuallyExclusiveError. >>>> >>>> Honza >>>> >>> Thanks, that's the error class I was searching for. Unfortunately, I >>> didn't know this one so I used more abstract error class. >>> >>> Fixed patch attached. >>> >> >> Given the messages that are used for MutuallyExclusiveError everywhere >> else in the framework, I think a better message would be "gid cannot be >> set for external group". >> > Fixed patch attached. > Thanks, ACK. Pushed to: master: b032debd233c70541e52d3ee677cb82f9840b291 ipa-4-1: cef8e06f8adc116936238264abf5883a0e49ec0a Honza -- Jan Cholasta From pvoborni at redhat.com Thu Nov 13 13:29:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 14:29:00 +0100 Subject: [Freeipa-devel] [PATCH] 787 webui: add radius fields to user page Message-ID: <5464B21C.2060509@redhat.com> add --radius=ID --radius-username=radiusUserName to Web UI https://fedorahosted.org/freeipa/ticket/4686 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0787-webui-add-radius-fields-to-user-page.patch Type: text/x-patch Size: 1439 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 13 13:50:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 14:50:17 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <5464AB28.5080405@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> <546353A5.505@redhat.com> <5464AB28.5080405@redhat.com> Message-ID: <5464B719.9090304@redhat.com> On 13/11/14 13:59, Jan Cholasta wrote: > Dne 12.11.2014 v 13:33 Martin Basti napsal(a): >> On 11/11/14 16:58, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >>>> Using specfile to create file doesn't work if named user is not on >>>> system. >>>> Appropriate permission have to be set during ipa-dns installation. >>>> >>>> Patch attached >>>> >>> >>> Why is the directory set up in dnskeysyncinstance instead of >>> bindinstance? >> Because, dnskeysyncinstance is the daemon which requires permission >> change. >> (dir is created by dyndb-ldap plugin) > > OK. But please rename the method to something more suitable > (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. > > Also please change the ticket link to > (cloned from BZ). > >> >>> >>> The original patch was released with 4.1.1, shouldn't there be update >>> in ipa-upgradeconfig? >> Cases: >> 1) fresh RPM install, no named user during RPM install -> named doesn't >> start, user had to fix it immediately, can't wait until next release. >> >> 2) fresh RPM install, named user -> no impact >> >> 3) upgrade IPA with DNS -> no impact >> >> 4) upgrade IPA without DNS -> after DNS installation, same as 1) >> >> 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not >> work (If user doesnt use DNSSEC) >> >> Only 5) looks serious for me, so here is updated patch. > > Could you do the update without the code duplication? In similar code > an appropriate *instance method is usually called. > >> >> Martin^2 >>> >>> Honza >>> >> >> > > Honza > Thanks. updated patch attached. Martin^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0161.3-Fix-named-working-directory-permissions.patch Type: text/x-patch Size: 6633 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 13 14:34:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 15:34:22 +0100 Subject: [Freeipa-devel] [PATCH 0077] Improve otptoken help messages In-Reply-To: <1415861122.9222.1.camel@redhat.com> References: <1415305490.3273.6.camel@redhat.com> <54606CC0.8060803@redhat.com> <1415861122.9222.1.camel@redhat.com> Message-ID: <5464C16E.3000205@redhat.com> On 13.11.2014 07:45, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 08:44 +0100, Jan Cholasta wrote: >> Hi, >> >> Dne 6.11.2014 v 21:24 Nathaniel McCallum napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4689 >> >> we don't usually use the "Set the" prefix in doc kwargs, so IMO it >> should not be used here as well. > > Fixed. > ACK Pushed to: master: 93ff9ec087854012d6ccb521d17981f4d25e5c23 ipa-4-1: 444ae28ca58ece3ed74511a25d69881f8e0e2227 -- Petr Vobornik From npmccallum at redhat.com Thu Nov 13 15:00:56 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 10:00:56 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5464A16B.7000307@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> Message-ID: <1415890856.9116.5.camel@redhat.com> On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: > On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: > > On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: > >> This is possible because python-qrcode's output now fits in a standard > >> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to > >> disable QR code output as it doesn't make sense in these contexts. > >> > >> https://fedorahosted.org/freeipa/ticket/4703 > > > > I removed the period from the doc string to maintain consistency with > > the rest of the plugin. > > > > Nathaniel > > > > I am not reviewing, just curious. What is the purpose of --qrcode option with > default=True? > > takes_options = LDAPCreate.takes_options + ( > - Flag('qrcode?', label=_('Display QR code')), > + Flag('qrcode', label=_('Display QR code'), default=True), > ) > > How can user turn it off? Both passing no option and passing --qrcode will get > the same result, no? :-) > > Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill > qrcode=0 when it's enabled? (To achieve API compatibility with old clients). I see three options: 1. Don't let the user turn it off from the command line (he can still turn it off from the Python API). 2. Change it to --no-qrcode (API change) 3. Change the type to Bool (API change) Like you, I like #2 the best. Attached is an implementation. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0078.1-Enable-QR-code-display-by-default-in-otptoken-add.patch Type: text/x-patch Size: 4761 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 13 15:13:58 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 16:13:58 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1415890856.9116.5.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> Message-ID: <5464CAB6.9020501@redhat.com> On 13.11.2014 16:00, Nathaniel McCallum wrote: > On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: >> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: >>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: >>>> This is possible because python-qrcode's output now fits in a standard >>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to >>>> disable QR code output as it doesn't make sense in these contexts. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4703 >>> >>> I removed the period from the doc string to maintain consistency with >>> the rest of the plugin. >>> >>> Nathaniel >>> >> >> I am not reviewing, just curious. What is the purpose of --qrcode option with >> default=True? >> >> takes_options = LDAPCreate.takes_options + ( >> - Flag('qrcode?', label=_('Display QR code')), >> + Flag('qrcode', label=_('Display QR code'), default=True), >> ) >> >> How can user turn it off? Both passing no option and passing --qrcode will get >> the same result, no? :-) >> >> Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill >> qrcode=0 when it's enabled? (To achieve API compatibility with old clients). > > I see three options: > 1. Don't let the user turn it off from the command line (he can still > turn it off from the Python API). > > 2. Change it to --no-qrcode (API change) > > 3. Change the type to Bool (API change) > > Like you, I like #2 the best. Attached is an implementation. I like --no-qrcode as well. Should we also keep qrcode as 'no_option' to maintain API compatibility (but not CLI)? -- Petr Vobornik From npmccallum at redhat.com Thu Nov 13 15:19:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 10:19:16 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5464CAB6.9020501@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> Message-ID: <1415891956.9116.6.camel@redhat.com> On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote: > On 13.11.2014 16:00, Nathaniel McCallum wrote: > > On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: > >> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: > >>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: > >>>> This is possible because python-qrcode's output now fits in a standard > >>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to > >>>> disable QR code output as it doesn't make sense in these contexts. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4703 > >>> > >>> I removed the period from the doc string to maintain consistency with > >>> the rest of the plugin. > >>> > >>> Nathaniel > >>> > >> > >> I am not reviewing, just curious. What is the purpose of --qrcode option with > >> default=True? > >> > >> takes_options = LDAPCreate.takes_options + ( > >> - Flag('qrcode?', label=_('Display QR code')), > >> + Flag('qrcode', label=_('Display QR code'), default=True), > >> ) > >> > >> How can user turn it off? Both passing no option and passing --qrcode will get > >> the same result, no? :-) > >> > >> Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill > >> qrcode=0 when it's enabled? (To achieve API compatibility with old clients). > > > > I see three options: > > 1. Don't let the user turn it off from the command line (he can still > > turn it off from the Python API). > > > > 2. Change it to --no-qrcode (API change) > > > > 3. Change the type to Bool (API change) > > > > Like you, I like #2 the best. Attached is an implementation. > > I like --no-qrcode as well. > > Should we also keep qrcode as 'no_option' to maintain API compatibility > (but not CLI)? I don't think it is necessary. It only makes sense to specify --qrcode in an interactive session. From pvoborni at redhat.com Thu Nov 13 15:19:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 16:19:17 +0100 Subject: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them In-Reply-To: <1415861468.9222.2.camel@redhat.com> References: <1414182086.13428.7.camel@redhat.com> <54606B01.1000202@redhat.com> <1415861468.9222.2.camel@redhat.com> Message-ID: <5464CBF5.3020206@redhat.com> On 13.11.2014 07:51, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 08:36 +0100, Jan Cholasta wrote: >> Hi, >> >> Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4642 >> >> please use "userobj.handle_not_found(owner)" instead of raising NotFound >> manually. > > Fixed. > Pushed to: master: c38e2d7394522a4b4f98f9d7e1ce234fa3be985f ipa-4-1: 2c1d40bf1f649edb82eafb29b7ce62a922e051f6 -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 15:20:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 16:20:05 +0100 Subject: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them In-Reply-To: <5464CBF5.3020206@redhat.com> References: <1414182086.13428.7.camel@redhat.com> <54606B01.1000202@redhat.com> <1415861468.9222.2.camel@redhat.com> <5464CBF5.3020206@redhat.com> Message-ID: <5464CC25.2090306@redhat.com> On 13.11.2014 16:19, Petr Vobornik wrote: > On 13.11.2014 07:51, Nathaniel McCallum wrote: >> On Mon, 2014-11-10 at 08:36 +0100, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4642 >>> >>> please use "userobj.handle_not_found(owner)" instead of raising NotFound >>> manually. >> >> Fixed. and also ACK :) > > Pushed to: > master: c38e2d7394522a4b4f98f9d7e1ce234fa3be985f > ipa-4-1: 2c1d40bf1f649edb82eafb29b7ce62a922e051f6 -- Petr Vobornik From pvoborni at redhat.com Thu Nov 13 15:40:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Nov 2014 16:40:45 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1415891956.9116.6.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> Message-ID: <5464D0FD.2040905@redhat.com> On 13.11.2014 16:19, Nathaniel McCallum wrote: > On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote: >> On 13.11.2014 16:00, Nathaniel McCallum wrote: >>> On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: >>>> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: >>>>>> This is possible because python-qrcode's output now fits in a standard >>>>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to >>>>>> disable QR code output as it doesn't make sense in these contexts. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4703 >>>>> >>>>> I removed the period from the doc string to maintain consistency with >>>>> the rest of the plugin. >>>>> >>>>> Nathaniel >>>>> >>>> >>>> I am not reviewing, just curious. What is the purpose of --qrcode option with >>>> default=True? >>>> >>>> takes_options = LDAPCreate.takes_options + ( >>>> - Flag('qrcode?', label=_('Display QR code')), >>>> + Flag('qrcode', label=_('Display QR code'), default=True), >>>> ) >>>> >>>> How can user turn it off? Both passing no option and passing --qrcode will get >>>> the same result, no? :-) >>>> >>>> Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill >>>> qrcode=0 when it's enabled? (To achieve API compatibility with old clients). >>> >>> I see three options: >>> 1. Don't let the user turn it off from the command line (he can still >>> turn it off from the Python API). >>> >>> 2. Change it to --no-qrcode (API change) >>> >>> 3. Change the type to Bool (API change) >>> >>> Like you, I like #2 the best. Attached is an implementation. >> >> I like --no-qrcode as well. >> >> Should we also keep qrcode as 'no_option' to maintain API compatibility >> (but not CLI)? > > I don't think it is necessary. It only makes sense to specify --qrcode > in an interactive session. > Makes sense. ACK Not pushing yet to give time for NACK if anybody doesn't agree with the API change. -- Petr Vobornik From mbasti at redhat.com Thu Nov 13 15:49:23 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 16:49:23 +0100 Subject: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI Message-ID: <5464D303.9070103@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4647 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0164-Fix-warning-message-should-not-contain-CLI-commands.patch Type: text/x-patch Size: 3168 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 13 15:57:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Nov 2014 16:57:25 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5464D0FD.2040905@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> Message-ID: <5464D4E5.4080003@redhat.com> On 11/13/2014 04:40 PM, Petr Vobornik wrote: > On 13.11.2014 16:19, Nathaniel McCallum wrote: >> On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote: >>> On 13.11.2014 16:00, Nathaniel McCallum wrote: >>>> On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: >>>>> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: >>>>>>> This is possible because python-qrcode's output now fits in a >>>>>>> standard >>>>>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to >>>>>>> disable QR code output as it doesn't make sense in these contexts. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4703 >>>>>> >>>>>> I removed the period from the doc string to maintain consistency with >>>>>> the rest of the plugin. >>>>>> >>>>>> Nathaniel >>>>>> >>>>> >>>>> I am not reviewing, just curious. What is the purpose of --qrcode >>>>> option with >>>>> default=True? >>>>> >>>>> takes_options = LDAPCreate.takes_options + ( >>>>> - Flag('qrcode?', label=_('Display QR code')), >>>>> + Flag('qrcode', label=_('Display QR code'), default=True), >>>>> ) >>>>> >>>>> How can user turn it off? Both passing no option and passing >>>>> --qrcode will get >>>>> the same result, no? :-) >>>>> >>>>> Shouldn't we instead change --qrcode to --no-qrcode and process >>>>> somehow fill >>>>> qrcode=0 when it's enabled? (To achieve API compatibility with old >>>>> clients). >>>> >>>> I see three options: >>>> 1. Don't let the user turn it off from the command line (he can still >>>> turn it off from the Python API). >>>> >>>> 2. Change it to --no-qrcode (API change) >>>> >>>> 3. Change the type to Bool (API change) >>>> >>>> Like you, I like #2 the best. Attached is an implementation. >>> >>> I like --no-qrcode as well. >>> >>> Should we also keep qrcode as 'no_option' to maintain API compatibility >>> (but not CLI)? >> >> I don't think it is necessary. It only makes sense to specify --qrcode >> in an interactive session. >> > > Makes sense. > > ACK > > Not pushing yet to give time for NACK if anybody doesn't agree with the > API change. Hold on, what is happening here? Aren't all clients since 4.0 sending the qrcode option to the server? We absolutely can not break backwards compatibility with released versions. We also should not break the CLI. Just make it a no-op option, and say it's deprecated in the doc. -- Petr? From npmccallum at redhat.com Thu Nov 13 17:02:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 12:02:51 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5464D4E5.4080003@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> Message-ID: <1415898171.9116.10.camel@redhat.com> On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote: > On 11/13/2014 04:40 PM, Petr Vobornik wrote: > > On 13.11.2014 16:19, Nathaniel McCallum wrote: > >> On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote: > >>> On 13.11.2014 16:00, Nathaniel McCallum wrote: > >>>> On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: > >>>>> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: > >>>>>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: > >>>>>>> This is possible because python-qrcode's output now fits in a > >>>>>>> standard > >>>>>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to > >>>>>>> disable QR code output as it doesn't make sense in these contexts. > >>>>>>> > >>>>>>> https://fedorahosted.org/freeipa/ticket/4703 > >>>>>> > >>>>>> I removed the period from the doc string to maintain consistency with > >>>>>> the rest of the plugin. > >>>>>> > >>>>>> Nathaniel > >>>>>> > >>>>> > >>>>> I am not reviewing, just curious. What is the purpose of --qrcode > >>>>> option with > >>>>> default=True? > >>>>> > >>>>> takes_options = LDAPCreate.takes_options + ( > >>>>> - Flag('qrcode?', label=_('Display QR code')), > >>>>> + Flag('qrcode', label=_('Display QR code'), default=True), > >>>>> ) > >>>>> > >>>>> How can user turn it off? Both passing no option and passing > >>>>> --qrcode will get > >>>>> the same result, no? :-) > >>>>> > >>>>> Shouldn't we instead change --qrcode to --no-qrcode and process > >>>>> somehow fill > >>>>> qrcode=0 when it's enabled? (To achieve API compatibility with old > >>>>> clients). > >>>> > >>>> I see three options: > >>>> 1. Don't let the user turn it off from the command line (he can still > >>>> turn it off from the Python API). > >>>> > >>>> 2. Change it to --no-qrcode (API change) > >>>> > >>>> 3. Change the type to Bool (API change) > >>>> > >>>> Like you, I like #2 the best. Attached is an implementation. > >>> > >>> I like --no-qrcode as well. > >>> > >>> Should we also keep qrcode as 'no_option' to maintain API compatibility > >>> (but not CLI)? > >> > >> I don't think it is necessary. It only makes sense to specify --qrcode > >> in an interactive session. > >> > > > > Makes sense. > > > > ACK > > > > Not pushing yet to give time for NACK if anybody doesn't agree with the > > API change. > > Hold on, what is happening here? > > Aren't all clients since 4.0 sending the qrcode option to the server? > We absolutely can not break backwards compatibility with released versions. > We also should not break the CLI. Just make it a no-op option, and say > it's deprecated in the doc. As I understand the current behavior, the qrcode option is *not* sent to the server by default in any scenario. The only thing this change would break would be if someone had scripted on top of this and had manually specified the qrcode option. I think this is extremely unlikely as scripts are much more likely to want to disable the qrcode output. Nathaniel From npmccallum at redhat.com Thu Nov 13 17:04:55 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 12:04:55 -0500 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type Message-ID: <1415898295.9116.12.camel@redhat.com> Additionally, fix a small bug in ipa-kdb so that the disabled User Auth Type is properly handled. https://fedorahosted.org/freeipa/ticket/4720 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0080-Expose-the-disabled-User-Auth-Type.patch Type: text/x-patch Size: 6774 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 13 17:28:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Nov 2014 18:28:27 +0100 Subject: [Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode Message-ID: <5464EA3B.3050004@redhat.com> To allow IDNA zonemgr email, value must be unicode not ASCII Ticket: https://fedorahosted.org/freeipa/ticket/4724 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0165-Fix-zonemgr-must-be-unicode-value.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 13 18:12:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Nov 2014 19:12:04 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1415898171.9116.10.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> Message-ID: <5464F474.3040807@redhat.com> On 11/13/2014 06:02 PM, Nathaniel McCallum wrote: > On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote: >> On 11/13/2014 04:40 PM, Petr Vobornik wrote: >>> On 13.11.2014 16:19, Nathaniel McCallum wrote: >>>> On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote: >>>>> On 13.11.2014 16:00, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote: >>>>>>> On 11/13/2014 07:53 AM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote: >>>>>>>>> This is possible because python-qrcode's output now fits in a >>>>>>>>> standard >>>>>>>>> terminal. Also, update ipa-otp-import and otptoken-add-yubikey to >>>>>>>>> disable QR code output as it doesn't make sense in these contexts. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4703 >>>>>>>> >>>>>>>> I removed the period from the doc string to maintain consistency with >>>>>>>> the rest of the plugin. >>>>>>>> >>>>>>>> Nathaniel >>>>>>>> >>>>>>> >>>>>>> I am not reviewing, just curious. What is the purpose of --qrcode >>>>>>> option with >>>>>>> default=True? >>>>>>> >>>>>>> takes_options = LDAPCreate.takes_options + ( >>>>>>> - Flag('qrcode?', label=_('Display QR code')), >>>>>>> + Flag('qrcode', label=_('Display QR code'), default=True), >>>>>>> ) >>>>>>> >>>>>>> How can user turn it off? Both passing no option and passing >>>>>>> --qrcode will get >>>>>>> the same result, no? :-) >>>>>>> >>>>>>> Shouldn't we instead change --qrcode to --no-qrcode and process >>>>>>> somehow fill >>>>>>> qrcode=0 when it's enabled? (To achieve API compatibility with old >>>>>>> clients). >>>>>> >>>>>> I see three options: >>>>>> 1. Don't let the user turn it off from the command line (he can still >>>>>> turn it off from the Python API). >>>>>> >>>>>> 2. Change it to --no-qrcode (API change) >>>>>> >>>>>> 3. Change the type to Bool (API change) >>>>>> >>>>>> Like you, I like #2 the best. Attached is an implementation. >>>>> >>>>> I like --no-qrcode as well. >>>>> >>>>> Should we also keep qrcode as 'no_option' to maintain API compatibility >>>>> (but not CLI)? >>>> >>>> I don't think it is necessary. It only makes sense to specify --qrcode >>>> in an interactive session. >>>> >>> >>> Makes sense. >>> >>> ACK >>> >>> Not pushing yet to give time for NACK if anybody doesn't agree with the >>> API change. >> >> Hold on, what is happening here? >> >> Aren't all clients since 4.0 sending the qrcode option to the server? >> We absolutely can not break backwards compatibility with released versions. >> We also should not break the CLI. Just make it a no-op option, and say >> it's deprecated in the doc. > > As I understand the current behavior, the qrcode option is *not* sent to > the server by default in any scenario. Nope, defaults are filled in by the client. (And also on the server if they're still missing; it's part of the common validation.) You can try it out, actually: $ ipa -vv otptoken-add ipa: INFO: trying https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json ipa: INFO: Forwarding 'otptoken_add' to json server 'https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json' ipa: INFO: Request: { "id": 0, "method": "otptoken_add", "params": [ [ null ], { "all": false, "ipatokenhotpcounter": 0, "ipatokenotpalgorithm": "sha1", "ipatokenotpdigits": 6, "ipatokenotpkey": "5\ufffdK\ufffd1\u000e\ufffd7,\ufffd_\ufffd\ufffd.0\ufffdM\ufffd\u0016\ufffd", "ipatokentotpclockoffset": 0, "ipatokentotptimestep": 30, "no_members": false, "qrcode": false, "raw": false, "type": "totp", "version": "2.108" } ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", ... -- Petr? From npmccallum at redhat.com Thu Nov 13 19:02:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 14:02:21 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <545CD9BD.2090601@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> Message-ID: <1415905341.26688.5.camel@redhat.com> On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek wrote: > >> > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > >>> Martin Kosek wrote: > >>> > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > >>>>> Martin Kosek wrote: > >>>>> > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > >>>>>>> Martin Kosek wrote: > >>>>>>> > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > >>>>>>>>> Nathaniel McCallum wrote: > >>>>>>>>> > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>>>>>>>>> > >>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>>>>>>>>> Patch attached. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>>>>>>>>> second timeouts and re-transmits when OTP is in place? > >>>>>>>>>>>> > >>>>>>>>>>>> What is the expected performance impact? Could it be > >>>>>>>>>>>> configured for OTP separately - somehow? (I guess that it is > >>>>>>>>>>>> not possible now ...) > >>>>>>>>>>> > >>>>>>>>>>> It benefits also communication of large packets (when large > >>>>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better > >>>>>>>>>>> choice for IPA in general. Especially given we have multiple > >>>>>>>>>>> KDC processes configured we do not want clients wasting KDC > >>>>>>>>>>> resources by making multiple processes do the same operation. > >>>>>>>>>> > >>>>>>>>>> So apparently this patch never got reviewed over a year ago. > >>>>>>>>>> > >>>>>>>>>> It was related to a bug which was opened in SSSD. However, when > >>>>>>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD > >>>>>>>>>> bug was closed but no corresponding FreeIPA bug was opened. The > >>>>>>>>>> patch then fell through the cracks. > >>>>>>>> > >>>>>>>> Right - without an associated ticket tracking the patch, it is > >>>>>>>> too easy to loose it unless the author prods people to review it. > >>>>>>>> > >>>>>>>>>> Without this patch, if OTP validation runs long we get > >>>>>>>>>> retransmits and failures. > >>>>>>>>>> > >>>>>>>>>> One question I have is how to handle this for upgrades since (I > >>>>>>>>>> think) this patch only handles new installs. > >>>>>>>>>> > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is > >>>>>>>>>> appreciated. > >>>>>>>>>> > >>>>>>>>>> I have attached a rebased version which has no other changes. > >>>>>>>>>> > >>>>>>>>>> Nathaniel > >>>>>>>>> > >>>>>>>>> I am not sure we can do much on updates, we do not have a > >>>>>>>>> client-update tool, I would just document it I guess. > >>>>>>>>> Otherwise we'd have to go back to sssd which can inject > >>>>>>>>> additional values in krb5.conf, however I am not sure it would > >>>>>>>>> be ok to set something like this in the sssd's pubconf > >>>>>>>>> includes ... > >>>>>>>> > >>>>>>>> Agreed, pubconf update does not sound right. > >>>>>>>> > >>>>>>>> However, we already update krb5.conf on client updates, in %post: > >>>>>>>> > >>>>>>>> %post client > >>>>>>>> if [ $1 -gt 1 ] ; then > >>>>>>>> # Has the client been configured? > >>>>>>>> restore=0 > >>>>>>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' > >>>>>>>> && restore=$(wc -l > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print > >>>>>>>> $1}') > >>>>>>>> > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > >>>>>>>> if ! grep -E -q > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > >>>>>>>> 2>/dev/null ; then > >>>>>>>> echo > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > >>>>>>>>>>> /etc/krb5.conf.ipanew > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > >>>>>>>> /sbin/restorecon /etc/krb5.conf > >>>>>>>> fi > >>>>>>>> fi > >>>>>>>> ... > >>>>>>>> > >>>>>>>> > >>>>>>>> This particular update is more difficult as not a first line > >>>>>>>> needs to be changed. Without adding ipa client update tool with > >>>>>>>> some reasonable krb5.conf parser, we could do something along > >>>>>>>> the lines of > >>>>>>>> > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = > >>>>>>>> 0/g' /etc/krb5.conf > >>>>>>>> > >>>>>>>> (tested), but it is not pretty. > >>>>>>> > >>>>>>> What happen the next time you run it again ? > >>>>>>> > >>>>>>> Simo. > >>>>>>> > >>>>>> > >>>>>> It would of course be added again, you would need to first grep for > >>>>>> presence of udp_preference_limit setting. Question is if this > >>>>>> approach is safe enough to be in our client %post upgrade. We > >>>>>> already upgrade krb5.conf here, just the change is much easier as > >>>>>> we just add a line to the beginning of the file. > >>>>> > >>>>> Well the concern (aside of duplication) is that an admin may > >>>>> "correct" the krb5.conf file to remove that option (for example > >>>>> because his clients also connect to a differen (older) KDC and must > >>>>> use UDP in preference. But now we end up messing with its krb5.conf > >>>>> every time an update is released. An update tool that keep tracks > >>>>> of whether a specific update has already been applied and does not > >>>>> retry every time would be needed IMO. > >>>>> > >>>>> Simo. > >>>> > >>>> In 4.1.x (as there is not much time to develop a separate client > >>>> update tool), we could grep just for "udp_preference_limit" presence > >>>> so that if admin changes it's value or comment it, it would not be > >>>> added again. > >>> > >>> Ok then maybe we add this: > >>> > >>> # The following value has been added by a freeipa client update > >>> # if you want to disable it, please comment it, do not delete it > >>> # or it will be re-added on the next update > >>> udp_preference_limit = 0 > >>> > >>> What do you think ? > >>> Simo. > >>> > >> > >> Sure, this could work (though it is quite lengthy). > > > > I think it would be sufficient to only perform the addition of udp_preference_limit if it does not already exist and if the version number of the package we are upgrading from is less than the one where we introduced the change. > > > > Nathaniel > > > > Or to simply call python and get the value of our state store keeping track > what was done on upgrades. This would work: > > # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 > if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" > # echo $? > 0 > > # python2 -c "from ipaserver.install import sysupgrade; > sysupgrade.set_upgrade_state('krb5.conf', 'udp_preference_limit_set', True)" > > # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 > if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" > # echo $? > 1 > > You would just need to come up with something that's present on the client, > this is just on the server sub package. What about the attached approach? It is untested, but I can test it if we like this method. Basically, create an include directory that we ship defaults in. Admins can update /etc/krb5.conf to override the defaults. If we need to change the default, we just change the file we ship. We can enable this on upgrades by ensuring that the appropriate includedir statement appears at the top of the file. The nice thing about this approach is that is preserves admin modifications (unless they removed the configuration directive rather than changing it). Thoughts? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Prefer-TCP-connections-to-UDP-in-krb5-clients.patch Type: text/x-patch Size: 3362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Migrate-Kerberos-client-defaults-to-an-include-direc.patch Type: text/x-patch Size: 2866 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 13 19:20:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 13 Nov 2014 14:20:14 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1415905341.26688.5.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> <1415905341.26688.5.camel@redhat.com> Message-ID: <1415906414.26688.9.camel@redhat.com> On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote: > On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek wrote: > > >> > > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > > >>> Martin Kosek wrote: > > >>> > > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > > >>>>> Martin Kosek wrote: > > >>>>> > > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > > >>>>>>> Martin Kosek wrote: > > >>>>>>> > > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > > >>>>>>>>> Nathaniel McCallum wrote: > > >>>>>>>>> > > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> ----- Original Message ----- > > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > >>>>>>>>>>>>> Patch attached. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > > >>>>>>>>>>>> second timeouts and re-transmits when OTP is in place? > > >>>>>>>>>>>> > > >>>>>>>>>>>> What is the expected performance impact? Could it be > > >>>>>>>>>>>> configured for OTP separately - somehow? (I guess that it is > > >>>>>>>>>>>> not possible now ...) > > >>>>>>>>>>> > > >>>>>>>>>>> It benefits also communication of large packets (when large > > >>>>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better > > >>>>>>>>>>> choice for IPA in general. Especially given we have multiple > > >>>>>>>>>>> KDC processes configured we do not want clients wasting KDC > > >>>>>>>>>>> resources by making multiple processes do the same operation. > > >>>>>>>>>> > > >>>>>>>>>> So apparently this patch never got reviewed over a year ago. > > >>>>>>>>>> > > >>>>>>>>>> It was related to a bug which was opened in SSSD. However, when > > >>>>>>>>>> it became clear we wanted to solve this in FreeIPA, the SSSD > > >>>>>>>>>> bug was closed but no corresponding FreeIPA bug was opened. The > > >>>>>>>>>> patch then fell through the cracks. > > >>>>>>>> > > >>>>>>>> Right - without an associated ticket tracking the patch, it is > > >>>>>>>> too easy to loose it unless the author prods people to review it. > > >>>>>>>> > > >>>>>>>>>> Without this patch, if OTP validation runs long we get > > >>>>>>>>>> retransmits and failures. > > >>>>>>>>>> > > >>>>>>>>>> One question I have is how to handle this for upgrades since (I > > >>>>>>>>>> think) this patch only handles new installs. > > >>>>>>>>>> > > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is > > >>>>>>>>>> appreciated. > > >>>>>>>>>> > > >>>>>>>>>> I have attached a rebased version which has no other changes. > > >>>>>>>>>> > > >>>>>>>>>> Nathaniel > > >>>>>>>>> > > >>>>>>>>> I am not sure we can do much on updates, we do not have a > > >>>>>>>>> client-update tool, I would just document it I guess. > > >>>>>>>>> Otherwise we'd have to go back to sssd which can inject > > >>>>>>>>> additional values in krb5.conf, however I am not sure it would > > >>>>>>>>> be ok to set something like this in the sssd's pubconf > > >>>>>>>>> includes ... > > >>>>>>>> > > >>>>>>>> Agreed, pubconf update does not sound right. > > >>>>>>>> > > >>>>>>>> However, we already update krb5.conf on client updates, in %post: > > >>>>>>>> > > >>>>>>>> %post client > > >>>>>>>> if [ $1 -gt 1 ] ; then > > >>>>>>>> # Has the client been configured? > > >>>>>>>> restore=0 > > >>>>>>>> test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' > > >>>>>>>> && restore=$(wc -l > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print > > >>>>>>>> $1}') > > >>>>>>>> > > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > > >>>>>>>> if ! grep -E -q > > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > > >>>>>>>> 2>/dev/null ; then > > >>>>>>>> echo > > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > > >>>>>>>>>>> /etc/krb5.conf.ipanew > > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > > >>>>>>>> /sbin/restorecon /etc/krb5.conf > > >>>>>>>> fi > > >>>>>>>> fi > > >>>>>>>> ... > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This particular update is more difficult as not a first line > > >>>>>>>> needs to be changed. Without adding ipa client update tool with > > >>>>>>>> some reasonable krb5.conf parser, we could do something along > > >>>>>>>> the lines of > > >>>>>>>> > > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit = > > >>>>>>>> 0/g' /etc/krb5.conf > > >>>>>>>> > > >>>>>>>> (tested), but it is not pretty. > > >>>>>>> > > >>>>>>> What happen the next time you run it again ? > > >>>>>>> > > >>>>>>> Simo. > > >>>>>>> > > >>>>>> > > >>>>>> It would of course be added again, you would need to first grep for > > >>>>>> presence of udp_preference_limit setting. Question is if this > > >>>>>> approach is safe enough to be in our client %post upgrade. We > > >>>>>> already upgrade krb5.conf here, just the change is much easier as > > >>>>>> we just add a line to the beginning of the file. > > >>>>> > > >>>>> Well the concern (aside of duplication) is that an admin may > > >>>>> "correct" the krb5.conf file to remove that option (for example > > >>>>> because his clients also connect to a differen (older) KDC and must > > >>>>> use UDP in preference. But now we end up messing with its krb5.conf > > >>>>> every time an update is released. An update tool that keep tracks > > >>>>> of whether a specific update has already been applied and does not > > >>>>> retry every time would be needed IMO. > > >>>>> > > >>>>> Simo. > > >>>> > > >>>> In 4.1.x (as there is not much time to develop a separate client > > >>>> update tool), we could grep just for "udp_preference_limit" presence > > >>>> so that if admin changes it's value or comment it, it would not be > > >>>> added again. > > >>> > > >>> Ok then maybe we add this: > > >>> > > >>> # The following value has been added by a freeipa client update > > >>> # if you want to disable it, please comment it, do not delete it > > >>> # or it will be re-added on the next update > > >>> udp_preference_limit = 0 > > >>> > > >>> What do you think ? > > >>> Simo. > > >>> > > >> > > >> Sure, this could work (though it is quite lengthy). > > > > > > I think it would be sufficient to only perform the addition of udp_preference_limit if it does not already exist and if the version number of the package we are upgrading from is less than the one where we introduced the change. > > > > > > Nathaniel > > > > > > > Or to simply call python and get the value of our state store keeping track > > what was done on upgrades. This would work: > > > > # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 > > if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" > > # echo $? > > 0 > > > > # python2 -c "from ipaserver.install import sysupgrade; > > sysupgrade.set_upgrade_state('krb5.conf', 'udp_preference_limit_set', True)" > > > > # python2 -c "from ipaserver.install import sysupgrade; import sys; sys.exit(1 > > if sysupgrade.get_upgrade_state('krb5.conf', 'udp_preference_limit_set') else 0)" > > # echo $? > > 1 > > > > You would just need to come up with something that's present on the client, > > this is just on the server sub package. > > What about the attached approach? It is untested, but I can test it if > we like this method. > > Basically, create an include directory that we ship defaults in. Admins > can update /etc/krb5.conf to override the defaults. If we need to change > the default, we just change the file we ship. > > We can enable this on upgrades by ensuring that the appropriate > includedir statement appears at the top of the file. The nice thing > about this approach is that is preserves admin modifications (unless > they removed the configuration directive rather than changing it). > > Thoughts? Simo has just informed me that we will be getting /etc/krb5.conf.d at some point in the near future. So I think for now I'd like to have the original patch[1] reviewed (not the includedir experiment patch). We then document the TCP issue for upgrades. Then, in the future, when we get /etc/krb5.conf.d, we can just stick the default in there. Is everyone cool with this? Nathaniel [1] - https://www.redhat.com/archives/freeipa-devel/2014-November/msg00098.html From ssorce at redhat.com Thu Nov 13 19:40:28 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 13 Nov 2014 14:40:28 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1415906414.26688.9.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <20141106194611.1c91f5eb@willson.usersys.redhat.com> <545C6E6A.5070101@redhat.com> <20141107082006.1d2543c5@willson.usersys.redhat.com> <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> <1415905341.26688.5.camel@redhat.com> <1415906414.26688.9.camel@redhat.com> Message-ID: <20141113144028.734cf2bf@willson.usersys.redhat.com> On Thu, 13 Nov 2014 14:20:14 -0500 Nathaniel McCallum wrote: > On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote: > > On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > > > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > > > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek > > > >> wrote: > > > >> > > > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > > > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > > > >>> Martin Kosek wrote: > > > >>> > > > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > > > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > > > >>>>> Martin Kosek wrote: > > > >>>>> > > > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > > > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > > > >>>>>>> Martin Kosek wrote: > > > >>>>>>> > > > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > > > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > > > >>>>>>>>> Nathaniel McCallum wrote: > > > >>>>>>>>> > > > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > > >>>>>>>>>>> > > > >>>>>>>>>>> ----- Original Message ----- > > > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > >>>>>>>>>>>>> Patch attached. > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To > > > >>>>>>>>>>>> prevent 1 second timeouts and re-transmits when OTP > > > >>>>>>>>>>>> is in place? > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> What is the expected performance impact? Could it be > > > >>>>>>>>>>>> configured for OTP separately - somehow? (I guess > > > >>>>>>>>>>>> that it is not possible now ...) > > > >>>>>>>>>>> > > > >>>>>>>>>>> It benefits also communication of large packets (when > > > >>>>>>>>>>> large MS-PAC or CAMMAC AD Data are attached), so it > > > >>>>>>>>>>> is a better choice for IPA in general. Especially > > > >>>>>>>>>>> given we have multiple KDC processes configured we do > > > >>>>>>>>>>> not want clients wasting KDC resources by making > > > >>>>>>>>>>> multiple processes do the same operation. > > > >>>>>>>>>> > > > >>>>>>>>>> So apparently this patch never got reviewed over a > > > >>>>>>>>>> year ago. > > > >>>>>>>>>> > > > >>>>>>>>>> It was related to a bug which was opened in SSSD. > > > >>>>>>>>>> However, when it became clear we wanted to solve this > > > >>>>>>>>>> in FreeIPA, the SSSD bug was closed but no > > > >>>>>>>>>> corresponding FreeIPA bug was opened. The patch then > > > >>>>>>>>>> fell through the cracks. > > > >>>>>>>> > > > >>>>>>>> Right - without an associated ticket tracking the patch, > > > >>>>>>>> it is too easy to loose it unless the author prods > > > >>>>>>>> people to review it. > > > >>>>>>>> > > > >>>>>>>>>> Without this patch, if OTP validation runs long we get > > > >>>>>>>>>> retransmits and failures. > > > >>>>>>>>>> > > > >>>>>>>>>> One question I have is how to handle this for upgrades > > > >>>>>>>>>> since (I think) this patch only handles new installs. > > > >>>>>>>>>> > > > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is > > > >>>>>>>>>> appreciated. > > > >>>>>>>>>> > > > >>>>>>>>>> I have attached a rebased version which has no other > > > >>>>>>>>>> changes. > > > >>>>>>>>>> > > > >>>>>>>>>> Nathaniel > > > >>>>>>>>> > > > >>>>>>>>> I am not sure we can do much on updates, we do not have > > > >>>>>>>>> a client-update tool, I would just document it I guess. > > > >>>>>>>>> Otherwise we'd have to go back to sssd which can inject > > > >>>>>>>>> additional values in krb5.conf, however I am not sure > > > >>>>>>>>> it would be ok to set something like this in the sssd's > > > >>>>>>>>> pubconf includes ... > > > >>>>>>>> > > > >>>>>>>> Agreed, pubconf update does not sound right. > > > >>>>>>>> > > > >>>>>>>> However, we already update krb5.conf on client updates, > > > >>>>>>>> in %post: > > > >>>>>>>> > > > >>>>>>>> %post client > > > >>>>>>>> if [ $1 -gt 1 ] ; then > > > >>>>>>>> # Has the client been configured? > > > >>>>>>>> restore=0 > > > >>>>>>>> test -f > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' && > > > >>>>>>>> restore=$(wc -l > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk > > > >>>>>>>> '{print $1}') > > > >>>>>>>> > > > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 > > > >>>>>>>> ]; then if ! grep -E -q > > > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > > > >>>>>>>> 2>/dev/null ; then > > > >>>>>>>> echo > > > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > > > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > > > >>>>>>>>>>> /etc/krb5.conf.ipanew > > > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > > > >>>>>>>> /sbin/restorecon /etc/krb5.conf > > > >>>>>>>> fi > > > >>>>>>>> fi > > > >>>>>>>> ... > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> This particular update is more difficult as not a first > > > >>>>>>>> line needs to be changed. Without adding ipa client > > > >>>>>>>> update tool with some reasonable krb5.conf parser, we > > > >>>>>>>> could do something along the lines of > > > >>>>>>>> > > > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n > > > >>>>>>>> udp_preference_limit = 0/g' /etc/krb5.conf > > > >>>>>>>> > > > >>>>>>>> (tested), but it is not pretty. > > > >>>>>>> > > > >>>>>>> What happen the next time you run it again ? > > > >>>>>>> > > > >>>>>>> Simo. > > > >>>>>>> > > > >>>>>> > > > >>>>>> It would of course be added again, you would need to first > > > >>>>>> grep for presence of udp_preference_limit setting. > > > >>>>>> Question is if this approach is safe enough to be in our > > > >>>>>> client %post upgrade. We already upgrade krb5.conf here, > > > >>>>>> just the change is much easier as we just add a line to > > > >>>>>> the beginning of the file. > > > >>>>> > > > >>>>> Well the concern (aside of duplication) is that an admin > > > >>>>> may "correct" the krb5.conf file to remove that option (for > > > >>>>> example because his clients also connect to a differen > > > >>>>> (older) KDC and must use UDP in preference. But now we end > > > >>>>> up messing with its krb5.conf every time an update is > > > >>>>> released. An update tool that keep tracks of whether a > > > >>>>> specific update has already been applied and does not retry > > > >>>>> every time would be needed IMO. > > > >>>>> > > > >>>>> Simo. > > > >>>> > > > >>>> In 4.1.x (as there is not much time to develop a separate > > > >>>> client update tool), we could grep just for > > > >>>> "udp_preference_limit" presence so that if admin changes > > > >>>> it's value or comment it, it would not be added again. > > > >>> > > > >>> Ok then maybe we add this: > > > >>> > > > >>> # The following value has been added by a freeipa client > > > >>> update # if you want to disable it, please comment it, do not > > > >>> delete it # or it will be re-added on the next update > > > >>> udp_preference_limit = 0 > > > >>> > > > >>> What do you think ? > > > >>> Simo. > > > >>> > > > >> > > > >> Sure, this could work (though it is quite lengthy). > > > > > > > > I think it would be sufficient to only perform the addition of > > > > udp_preference_limit if it does not already exist and if the > > > > version number of the package we are upgrading from is less > > > > than the one where we introduced the change. > > > > > > > > Nathaniel > > > > > > > > > > Or to simply call python and get the value of our state store > > > keeping track what was done on upgrades. This would work: > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > 'udp_preference_limit_set') else 0)" # echo $? > > > 0 > > > > > > # python2 -c "from ipaserver.install import sysupgrade; > > > sysupgrade.set_upgrade_state('krb5.conf', > > > 'udp_preference_limit_set', True)" > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > 'udp_preference_limit_set') else 0)" # echo $? > > > 1 > > > > > > You would just need to come up with something that's present on > > > the client, this is just on the server sub package. > > > > What about the attached approach? It is untested, but I can test it > > if we like this method. > > > > Basically, create an include directory that we ship defaults in. > > Admins can update /etc/krb5.conf to override the defaults. If we > > need to change the default, we just change the file we ship. > > > > We can enable this on upgrades by ensuring that the appropriate > > includedir statement appears at the top of the file. The nice thing > > about this approach is that is preserves admin modifications (unless > > they removed the configuration directive rather than changing it). > > > > Thoughts? > > Simo has just informed me that we will be getting /etc/krb5.conf.d at > some point in the near future. So I think for now I'd like to have the > original patch[1] reviewed (not the includedir experiment patch). We > then document the TCP issue for upgrades. Then, in the future, when we > get /etc/krb5.conf.d, we can just stick the default in there. > > Is everyone cool with this? +1 > Nathaniel > > [1] - > https://www.redhat.com/archives/freeipa-devel/2014-November/msg00098.html > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Nov 14 01:22:55 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Nov 2014 20:22:55 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <54622B6F.3080101@redhat.com> References: <54622B6F.3080101@redhat.com> Message-ID: <20141113202255.373aa1ca@willson.usersys.redhat.com> On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek wrote: > Hello, > > this thread is about RFE > "IPA servers when installed should register themselves in the > external DNS" https://fedorahosted.org/freeipa/ticket/4424 > > It is not a complete design, just a raw idea. > > > Use case > ======== > FreeIPA installation to a network with existing DNS infrastructure + > network administrator who is not willing to add/maintain new DNS > servers "just for FreeIPA". > > > High-level idea > =============== > - Transform dns* commands from FreeIPA framework to equivalent > "nsupdate" commands and send DNS updates to existing DNS servers. > - Provide necessary encryption/signing keys to nsupdate. > > > 1) Integration to FreeIPA framework > =================================== > First of all, we need to decide if "external DNS integration" can be > used at the same time with FreeIPA-integrated DNS or not. > Side-question is what to do if a first server is installed with > external-DNS but another replica is being installed with > integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. > In other words, the question is if current "dns.py" plugin shipped > with FreeIPA framework should be: > > a) Extended dns.py with dnsexternal-* commands > ---------------------------------------------- > Disadvantages: > - It complicate FreeIPA DNS interface which is a complex beast even > now. > - We would have add condition to every DNS API call in installers > which would increase horribleness of the installer code even more (or > add another layer of abstraction...). I agree having a special command is undesirable. > - I don't see a point in using integrated-DNS with external-DNS at > the same time. To use integrated-DNS you have to get a proper DNS > delegation from parent domain - and if you can get the delegation > then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. > Advantages: > - You can use external & integrated DNS at the same time. We can achieve the same w/o a new ipa level command. > b) Replace dns.py with another implementation of current dnszone-* & > dnsrecord-* API. > --------------------------------------------------------------------- > This seems like a cleaner approach to me. It could be shipped as > ipa-server-dns-external package (opposed to "standard" ipa-server-dns > package). > > Advantages: > - It could seamlessly work with FreeIPA client installer because the > dns*->nsupdate command transformation would be done on FreeIPA server > and client doesn't need to know about it. > - Does not require re-training/not much new documentation because > commands are the same. > > Disadvantages: > - You can't use integrated & external DNS at the same time (but I > don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. > Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the framework detects that the zone is "external", fewttches the TSIG key (if the user has access to it) and spawn an nsupdate command that will perform the update against whatever DNS server is authoritative for the zone. Some commands may be disabled if the zone is external and appropriate errors would be returned. > 2) Authentication to external DNS server/keys > ============================================= > This is separate problem from FreeIPA framework integration. > We will have to somehow store raw symmetric keys (for DNS TSIG) or > keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so > every replica can update DNS records as necessary. For TSIG keys I think we should just store them in a LDAP record, see above. For keytabs we can simply store them just like any other kerberos key if we really need it (in a trust case for example, we may not need a new keytab, we may be allowed to use our own credentials through the trust. So we'll need to explore a bit how to properly express that in configuration. REtrieval ok keytabs is then just a matter of running ipa-getkeytab -r on the replica that needs it. > This will be the funny part because in case of AD trusts we have > chicken-egg problem. You need to establish trust to get ticket for > DNS/dc1.ad.example at AD principal but you can't (I guess) establish > trust until proper DNS records are in place ... No, in this case we should create the records at trust establishment time using the admin credentials we have been provided. NO chicken-egg issue. > For 'experimental' phase I would go with pre-populated CCcache, i.e. > admin will manually do kinit Administrator at AD and then run FreeIPA > installer. We already to this, so there is no need to invent anything here IMO. > Maybe we can re-use trust secret somehow? I don't know, I will reach > out to AD experts with questions. > > This area needs more research but for now it seems feasible to re-use > DNSSEC key distribution system for TSIG keys and keytabs so "only" > the chicken-egg problem is left. > > This will need new LDAP schema but I will propose something when I'm > done with investigation. Please let me know if you agree with a new zone type as a way to "forward" updates. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Nov 14 08:55:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Nov 2014 09:55:45 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <54510D29.1020804@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> Message-ID: <5465C391.7030003@redhat.com> On 10/29/2014 04:52 PM, Petr Viktorin wrote: > On 10/29/2014 01:22 PM, Tomas Babej wrote: >> >> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>> This almost completes the switch to pytest. There are two missing >>>> things: >>>> - the details of test results (--with-xunit) are not read correctly by >>>> Jenkins. I have a theory I'm investigating here. >>>> - the beakerlib integration is still not ready >>>> >>>> >>>> I'll not be available for the rest of the week so I'm sending this >>>> early, in case someone wants to take a look. >>> >>> I've updated (and rearranged) the patches after some more testing. >>> Both points above are fixed. Individual plugins are broken out; some >>> would be nice to even release independently of IPA. (There is some >>> demand for the BeakerLib plugin; for that I'd only need to break the >>> dependency on ipa_log_manager.) >>> >>> >>> These depend on my patches 0656-0660. >>> > >> Thanks for this effort! >> >> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names >> >> There are some references to the old names in the test_ipapython and >> test_install: >> >> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >> [tbabej at thinkpad7 ipatests]$ git grep setUp >> test_install/test_updates.py: def setUp(self): >> test_ipapython/test_cookie.py: def setUp(self): >> test_ipapython/test_cookie.py: def setUp(self): >> test_ipapython/test_cookie.py: def setUp(self): >> test_ipapython/test_dn.py: def setUp(self): >> test_ipapython/test_dn.py: def setUp(self): >> test_ipapython/test_dn.py: def setUp(self): >> test_ipapython/test_dn.py: def setUp(self): >> test_ipapython/test_dn.py: def setUp(self): >> [tbabej at thinkpad7 ipatests]$ git grep tearDown >> test_install/test_updates.py: def tearDown(self): > > These are in unittest.testCase. It would be nice to convert those as > well, but that's for a larger cleanup. > >> #### Patch 0657: tests: Add configuration for pytest >> >> Shouldn't we rather change the class names? > > Ideally yes, but I don't think renaming most of our test classes would > be worth the benefit. > >> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >> get_subcls >> >> ACK. >> >> #### Patch 0659: test_automount_plugin: Fix test ordering >> >> ACK. >> >> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >> >> --- a/ipatests/test_ipaserver/test_changepw.py >> +++ b/ipatests/test_ipaserver/test_changepw.py >> @@ -33,8 +33,7 @@ >> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >> app_uri = '/ipa/session/change_password' >> >> - def setup(self): >> - super(test_changepw, self).setup() >> + def setup(cls): >> try: >> api.Command['user_add'](uid=testuser, >> givenname=u'Test', sn=u'User') >> api.Command['passwd'](testuser, >> password=u'old_password') >> @@ -43,12 +42,11 @@ def setup(self): >> 'Cannot set up test user: %s' % e >> ) >> >> - def teardown(self): >> + def teardown(cls): >> try: >> api.Command['user_del']([testuser]) >> except errors.NotFound: >> pass >> - super(test_changepw, self).teardown() >> >> The setup/teardown methods are not classmethods, so the name of the >> first argument should remain "self". > > Oops, thanks for the catch! > >> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for non-doctest >> examples >> >> ACK. >> >> #### PATCH 0662: test_webui: Don't use __init__ for test classes >> >> I don't think the following change will work: >> >> - def __init__(self, driver=None, config=None): >> + def setup(self, driver=None, config=None): >> self.request_timeout = 30 >> self.driver = driver >> self.config = config >> if not config: >> self.load_config() >> + self.get_driver().maximize_window() >> + >> + def teardown(self): >> + self.driver.quit() >> >> def load_config(self): >> """ >> @@ -161,20 +165,6 @@ def load_config(self): >> if 'type' not in c: >> c['type'] = DEFAULT_TYPE >> >> - def setup(self): >> - """ >> - Test setup >> - """ >> - if not self.driver: >> - self.driver = self.get_driver() >> - self.driver.maximize_window() >> - >> - def teardown(self): >> - """ >> - Test clean up >> - """ >> - self.driver.quit() >> >> >> The setup(self) method used to set the self.driver attribute on the >> class instance, now nothing sets it. The setup method should do: >> >> def setup(self, driver=None, config=None): >> self.request_timeout = 30 >> self.driver = driver >> self.config = config >> if not config: >> self.load_config() >> if not self.driver: >> self.driver = self.get_driver() >> self.driver.maximize_window() >> >> However, I would prefer having self.driver as a cached property. > > Well, ideally these would be fixtures. > > Thanks for the catch. > >> #### PATCH 0663: test_ipapython: Use functions instead of classes in >> test generators >> >> ACK. >> >> #### PATCH 0664: Configure pytest to run doctests >> >> ACK. >> >> #### PATCH 0665: Declarative tests: Move cleanup to >> setup_class/teardown_class >> >> You should also remove the now redundant cleanup_generate method. > > Right, removed. > >> Also: Do we really want to print out error.NotFound or >> errors.EmptyModList exceptions produced by cleanup commands? > > It's just one line, might help debugging. It should only show up on > failures. > >> #### PATCH 0666: Declarative tests: Switch to pytest >> >> Nitpitck: declarative.py has wrong year in the copyright header. >> Otherwise ACK. > > Fixed. > >> #### PATCH 0667: Integration tests: Port the ordering plugin to pytest >> >> Specfile change belongs to the previous patch, but I doubt these would >> be separated, so not worth spending the time IMHO. > > Also, the previous patch doesn't actually import pytest. But a lot of > these patches break tests by themselves, so they shouldn't be separated. > >> Why does TestIPACommands have ordered decorator applied? It is applied >> on IntegrationTest directly, from which CALessBase inherits from. I >> don't think it's necessary (unless I'm missing something), so we should >> rather remove the occurence of the decorator in the test_caless.py than >> fixing the import. > > Actually, I think only only the classes that actually need it should > have the decorator. > Again, cleanup for a future time. > >> #### PATCH 0668: Switch make-test to pytest >> >> Nice simplification. However, make-test does not work for me: >> >> I'm getting tons of errors (during the collection) along the lines of: >> >> ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py >> _________________ >> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport >> raise self.ImportMismatchError(modname, modfile, self) >> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >> _______________ ERROR collecting >> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport >> raise self.ImportMismatchError(modname, modfile, self) >> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >> _______________ ERROR collecting >> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >> import file mismatch: >> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >> __file__ attribute: >> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >> which is not the same as the test file we want to collect: >> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >> HINT: remove __pycache__ / .pyc files and/or use a unique basename >> for your test file modules >> ================ 163 passed, 7 skipped, 679 error in 48.14 seconds >> ============== >> >> >> I am running this as ./make-test from the directory containing the >> freeipa sources. The ipa-run-tests command seems to work fine though. > > Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? > I've added . to PYTHONPATH, that may help (and it should also help with > plugin loading in some cases). > >> #### PATCH 0669: Add local pytest plugin for --with-xunit and >> --logging-level >> >> ACK. >> >> #### PATCH 0670: Switch ipa-run-tests to pytest >> >> ACK. >> >> #### PATCH 0671: Switch integration testing config to a fixture >> >> ACK. >> >> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >> collection to pytest >> >> I didn't see any glitches, but I haven't tested this one out yet >> functionally. >> >> ### General notes >> >> I did two IPA master installs today, one with your patches applied. >> There were significant differences in the number of successfully passing >> tests: >> >> nose: FAILED (SKIP=60, errors=46, failures=14) >> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >> 860.47 seconds ========= >> >> Did you not encounter this in your testing? I will look more deeply into >> the failures themselves. > > I did, but it was always some stupid mistake :) > Do you have ~/.ipa set up, and $MASTER undefined? > > The integration test did fail for me now when they were not configured. > I added an additional patch to fix that. Ping, could you look at the updated patches? -- Petr? From jhrozek at redhat.com Fri Nov 14 09:32:23 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 14 Nov 2014 10:32:23 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141113144028.734cf2bf@willson.usersys.redhat.com> References: <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> <1415905341.26688.5.camel@redhat.com> <1415906414.26688.9.camel@redhat.com> <20141113144028.734cf2bf@willson.usersys.redhat.com> Message-ID: <20141114093223.GE9338@hendrix.brq.redhat.com> On Thu, Nov 13, 2014 at 02:40:28PM -0500, Simo Sorce wrote: > On Thu, 13 Nov 2014 14:20:14 -0500 > Nathaniel McCallum wrote: > > > On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote: > > > On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > > > > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > > > > > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek > > > > >> wrote: > > > > >> > > > > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > > > > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > > > > >>> Martin Kosek wrote: > > > > >>> > > > > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > > > > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > > > > >>>>> Martin Kosek wrote: > > > > >>>>> > > > > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > > > > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > > > > >>>>>>> Martin Kosek wrote: > > > > >>>>>>> > > > > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > > > > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > > > > >>>>>>>>> Nathaniel McCallum wrote: > > > > >>>>>>>>> > > > > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> ----- Original Message ----- > > > > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > >>>>>>>>>>>>> Patch attached. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To > > > > >>>>>>>>>>>> prevent 1 second timeouts and re-transmits when OTP > > > > >>>>>>>>>>>> is in place? > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> What is the expected performance impact? Could it be > > > > >>>>>>>>>>>> configured for OTP separately - somehow? (I guess > > > > >>>>>>>>>>>> that it is not possible now ...) > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> It benefits also communication of large packets (when > > > > >>>>>>>>>>> large MS-PAC or CAMMAC AD Data are attached), so it > > > > >>>>>>>>>>> is a better choice for IPA in general. Especially > > > > >>>>>>>>>>> given we have multiple KDC processes configured we do > > > > >>>>>>>>>>> not want clients wasting KDC resources by making > > > > >>>>>>>>>>> multiple processes do the same operation. > > > > >>>>>>>>>> > > > > >>>>>>>>>> So apparently this patch never got reviewed over a > > > > >>>>>>>>>> year ago. > > > > >>>>>>>>>> > > > > >>>>>>>>>> It was related to a bug which was opened in SSSD. > > > > >>>>>>>>>> However, when it became clear we wanted to solve this > > > > >>>>>>>>>> in FreeIPA, the SSSD bug was closed but no > > > > >>>>>>>>>> corresponding FreeIPA bug was opened. The patch then > > > > >>>>>>>>>> fell through the cracks. > > > > >>>>>>>> > > > > >>>>>>>> Right - without an associated ticket tracking the patch, > > > > >>>>>>>> it is too easy to loose it unless the author prods > > > > >>>>>>>> people to review it. > > > > >>>>>>>> > > > > >>>>>>>>>> Without this patch, if OTP validation runs long we get > > > > >>>>>>>>>> retransmits and failures. > > > > >>>>>>>>>> > > > > >>>>>>>>>> One question I have is how to handle this for upgrades > > > > >>>>>>>>>> since (I think) this patch only handles new installs. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is > > > > >>>>>>>>>> appreciated. > > > > >>>>>>>>>> > > > > >>>>>>>>>> I have attached a rebased version which has no other > > > > >>>>>>>>>> changes. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Nathaniel > > > > >>>>>>>>> > > > > >>>>>>>>> I am not sure we can do much on updates, we do not have > > > > >>>>>>>>> a client-update tool, I would just document it I guess. > > > > >>>>>>>>> Otherwise we'd have to go back to sssd which can inject > > > > >>>>>>>>> additional values in krb5.conf, however I am not sure > > > > >>>>>>>>> it would be ok to set something like this in the sssd's > > > > >>>>>>>>> pubconf includes ... > > > > >>>>>>>> > > > > >>>>>>>> Agreed, pubconf update does not sound right. > > > > >>>>>>>> > > > > >>>>>>>> However, we already update krb5.conf on client updates, > > > > >>>>>>>> in %post: > > > > >>>>>>>> > > > > >>>>>>>> %post client > > > > >>>>>>>> if [ $1 -gt 1 ] ; then > > > > >>>>>>>> # Has the client been configured? > > > > >>>>>>>> restore=0 > > > > >>>>>>>> test -f > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' && > > > > >>>>>>>> restore=$(wc -l > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk > > > > >>>>>>>> '{print $1}') > > > > >>>>>>>> > > > > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 > > > > >>>>>>>> ]; then if ! grep -E -q > > > > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > > > > >>>>>>>> 2>/dev/null ; then > > > > >>>>>>>> echo > > > > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > > > > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > > > > >>>>>>>>>>> /etc/krb5.conf.ipanew > > > > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > > > > >>>>>>>> /sbin/restorecon /etc/krb5.conf > > > > >>>>>>>> fi > > > > >>>>>>>> fi > > > > >>>>>>>> ... > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> This particular update is more difficult as not a first > > > > >>>>>>>> line needs to be changed. Without adding ipa client > > > > >>>>>>>> update tool with some reasonable krb5.conf parser, we > > > > >>>>>>>> could do something along the lines of > > > > >>>>>>>> > > > > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n > > > > >>>>>>>> udp_preference_limit = 0/g' /etc/krb5.conf > > > > >>>>>>>> > > > > >>>>>>>> (tested), but it is not pretty. > > > > >>>>>>> > > > > >>>>>>> What happen the next time you run it again ? > > > > >>>>>>> > > > > >>>>>>> Simo. > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> It would of course be added again, you would need to first > > > > >>>>>> grep for presence of udp_preference_limit setting. > > > > >>>>>> Question is if this approach is safe enough to be in our > > > > >>>>>> client %post upgrade. We already upgrade krb5.conf here, > > > > >>>>>> just the change is much easier as we just add a line to > > > > >>>>>> the beginning of the file. > > > > >>>>> > > > > >>>>> Well the concern (aside of duplication) is that an admin > > > > >>>>> may "correct" the krb5.conf file to remove that option (for > > > > >>>>> example because his clients also connect to a differen > > > > >>>>> (older) KDC and must use UDP in preference. But now we end > > > > >>>>> up messing with its krb5.conf every time an update is > > > > >>>>> released. An update tool that keep tracks of whether a > > > > >>>>> specific update has already been applied and does not retry > > > > >>>>> every time would be needed IMO. > > > > >>>>> > > > > >>>>> Simo. > > > > >>>> > > > > >>>> In 4.1.x (as there is not much time to develop a separate > > > > >>>> client update tool), we could grep just for > > > > >>>> "udp_preference_limit" presence so that if admin changes > > > > >>>> it's value or comment it, it would not be added again. > > > > >>> > > > > >>> Ok then maybe we add this: > > > > >>> > > > > >>> # The following value has been added by a freeipa client > > > > >>> update # if you want to disable it, please comment it, do not > > > > >>> delete it # or it will be re-added on the next update > > > > >>> udp_preference_limit = 0 > > > > >>> > > > > >>> What do you think ? > > > > >>> Simo. > > > > >>> > > > > >> > > > > >> Sure, this could work (though it is quite lengthy). > > > > > > > > > > I think it would be sufficient to only perform the addition of > > > > > udp_preference_limit if it does not already exist and if the > > > > > version number of the package we are upgrading from is less > > > > > than the one where we introduced the change. > > > > > > > > > > Nathaniel > > > > > > > > > > > > > Or to simply call python and get the value of our state store > > > > keeping track what was done on upgrades. This would work: > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > 0 > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; > > > > sysupgrade.set_upgrade_state('krb5.conf', > > > > 'udp_preference_limit_set', True)" > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > 1 > > > > > > > > You would just need to come up with something that's present on > > > > the client, this is just on the server sub package. > > > > > > What about the attached approach? It is untested, but I can test it > > > if we like this method. > > > > > > Basically, create an include directory that we ship defaults in. > > > Admins can update /etc/krb5.conf to override the defaults. If we > > > need to change the default, we just change the file we ship. > > > > > > We can enable this on upgrades by ensuring that the appropriate > > > includedir statement appears at the top of the file. The nice thing > > > about this approach is that is preserves admin modifications (unless > > > they removed the configuration directive rather than changing it). > > > > > > Thoughts? > > > > Simo has just informed me that we will be getting /etc/krb5.conf.d at > > some point in the near future. So I think for now I'd like to have the > > original patch[1] reviewed (not the includedir experiment patch). We > > then document the TCP issue for upgrades. Then, in the future, when we > > get /etc/krb5.conf.d, we can just stick the default in there. > > > > Is everyone cool with this? > > +1 If there's an easy way to set this option in SSSD, I'm fine with setting the same default in SSSD as well. Sorry we dropped the ball on this item from the SSSD side, I think it's just b/c there was no ticket filed ... From pvoborni at redhat.com Fri Nov 14 12:18:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Nov 2014 13:18:59 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5464F474.3040807@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> Message-ID: <5465F333.3070008@redhat.com> On 13.11.2014 19:12, Petr Viktorin wrote: > On 11/13/2014 06:02 PM, Nathaniel McCallum wrote: >> On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote: >>> On 11/13/2014 04:40 PM, Petr Vobornik wrote: >>>> On 13.11.2014 16:19, Nathaniel McCallum wrote: >>>>>>> >>>>>>> Like you, I like #2 the best. Attached is an implementation. >>>>>> >>>>>> I like --no-qrcode as well. >>>>>> >>>>>> Should we also keep qrcode as 'no_option' to maintain API >>>>>> compatibility >>>>>> (but not CLI)? >>>>> >>>>> I don't think it is necessary. It only makes sense to specify --qrcode >>>>> in an interactive session. >>>>> >>>> >>>> Makes sense. >>>> >>>> ACK >>>> >>>> Not pushing yet to give time for NACK if anybody doesn't agree with the >>>> API change. >>> >>> Hold on, what is happening here? >>> >>> Aren't all clients since 4.0 sending the qrcode option to the server? >>> We absolutely can not break backwards compatibility with released >>> versions. >>> We also should not break the CLI. Just make it a no-op option, and say >>> it's deprecated in the doc. >> >> As I understand the current behavior, the qrcode option is *not* sent to >> the server by default in any scenario. > > Nope, defaults are filled in by the client. (And also on the server if > they're still missing; it's part of the common validation.) IMHO this is quite unfortunate behavior which may also fail horribly if there is a newer client and an older server -> backwards compatibility is on API level, not CLI level. Defaults should be filled by server, not a client. We should seriously reconsider the design of our CLI. But that's for different, future discussion. That's said and given the circumstances, it is easier and cleaner to return the --qrcode back as no_param now than to deal with potential future issues. > > You can try it out, actually: > > $ ipa -vv otptoken-add > ipa: INFO: trying https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json > ipa: INFO: Forwarding 'otptoken_add' to json server > 'https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json' > ipa: INFO: Request: { > "id": 0, > "method": "otptoken_add", > "params": [ > [ > null > ], > { > "all": false, > "ipatokenhotpcounter": 0, > "ipatokenotpalgorithm": "sha1", > "ipatokenotpdigits": 6, > "ipatokenotpkey": > "5\ufffdK\ufffd1\u000e\ufffd7,\ufffd_\ufffd\ufffd.0\ufffdM\ufffd\u0016\ufffd", > > "ipatokentotpclockoffset": 0, > "ipatokentotptimestep": 30, > "no_members": false, > "qrcode": false, > "raw": false, > "type": "totp", > "version": "2.108" > } > ] > } > ipa: INFO: Response: { > "error": null, > "id": 0, > "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", > ... > -- Petr Vobornik From mbasti at redhat.com Fri Nov 14 12:38:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Nov 2014 13:38:27 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli In-Reply-To: <20141114123125.GS1849@tscherf.redhat.com> References: <20141111123711.GU1849@tscherf.redhat.com> <546207C5.1080603@redhat.com> <20141111144239.GZ1849@tscherf.redhat.com> <54623049.3010509@redhat.com> <20141114123125.GS1849@tscherf.redhat.com> Message-ID: <5465F7C3.10600@redhat.com> On 14/11/14 13:31, Thorsten Scherf wrote: > On [Tue, 11.11.2014 16:50], Martin Basti wrote: >> On 11/11/14 15:42, Thorsten Scherf wrote: >>> On [Tue, 11.11.2014 13:57], Martin Basti wrote: >>>> On 11/11/14 13:37, Thorsten Scherf wrote: >>>>> The ipa-server-install man page is more descriptive on how to >>>>> configure >>>>> multiple DNS forwarders than the cli help. The cli help is more >>>>> verbose >>>>> now. >>>>> >>>>> https://fedorahosted.org//ticket/4465 >>>>> >>>>> Cheers, >>>>> Thorsten >>>>> >>>>> >>>> Hello, >>>> >>>> thanks for patch, but I have a few objections. >>>> >>>> 1) Trac link in commit is corrupted >>>> 2) The forwarder option is in more installation scripts: >>>> * ipa-dns-install >>>> * ipa-replica-install >>>> * ipa-server-install >>> >>> Please find the new patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/4465 >>> >>> Cheers, >>> Thorsten >>> >>> >> Thank you, ACK. >> >> Please read how to format a patch for future. >> http://www.freeipa.org/page/Contribute/Patch_Format > > yeah, sorry, will do the next time. > > Can you push the patch to master? > > Cheers, > Thorsten > Yes it can, but I don't have rights to do that. >> >> -- >> Martin Basti >> -- Martin Basti From pviktori at redhat.com Fri Nov 14 13:08:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Nov 2014 14:08:24 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5465F333.3070008@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> Message-ID: <5465FEC8.4030602@redhat.com> On 11/14/2014 01:18 PM, Petr Vobornik wrote: [...] >> >> Nope, defaults are filled in by the client. (And also on the server if >> they're still missing; it's part of the common validation.) > > IMHO this is quite unfortunate behavior which may also fail horribly if > there is a newer client and an older server -> backwards compatibility > is on API level, not CLI level. Defaults should be filled by server, not > a client. We should seriously reconsider the design of our CLI. But > that's for different, future discussion. You can't use a newer client with an older server, you get a VersionError in that case. Feel free to file a ticket. But yes, redesigning the API is not exactly a priority. > That's said and given the circumstances, it is easier and cleaner to > return the --qrcode back as no_param now than to deal with potential > future issues. What's the reason to break the CLI by making it no_param? -- Petr? From pvoborni at redhat.com Fri Nov 14 13:25:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Nov 2014 14:25:08 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5465FEC8.4030602@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> Message-ID: <546602B4.3070609@redhat.com> On 14.11.2014 14:08, Petr Viktorin wrote: > On 11/14/2014 01:18 PM, Petr Vobornik wrote: > [...] >>> >>> Nope, defaults are filled in by the client. (And also on the server if >>> they're still missing; it's part of the common validation.) >> >> IMHO this is quite unfortunate behavior which may also fail horribly if >> there is a newer client and an older server -> backwards compatibility >> is on API level, not CLI level. Defaults should be filled by server, not >> a client. We should seriously reconsider the design of our CLI. But >> that's for different, future discussion. > > You can't use a newer client with an older server, you get a > VersionError in that case. And that's bad because, IMHO, this case may be more common that a newer server and an older client, e.g., RHEL 6.5 server and Fedora 21 client. > > Feel free to file a ticket. But yes, redesigning the API is not exactly > a priority. > >> That's said and given the circumstances, it is easier and cleaner to >> return the --qrcode back as no_param now than to deal with potential >> future issues. > > What's the reason to break the CLI by making it no_param? Sorry I meant, no_option, there is no no_param. Because it returns it back to Nathaniel's argument about interactive session and I agree with it. Why would we have both --no-qrcode and --qrcode options available on CLI? -- Petr Vobornik From ssorce at redhat.com Fri Nov 14 14:06:57 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 14 Nov 2014 09:06:57 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141114093223.GE9338@hendrix.brq.redhat.com> References: <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> <1415905341.26688.5.camel@redhat.com> <1415906414.26688.9.camel@redhat.com> <20141113144028.734cf2bf@willson.usersys.redhat.com> <20141114093223.GE9338@hendrix.brq.redhat.com> Message-ID: <20141114090657.7e65bfe3@willson.usersys.redhat.com> On Fri, 14 Nov 2014 10:32:23 +0100 Jakub Hrozek wrote: > On Thu, Nov 13, 2014 at 02:40:28PM -0500, Simo Sorce wrote: > > On Thu, 13 Nov 2014 14:20:14 -0500 > > Nathaniel McCallum wrote: > > > > > On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote: > > > > On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > > > > > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > > > > > > > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek > > > > > >> wrote: > > > > > >> > > > > > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > > > > > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > > > > > >>> Martin Kosek wrote: > > > > > >>> > > > > > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > > > > > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > > > > > >>>>> Martin Kosek wrote: > > > > > >>>>> > > > > > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > > > > > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > > > > > >>>>>>> Martin Kosek wrote: > > > > > >>>>>>> > > > > > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > > > > > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > > > > > >>>>>>>>> Nathaniel McCallum wrote: > > > > > >>>>>>>>> > > > > > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce > > > > > >>>>>>>>>> wrote: > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> ----- Original Message ----- > > > > > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > > >>>>>>>>>>>>> Patch attached. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? > > > > > >>>>>>>>>>>> To prevent 1 second timeouts and re-transmits > > > > > >>>>>>>>>>>> when OTP is in place? > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> What is the expected performance impact? Could > > > > > >>>>>>>>>>>> it be configured for OTP separately - somehow? > > > > > >>>>>>>>>>>> (I guess that it is not possible now ...) > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> It benefits also communication of large packets > > > > > >>>>>>>>>>> (when large MS-PAC or CAMMAC AD Data are > > > > > >>>>>>>>>>> attached), so it is a better choice for IPA in > > > > > >>>>>>>>>>> general. Especially given we have multiple KDC > > > > > >>>>>>>>>>> processes configured we do not want clients > > > > > >>>>>>>>>>> wasting KDC resources by making multiple > > > > > >>>>>>>>>>> processes do the same operation. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> So apparently this patch never got reviewed over a > > > > > >>>>>>>>>> year ago. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> It was related to a bug which was opened in SSSD. > > > > > >>>>>>>>>> However, when it became clear we wanted to solve > > > > > >>>>>>>>>> this in FreeIPA, the SSSD bug was closed but no > > > > > >>>>>>>>>> corresponding FreeIPA bug was opened. The patch > > > > > >>>>>>>>>> then fell through the cracks. > > > > > >>>>>>>> > > > > > >>>>>>>> Right - without an associated ticket tracking the > > > > > >>>>>>>> patch, it is too easy to loose it unless the author > > > > > >>>>>>>> prods people to review it. > > > > > >>>>>>>> > > > > > >>>>>>>>>> Without this patch, if OTP validation runs long we > > > > > >>>>>>>>>> get retransmits and failures. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> One question I have is how to handle this for > > > > > >>>>>>>>>> upgrades since (I think) this patch only handles > > > > > >>>>>>>>>> new installs. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help > > > > > >>>>>>>>>> is appreciated. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> I have attached a rebased version which has no > > > > > >>>>>>>>>> other changes. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Nathaniel > > > > > >>>>>>>>> > > > > > >>>>>>>>> I am not sure we can do much on updates, we do not > > > > > >>>>>>>>> have a client-update tool, I would just document it > > > > > >>>>>>>>> I guess. Otherwise we'd have to go back to sssd > > > > > >>>>>>>>> which can inject additional values in krb5.conf, > > > > > >>>>>>>>> however I am not sure it would be ok to set > > > > > >>>>>>>>> something like this in the sssd's pubconf > > > > > >>>>>>>>> includes ... > > > > > >>>>>>>> > > > > > >>>>>>>> Agreed, pubconf update does not sound right. > > > > > >>>>>>>> > > > > > >>>>>>>> However, we already update krb5.conf on client > > > > > >>>>>>>> updates, in %post: > > > > > >>>>>>>> > > > > > >>>>>>>> %post client > > > > > >>>>>>>> if [ $1 -gt 1 ] ; then > > > > > >>>>>>>> # Has the client been configured? > > > > > >>>>>>>> restore=0 > > > > > >>>>>>>> test -f > > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' && > > > > > >>>>>>>> restore=$(wc -l > > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | > > > > > >>>>>>>> awk '{print $1}') > > > > > >>>>>>>> > > > > > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore > > > > > >>>>>>>> -ge 2 ]; then if ! grep -E -q > > > > > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > > > > > >>>>>>>> 2>/dev/null ; then > > > > > >>>>>>>> echo > > > > > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > > > > > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > > > > > >>>>>>>>>>> /etc/krb5.conf.ipanew > > > > > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > > > > > >>>>>>>> /sbin/restorecon /etc/krb5.conf > > > > > >>>>>>>> fi > > > > > >>>>>>>> fi > > > > > >>>>>>>> ... > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> This particular update is more difficult as not a > > > > > >>>>>>>> first line needs to be changed. Without adding ipa > > > > > >>>>>>>> client update tool with some reasonable krb5.conf > > > > > >>>>>>>> parser, we could do something along the lines of > > > > > >>>>>>>> > > > > > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n > > > > > >>>>>>>> udp_preference_limit = 0/g' /etc/krb5.conf > > > > > >>>>>>>> > > > > > >>>>>>>> (tested), but it is not pretty. > > > > > >>>>>>> > > > > > >>>>>>> What happen the next time you run it again ? > > > > > >>>>>>> > > > > > >>>>>>> Simo. > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>>> It would of course be added again, you would need to > > > > > >>>>>> first grep for presence of udp_preference_limit > > > > > >>>>>> setting. Question is if this approach is safe enough > > > > > >>>>>> to be in our client %post upgrade. We already upgrade > > > > > >>>>>> krb5.conf here, just the change is much easier as we > > > > > >>>>>> just add a line to the beginning of the file. > > > > > >>>>> > > > > > >>>>> Well the concern (aside of duplication) is that an > > > > > >>>>> admin may "correct" the krb5.conf file to remove that > > > > > >>>>> option (for example because his clients also connect to > > > > > >>>>> a differen (older) KDC and must use UDP in preference. > > > > > >>>>> But now we end up messing with its krb5.conf every time > > > > > >>>>> an update is released. An update tool that keep tracks > > > > > >>>>> of whether a specific update has already been applied > > > > > >>>>> and does not retry every time would be needed IMO. > > > > > >>>>> > > > > > >>>>> Simo. > > > > > >>>> > > > > > >>>> In 4.1.x (as there is not much time to develop a separate > > > > > >>>> client update tool), we could grep just for > > > > > >>>> "udp_preference_limit" presence so that if admin changes > > > > > >>>> it's value or comment it, it would not be added again. > > > > > >>> > > > > > >>> Ok then maybe we add this: > > > > > >>> > > > > > >>> # The following value has been added by a freeipa client > > > > > >>> update # if you want to disable it, please comment it, do > > > > > >>> not delete it # or it will be re-added on the next update > > > > > >>> udp_preference_limit = 0 > > > > > >>> > > > > > >>> What do you think ? > > > > > >>> Simo. > > > > > >>> > > > > > >> > > > > > >> Sure, this could work (though it is quite lengthy). > > > > > > > > > > > > I think it would be sufficient to only perform the addition > > > > > > of udp_preference_limit if it does not already exist and if > > > > > > the version number of the package we are upgrading from is > > > > > > less than the one where we introduced the change. > > > > > > > > > > > > Nathaniel > > > > > > > > > > > > > > > > Or to simply call python and get the value of our state store > > > > > keeping track what was done on upgrades. This would work: > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > > 0 > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; > > > > > sysupgrade.set_upgrade_state('krb5.conf', > > > > > 'udp_preference_limit_set', True)" > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > > 1 > > > > > > > > > > You would just need to come up with something that's present > > > > > on the client, this is just on the server sub package. > > > > > > > > What about the attached approach? It is untested, but I can > > > > test it if we like this method. > > > > > > > > Basically, create an include directory that we ship defaults in. > > > > Admins can update /etc/krb5.conf to override the defaults. If we > > > > need to change the default, we just change the file we ship. > > > > > > > > We can enable this on upgrades by ensuring that the appropriate > > > > includedir statement appears at the top of the file. The nice > > > > thing about this approach is that is preserves admin > > > > modifications (unless they removed the configuration directive > > > > rather than changing it). > > > > > > > > Thoughts? > > > > > > Simo has just informed me that we will be > > > getting /etc/krb5.conf.d at some point in the near future. So I > > > think for now I'd like to have the original patch[1] reviewed > > > (not the includedir experiment patch). We then document the TCP > > > issue for upgrades. Then, in the future, when we > > > get /etc/krb5.conf.d, we can just stick the default in there. > > > > > > Is everyone cool with this? > > > > +1 > > If there's an easy way to set this option in SSSD, I'm fine with > setting the same default in SSSD as well. > > Sorry we dropped the ball on this item from the SSSD side, I think > it's just b/c there was no ticket filed ... We discussed doing that, but we think sssd is not the right place, as an admin may legitimately want to remove that option. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 14 14:39:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Nov 2014 15:39:58 +0100 Subject: [Freeipa-devel] [PATCH] Add help string on how to configure multiple DNS forwards on cli In-Reply-To: <5465F7C3.10600@redhat.com> References: <20141111123711.GU1849@tscherf.redhat.com> <546207C5.1080603@redhat.com> <20141111144239.GZ1849@tscherf.redhat.com> <54623049.3010509@redhat.com> <20141114123125.GS1849@tscherf.redhat.com> <5465F7C3.10600@redhat.com> Message-ID: <5466143E.2090201@redhat.com> On 11/14/2014 01:38 PM, Martin Basti wrote: > On 14/11/14 13:31, Thorsten Scherf wrote: >> On [Tue, 11.11.2014 16:50], Martin Basti wrote: >>> On 11/11/14 15:42, Thorsten Scherf wrote: >>>> On [Tue, 11.11.2014 13:57], Martin Basti wrote: >>>>> On 11/11/14 13:37, Thorsten Scherf wrote: >>>>>> The ipa-server-install man page is more descriptive on how to configure >>>>>> multiple DNS forwarders than the cli help. The cli help is more verbose >>>>>> now. >>>>>> >>>>>> https://fedorahosted.org//ticket/4465 >>>>>> >>>>>> Cheers, >>>>>> Thorsten >>>>>> >>>>>> >>>>> Hello, >>>>> >>>>> thanks for patch, but I have a few objections. >>>>> >>>>> 1) Trac link in commit is corrupted >>>>> 2) The forwarder option is in more installation scripts: >>>>> * ipa-dns-install >>>>> * ipa-replica-install >>>>> * ipa-server-install >>>> >>>> Please find the new patch attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4465 >>>> >>>> Cheers, >>>> Thorsten >>>> >>>> >>> Thank you, ACK. >>> >>> Please read how to format a patch for future. >>> http://www.freeipa.org/page/Contribute/Patch_Format >> >> yeah, sorry, will do the next time. >> >> Can you push the patch to master? >> >> Cheers, >> Thorsten >> > > Yes it can, but I don't have rights to do that. Pushed to: master: 4c670919a5b15b70ff6efb50e9bb60eb45cecdba ipa-4-1: 8a3389d30c8f47d58e889a9772d68f5e70a4cd71 Martin From pviktori at redhat.com Fri Nov 14 16:20:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Nov 2014 17:20:06 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <546602B4.3070609@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <546602B4.3070609@redhat.com> Message-ID: <54662BB6.30509@redhat.com> On 11/14/2014 02:25 PM, Petr Vobornik wrote: > On 14.11.2014 14:08, Petr Viktorin wrote: >> On 11/14/2014 01:18 PM, Petr Vobornik wrote: >> [...] >>>> >>>> Nope, defaults are filled in by the client. (And also on the server if >>>> they're still missing; it's part of the common validation.) >>> >>> IMHO this is quite unfortunate behavior which may also fail horribly if >>> there is a newer client and an older server -> backwards compatibility >>> is on API level, not CLI level. Defaults should be filled by server, not >>> a client. We should seriously reconsider the design of our CLI. But >>> that's for different, future discussion. >> >> You can't use a newer client with an older server, you get a >> VersionError in that case. > > And that's bad because, IMHO, this case may be more common that a newer > server and an older client, e.g., RHEL 6.5 server and Fedora 21 client. > >> >> Feel free to file a ticket. But yes, redesigning the API is not exactly >> a priority. >> >>> That's said and given the circumstances, it is easier and cleaner to >>> return the --qrcode back as no_param now than to deal with potential >>> future issues. >> >> What's the reason to break the CLI by making it no_param? > > Sorry I meant, no_option, there is no no_param. Because it returns it > back to Nathaniel's argument about interactive session and I agree with > it. Why would we have both --no-qrcode and --qrcode options available on > CLI? It breaks the CLI, and for that there should be a better reason than "it looks bad". The CLI is an interface as well. -- Petr? From pspacek at redhat.com Fri Nov 14 16:31:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 14 Nov 2014 17:31:51 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141113202255.373aa1ca@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> Message-ID: <54662E77.9020608@redhat.com> On 14.11.2014 02:22, Simo Sorce wrote: > On Tue, 11 Nov 2014 16:29:51 +0100 > Petr Spacek wrote: > >> Hello, >> >> this thread is about RFE >> "IPA servers when installed should register themselves in the >> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >> >> It is not a complete design, just a raw idea. >> >> >> Use case >> ======== >> FreeIPA installation to a network with existing DNS infrastructure + >> network administrator who is not willing to add/maintain new DNS >> servers "just for FreeIPA". >> >> >> High-level idea >> =============== >> - Transform dns* commands from FreeIPA framework to equivalent >> "nsupdate" commands and send DNS updates to existing DNS servers. >> - Provide necessary encryption/signing keys to nsupdate. >> >> >> 1) Integration to FreeIPA framework >> =================================== >> First of all, we need to decide if "external DNS integration" can be >> used at the same time with FreeIPA-integrated DNS or not. >> Side-question is what to do if a first server is installed with >> external-DNS but another replica is being installed with >> integrated-DNS and so on. > > I think being able to integrate with an external DNS is important, and > not just at the server level, being able to distribute TSIG keys to > client would be nice too, though a lot less important, than getting > server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. >> In other words, the question is if current "dns.py" plugin shipped >> with FreeIPA framework should be: >> >> a) Extended dns.py with dnsexternal-* commands >> ---------------------------------------------- >> Disadvantages: >> - It complicate FreeIPA DNS interface which is a complex beast even >> now. >> - We would have add condition to every DNS API call in installers >> which would increase horribleness of the installer code even more (or >> add another layer of abstraction...). > > I agree having a special command is undesirable. >> >> - I don't see a point in using integrated-DNS with external-DNS at >> the same time. To use integrated-DNS you have to get a proper DNS >> delegation from parent domain - and if you can get the delegation >> then there is no point in using external DNS ... > > I disagree on this point, it makes a lot of sense to have some zones > maintained by IPA and ... some not. > >> Advantages: >> - You can use external & integrated DNS at the same time. > > We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. >> b) Replace dns.py with another implementation of current dnszone-* & >> dnsrecord-* API. >> --------------------------------------------------------------------- >> This seems like a cleaner approach to me. It could be shipped as >> ipa-server-dns-external package (opposed to "standard" ipa-server-dns >> package). >> >> Advantages: >> - It could seamlessly work with FreeIPA client installer because the >> dns*->nsupdate command transformation would be done on FreeIPA server >> and client doesn't need to know about it. >> - Does not require re-training/not much new documentation because >> commands are the same. >> >> Disadvantages: >> - You can't use integrated & external DNS at the same time (but I >> don't think it justifies the added complexity). > > I disagree. > > One of the reason to use a mix is to allow smooth migrations where > zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. >> Petr^3 or anyone else, what do you propose? > > I think what I'd like to see is to be able to configure a DNS zone in > LDAP and mark it external. > The zone would held the TSIG keys necessary to perform DNS updates. > > When the regular ipa dnsrecord-add etc... commands are called, the > framework detects that the zone is "external", fewttches the TSIG key > (if the user has access to it) and spawn an nsupdate command that will > perform the update against whatever DNS server is authoritative for the > zone. > > Some commands may be disabled if the zone is external and appropriate > errors would be returned. Correct, this will be inevitable. >> 2) Authentication to external DNS server/keys >> ============================================= >> This is separate problem from FreeIPA framework integration. >> We will have to somehow store raw symmetric keys (for DNS TSIG) or >> keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so >> every replica can update DNS records as necessary. > > For TSIG keys I think we should just store them in a LDAP record, see > above. Without any encryption? Am I missing something? > For keytabs we can simply store them just like any other kerberos key > if we really need it (in a trust case for example, we may not need a > new keytab, we may be allowed to use our own credentials through the > trust. So we'll need to explore a bit how to properly express that in > configuration. REtrieval ok keytabs is then just a matter of running > ipa-getkeytab -r on the replica that needs it. > >> This will be the funny part because in case of AD trusts we have >> chicken-egg problem. You need to establish trust to get ticket for >> DNS/dc1.ad.example at AD principal but you can't (I guess) establish >> trust until proper DNS records are in place ... > > No, in this case we should create the records at trust establishment > time using the admin credentials we have been provided. NO chicken-egg > issue. Sorry, we surely *have* a chicken-egg issue because ipa-server-install is completely separate step from from ipa-adtrust-install which is completely separate from ipa trust-add. (And there is nothing which forces user to establish AD trust right after ipa-server-install finished.) Also, in some cases it is not possible to use the same credentials for trust establishment and for DNS updates on AD. Think about one-way trust or possibly two-way trust but established using pre-shared trust secret (which is AFAIK not usable for kinit). Alexander, could you clarify if it is possible to create an AD trust *without* DNS records for FreeIPA side of the trust? Another problem is that reliance on AD trusts would effectively prevent interoperability with non-AD DNS servers (think Infoblox or standard BIND). I tend to think that we will need to obtain credentials (AD login/pass/keytab/TSIG key) as one of ipa-server-install parameters so all DNS updates can be done right away. This would allow us have ipa-server-install script which in fact produces *working* FreeIPA domain. In other cases ipa-server-install would end but the FreeIPA domain would not be functional because of missing records in DNS. >> For 'experimental' phase I would go with pre-populated CCcache, i.e. >> admin will manually do kinit Administrator at AD and then run FreeIPA >> installer. > > We already to this, so there is no need to invent anything here IMO. Except for cases mentioned above ... >> Maybe we can re-use trust secret somehow? I don't know, I will reach >> out to AD experts with questions. >> >> This area needs more research but for now it seems feasible to re-use >> DNSSEC key distribution system for TSIG keys and keytabs so "only" >> the chicken-egg problem is left. >> >> This will need new LDAP schema but I will propose something when I'm >> done with investigation. > > Please let me know if you agree with a new zone type as a way to > "forward" updates. Generally I agree, it was my plan too. My main concern is not about LDAP structure but about FreeIPA framework and about workflow in general. It will be fun to extend the spaghetti code we have ... -- Petr^2 Spacek From npmccallum at redhat.com Fri Nov 14 17:10:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 14 Nov 2014 12:10:46 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <54662BB6.30509@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <546602B4.3070609@redhat.com> <54662BB6.30509@redhat.com> Message-ID: <1415985046.2764.1.camel@redhat.com> On Fri, 2014-11-14 at 17:20 +0100, Petr Viktorin wrote: > On 11/14/2014 02:25 PM, Petr Vobornik wrote: > > On 14.11.2014 14:08, Petr Viktorin wrote: > >> On 11/14/2014 01:18 PM, Petr Vobornik wrote: > >> [...] > >>>> > >>>> Nope, defaults are filled in by the client. (And also on the server if > >>>> they're still missing; it's part of the common validation.) > >>> > >>> IMHO this is quite unfortunate behavior which may also fail horribly if > >>> there is a newer client and an older server -> backwards compatibility > >>> is on API level, not CLI level. Defaults should be filled by server, not > >>> a client. We should seriously reconsider the design of our CLI. But > >>> that's for different, future discussion. > >> > >> You can't use a newer client with an older server, you get a > >> VersionError in that case. > > > > And that's bad because, IMHO, this case may be more common that a newer > > server and an older client, e.g., RHEL 6.5 server and Fedora 21 client. > > > >> > >> Feel free to file a ticket. But yes, redesigning the API is not exactly > >> a priority. > >> > >>> That's said and given the circumstances, it is easier and cleaner to > >>> return the --qrcode back as no_param now than to deal with potential > >>> future issues. > >> > >> What's the reason to break the CLI by making it no_param? > > > > Sorry I meant, no_option, there is no no_param. Because it returns it > > back to Nathaniel's argument about interactive session and I agree with > > it. Why would we have both --no-qrcode and --qrcode options available on > > CLI? > > It breaks the CLI, and for that there should be a better reason than "it > looks bad". The CLI is an interface as well. The attached patch retains --qrcode but specified as no_option. It is marked as deprecated. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0078.2-Enable-QR-code-display-by-default-in-otptoken-add.patch Type: text/x-patch Size: 5191 bytes Desc: not available URL: From npmccallum at redhat.com Fri Nov 14 17:11:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 14 Nov 2014 12:11:49 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141114090657.7e65bfe3@willson.usersys.redhat.com> References: <545CC86E.9020702@redhat.com> <20141107085129.77573940@willson.usersys.redhat.com> <545CCECD.3040205@redhat.com> <20141107090311.6c430c54@willson.usersys.redhat.com> <545CD550.9090405@redhat.com> <7963A635-2F98-4CEB-B4CB-A10B94BFA910@redhat.com> <545CD9BD.2090601@redhat.com> <1415905341.26688.5.camel@redhat.com> <1415906414.26688.9.camel@redhat.com> <20141113144028.734cf2bf@willson.usersys.redhat.com> <20141114093223.GE9338@hendrix.brq.redhat.com> <20141114090657.7e65bfe3@willson.usersys.redhat.com> Message-ID: <1415985109.2764.2.camel@redhat.com> On Fri, 2014-11-14 at 09:06 -0500, Simo Sorce wrote: > On Fri, 14 Nov 2014 10:32:23 +0100 > Jakub Hrozek wrote: > > > On Thu, Nov 13, 2014 at 02:40:28PM -0500, Simo Sorce wrote: > > > On Thu, 13 Nov 2014 14:20:14 -0500 > > > Nathaniel McCallum wrote: > > > > > > > On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote: > > > > > On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote: > > > > > > On 11/07/2014 03:28 PM, Nathaniel McCallum wrote: > > > > > > > > > > > > > >> On Nov 7, 2014, at 9:21 AM, Martin Kosek > > > > > > >> wrote: > > > > > > >> > > > > > > >> On 11/07/2014 03:03 PM, Simo Sorce wrote: > > > > > > >>> On Fri, 07 Nov 2014 14:53:17 +0100 > > > > > > >>> Martin Kosek wrote: > > > > > > >>> > > > > > > >>>> On 11/07/2014 02:51 PM, Simo Sorce wrote: > > > > > > >>>>> On Fri, 07 Nov 2014 14:26:06 +0100 > > > > > > >>>>> Martin Kosek wrote: > > > > > > >>>>> > > > > > > >>>>>> On 11/07/2014 02:20 PM, Simo Sorce wrote: > > > > > > >>>>>>> On Fri, 07 Nov 2014 08:02:02 +0100 > > > > > > >>>>>>> Martin Kosek wrote: > > > > > > >>>>>>> > > > > > > >>>>>>>> On 11/07/2014 01:46 AM, Simo Sorce wrote: > > > > > > >>>>>>>>> On Thu, 06 Nov 2014 18:00:21 -0500 > > > > > > >>>>>>>>> Nathaniel McCallum wrote: > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce > > > > > > >>>>>>>>>> wrote: > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> ----- Original Message ----- > > > > > > >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > > > >>>>>>>>>>>>> Patch attached. > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> I'm curious - what is the purpose of this patch? > > > > > > >>>>>>>>>>>> To prevent 1 second timeouts and re-transmits > > > > > > >>>>>>>>>>>> when OTP is in place? > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>> What is the expected performance impact? Could > > > > > > >>>>>>>>>>>> it be configured for OTP separately - somehow? > > > > > > >>>>>>>>>>>> (I guess that it is not possible now ...) > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> It benefits also communication of large packets > > > > > > >>>>>>>>>>> (when large MS-PAC or CAMMAC AD Data are > > > > > > >>>>>>>>>>> attached), so it is a better choice for IPA in > > > > > > >>>>>>>>>>> general. Especially given we have multiple KDC > > > > > > >>>>>>>>>>> processes configured we do not want clients > > > > > > >>>>>>>>>>> wasting KDC resources by making multiple > > > > > > >>>>>>>>>>> processes do the same operation. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> So apparently this patch never got reviewed over a > > > > > > >>>>>>>>>> year ago. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> It was related to a bug which was opened in SSSD. > > > > > > >>>>>>>>>> However, when it became clear we wanted to solve > > > > > > >>>>>>>>>> this in FreeIPA, the SSSD bug was closed but no > > > > > > >>>>>>>>>> corresponding FreeIPA bug was opened. The patch > > > > > > >>>>>>>>>> then fell through the cracks. > > > > > > >>>>>>>> > > > > > > >>>>>>>> Right - without an associated ticket tracking the > > > > > > >>>>>>>> patch, it is too easy to loose it unless the author > > > > > > >>>>>>>> prods people to review it. > > > > > > >>>>>>>> > > > > > > >>>>>>>>>> Without this patch, if OTP validation runs long we > > > > > > >>>>>>>>>> get retransmits and failures. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> One question I have is how to handle this for > > > > > > >>>>>>>>>> upgrades since (I think) this patch only handles > > > > > > >>>>>>>>>> new installs. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help > > > > > > >>>>>>>>>> is appreciated. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> I have attached a rebased version which has no > > > > > > >>>>>>>>>> other changes. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Nathaniel > > > > > > >>>>>>>>> > > > > > > >>>>>>>>> I am not sure we can do much on updates, we do not > > > > > > >>>>>>>>> have a client-update tool, I would just document it > > > > > > >>>>>>>>> I guess. Otherwise we'd have to go back to sssd > > > > > > >>>>>>>>> which can inject additional values in krb5.conf, > > > > > > >>>>>>>>> however I am not sure it would be ok to set > > > > > > >>>>>>>>> something like this in the sssd's pubconf > > > > > > >>>>>>>>> includes ... > > > > > > >>>>>>>> > > > > > > >>>>>>>> Agreed, pubconf update does not sound right. > > > > > > >>>>>>>> > > > > > > >>>>>>>> However, we already update krb5.conf on client > > > > > > >>>>>>>> updates, in %post: > > > > > > >>>>>>>> > > > > > > >>>>>>>> %post client > > > > > > >>>>>>>> if [ $1 -gt 1 ] ; then > > > > > > >>>>>>>> # Has the client been configured? > > > > > > >>>>>>>> restore=0 > > > > > > >>>>>>>> test -f > > > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' && > > > > > > >>>>>>>> restore=$(wc -l > > > > > > >>>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | > > > > > > >>>>>>>> awk '{print $1}') > > > > > > >>>>>>>> > > > > > > >>>>>>>> if [ -f '/etc/sssd/sssd.conf' -a $restore > > > > > > >>>>>>>> -ge 2 ]; then if ! grep -E -q > > > > > > >>>>>>>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > > > > > > >>>>>>>> 2>/dev/null ; then > > > > > > >>>>>>>> echo > > > > > > >>>>>>>> "includedir /var/lib/sss/pubconf/krb5.include.d/" > > > > > > >>>>>>>>> /etc/krb5.conf.ipanew cat /etc/krb5.conf > > > > > > >>>>>>>>>>> /etc/krb5.conf.ipanew > > > > > > >>>>>>>> mv /etc/krb5.conf.ipanew /etc/krb5.conf > > > > > > >>>>>>>> /sbin/restorecon /etc/krb5.conf > > > > > > >>>>>>>> fi > > > > > > >>>>>>>> fi > > > > > > >>>>>>>> ... > > > > > > >>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>>> This particular update is more difficult as not a > > > > > > >>>>>>>> first line needs to be changed. Without adding ipa > > > > > > >>>>>>>> client update tool with some reasonable krb5.conf > > > > > > >>>>>>>> parser, we could do something along the lines of > > > > > > >>>>>>>> > > > > > > >>>>>>>> sed -E 0i 's/(forwardable = \w+)/\1\n > > > > > > >>>>>>>> udp_preference_limit = 0/g' /etc/krb5.conf > > > > > > >>>>>>>> > > > > > > >>>>>>>> (tested), but it is not pretty. > > > > > > >>>>>>> > > > > > > >>>>>>> What happen the next time you run it again ? > > > > > > >>>>>>> > > > > > > >>>>>>> Simo. > > > > > > >>>>>>> > > > > > > >>>>>> > > > > > > >>>>>> It would of course be added again, you would need to > > > > > > >>>>>> first grep for presence of udp_preference_limit > > > > > > >>>>>> setting. Question is if this approach is safe enough > > > > > > >>>>>> to be in our client %post upgrade. We already upgrade > > > > > > >>>>>> krb5.conf here, just the change is much easier as we > > > > > > >>>>>> just add a line to the beginning of the file. > > > > > > >>>>> > > > > > > >>>>> Well the concern (aside of duplication) is that an > > > > > > >>>>> admin may "correct" the krb5.conf file to remove that > > > > > > >>>>> option (for example because his clients also connect to > > > > > > >>>>> a differen (older) KDC and must use UDP in preference. > > > > > > >>>>> But now we end up messing with its krb5.conf every time > > > > > > >>>>> an update is released. An update tool that keep tracks > > > > > > >>>>> of whether a specific update has already been applied > > > > > > >>>>> and does not retry every time would be needed IMO. > > > > > > >>>>> > > > > > > >>>>> Simo. > > > > > > >>>> > > > > > > >>>> In 4.1.x (as there is not much time to develop a separate > > > > > > >>>> client update tool), we could grep just for > > > > > > >>>> "udp_preference_limit" presence so that if admin changes > > > > > > >>>> it's value or comment it, it would not be added again. > > > > > > >>> > > > > > > >>> Ok then maybe we add this: > > > > > > >>> > > > > > > >>> # The following value has been added by a freeipa client > > > > > > >>> update # if you want to disable it, please comment it, do > > > > > > >>> not delete it # or it will be re-added on the next update > > > > > > >>> udp_preference_limit = 0 > > > > > > >>> > > > > > > >>> What do you think ? > > > > > > >>> Simo. > > > > > > >>> > > > > > > >> > > > > > > >> Sure, this could work (though it is quite lengthy). > > > > > > > > > > > > > > I think it would be sufficient to only perform the addition > > > > > > > of udp_preference_limit if it does not already exist and if > > > > > > > the version number of the package we are upgrading from is > > > > > > > less than the one where we introduced the change. > > > > > > > > > > > > > > Nathaniel > > > > > > > > > > > > > > > > > > > Or to simply call python and get the value of our state store > > > > > > keeping track what was done on upgrades. This would work: > > > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > > > 0 > > > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; > > > > > > sysupgrade.set_upgrade_state('krb5.conf', > > > > > > 'udp_preference_limit_set', True)" > > > > > > > > > > > > # python2 -c "from ipaserver.install import sysupgrade; import > > > > > > sys; sys.exit(1 if sysupgrade.get_upgrade_state('krb5.conf', > > > > > > 'udp_preference_limit_set') else 0)" # echo $? > > > > > > 1 > > > > > > > > > > > > You would just need to come up with something that's present > > > > > > on the client, this is just on the server sub package. > > > > > > > > > > What about the attached approach? It is untested, but I can > > > > > test it if we like this method. > > > > > > > > > > Basically, create an include directory that we ship defaults in. > > > > > Admins can update /etc/krb5.conf to override the defaults. If we > > > > > need to change the default, we just change the file we ship. > > > > > > > > > > We can enable this on upgrades by ensuring that the appropriate > > > > > includedir statement appears at the top of the file. The nice > > > > > thing about this approach is that is preserves admin > > > > > modifications (unless they removed the configuration directive > > > > > rather than changing it). > > > > > > > > > > Thoughts? > > > > > > > > Simo has just informed me that we will be > > > > getting /etc/krb5.conf.d at some point in the near future. So I > > > > think for now I'd like to have the original patch[1] reviewed > > > > (not the includedir experiment patch). We then document the TCP > > > > issue for upgrades. Then, in the future, when we > > > > get /etc/krb5.conf.d, we can just stick the default in there. > > > > > > > > Is everyone cool with this? > > > > > > +1 > > > > If there's an easy way to set this option in SSSD, I'm fine with > > setting the same default in SSSD as well. > > > > Sorry we dropped the ball on this item from the SSSD side, I think > > it's just b/c there was no ticket filed ... > > We discussed doing that, but we think sssd is not the right place, as > an admin may legitimately want to remove that option. In my understanding, SSSD gets this for free with this patch. From simo at redhat.com Fri Nov 14 18:26:25 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 14 Nov 2014 13:26:25 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5465FEC8.4030602@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> Message-ID: <20141114132625.3c0a1e8b@willson.usersys.redhat.com> On Fri, 14 Nov 2014 14:08:24 +0100 Petr Viktorin wrote: > On 11/14/2014 01:18 PM, Petr Vobornik wrote: > [...] > >> > >> Nope, defaults are filled in by the client. (And also on the > >> server if they're still missing; it's part of the common > >> validation.) > > > > IMHO this is quite unfortunate behavior which may also fail > > horribly if there is a newer client and an older server -> > > backwards compatibility is on API level, not CLI level. Defaults > > should be filled by server, not a client. We should seriously > > reconsider the design of our CLI. But that's for different, future > > discussion. > > You can't use a newer client with an older server, you get a > VersionError in that case. Does it break only for this command ? Or in general. If a Fedora 21 client can't talk to a RHEL 6 server we have a huge problem that we need to fix *yesterday*. > Feel free to file a ticket. But yes, redesigning the API is not > exactly a priority. > > > That's said and given the circumstances, it is easier and cleaner to > > return the --qrcode back as no_param now than to deal with potential > > future issues. > > What's the reason to break the CLI by making it no_param? > > -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Nov 14 19:03:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Nov 2014 20:03:34 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <20141114132625.3c0a1e8b@willson.usersys.redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> Message-ID: <54665206.90700@redhat.com> On 11/14/2014 07:26 PM, Simo Sorce wrote: > On Fri, 14 Nov 2014 14:08:24 +0100 > Petr Viktorin wrote: > >> On 11/14/2014 01:18 PM, Petr Vobornik wrote: >> [...] >>>> >>>> Nope, defaults are filled in by the client. (And also on the >>>> server if they're still missing; it's part of the common >>>> validation.) >>> >>> IMHO this is quite unfortunate behavior which may also fail >>> horribly if there is a newer client and an older server -> >>> backwards compatibility is on API level, not CLI level. Defaults >>> should be filled by server, not a client. We should seriously >>> reconsider the design of our CLI. But that's for different, future >>> discussion. >> >> You can't use a newer client with an older server, you get a >> VersionError in that case. > > Does it break only for this command ? > Or in general. In general. It's been built into the framework since IPA 2.0 [0]. There have been four years of development assuming this compatibility scheme. > If a Fedora 21 client can't talk to a RHEL 6 server we have a huge > problem that we need to fix *yesterday*. Then we have a huge task on our hands. [0] ticket https://fedorahosted.org/freeipa/ticket/584 -- Petr? From pviktori at redhat.com Fri Nov 14 19:05:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Nov 2014 20:05:35 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <54665206.90700@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> Message-ID: <5466527F.7060805@redhat.com> On 11/14/2014 08:03 PM, Petr Viktorin wrote: > On 11/14/2014 07:26 PM, Simo Sorce wrote: >> On Fri, 14 Nov 2014 14:08:24 +0100 >> Petr Viktorin wrote: >> >>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: >>> [...] >>>>> >>>>> Nope, defaults are filled in by the client. (And also on the >>>>> server if they're still missing; it's part of the common >>>>> validation.) >>>> >>>> IMHO this is quite unfortunate behavior which may also fail >>>> horribly if there is a newer client and an older server -> >>>> backwards compatibility is on API level, not CLI level. Defaults >>>> should be filled by server, not a client. We should seriously >>>> reconsider the design of our CLI. But that's for different, future >>>> discussion. >>> >>> You can't use a newer client with an older server, you get a >>> VersionError in that case. >> >> Does it break only for this command ? >> Or in general. > > In general. It's been built into the framework since IPA 2.0 [0]. There > have been four years of development assuming this compatibility scheme. I should clarify ? this is only for the API, i.e. the `ipa` command. Clients of the "ipa-client-install" sort don't use the API. >> If a Fedora 21 client can't talk to a RHEL 6 server we have a huge >> problem that we need to fix *yesterday*. > > Then we have a huge task on our hands. > > > [0] ticket https://fedorahosted.org/freeipa/ticket/584 > -- Petr? From simo at redhat.com Fri Nov 14 19:29:33 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 14 Nov 2014 14:29:33 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <5466527F.7060805@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> Message-ID: <20141114142933.3e36c17a@willson.usersys.redhat.com> On Fri, 14 Nov 2014 20:05:35 +0100 Petr Viktorin wrote: > On 11/14/2014 08:03 PM, Petr Viktorin wrote: > > On 11/14/2014 07:26 PM, Simo Sorce wrote: > >> On Fri, 14 Nov 2014 14:08:24 +0100 > >> Petr Viktorin wrote: > >> > >>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: > >>> [...] > >>>>> > >>>>> Nope, defaults are filled in by the client. (And also on the > >>>>> server if they're still missing; it's part of the common > >>>>> validation.) > >>>> > >>>> IMHO this is quite unfortunate behavior which may also fail > >>>> horribly if there is a newer client and an older server -> > >>>> backwards compatibility is on API level, not CLI level. Defaults > >>>> should be filled by server, not a client. We should seriously > >>>> reconsider the design of our CLI. But that's for different, > >>>> future discussion. > >>> > >>> You can't use a newer client with an older server, you get a > >>> VersionError in that case. > >> > >> Does it break only for this command ? > >> Or in general. > > > > In general. It's been built into the framework since IPA 2.0 [0]. > > There have been four years of development assuming this > > compatibility scheme. > > I should clarify ? this is only for the API, i.e. the `ipa` command. > Clients of the "ipa-client-install" sort don't use the API. I know they don't or it would be a disaster. However it is unreasonable to keep changing the API without any 2 way compatibility going forward. I expect it to be extremely common for an admin to have a much more recent desktop then the server being used. Having to jump through hoops to use the admin cli is not friendly. And we do not change the actual CLI that much, so it would be unexpected. We need to take seriously in consideration compatibility going both ways (of course new commands should just get "NotSupported" errors when used against old servers. But old commands should work, there is no good reason to break this kind of compatibility, it is just an artefact of botched versioning we did a few years ago and it is about time we seriously address this, also because once we make one of these APIs public and supported we cannot willy nilly break it, and we cannot force people to change their software if all works well except a version number being sent in and out. Individual interfaces need to be versioned, and one an interface is release it must no change (a new version need to be created if changes are needed). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Nov 18 04:42:24 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Nov 2014 23:42:24 -0500 Subject: [Freeipa-devel] [PATCH] Improve developers RPM builds Message-ID: <20141117234224.5095d1ee@willson.usersys.redhat.com> This small patch will add a date component to the ipa version when building straight from git. This way successive builds will clearly install on top of a previous one even if alphabetically the git commit id has gone backwards. It also gives a chance of remembering what/when you had installed on older VMs at a simply rpm -qi glance. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-UTC-date-to-GIT-snapshot-version-generation.patch Type: text/x-patch Size: 1372 bytes Desc: not available URL: From simo at redhat.com Tue Nov 18 05:01:20 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 00:01:20 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation Message-ID: <20141118000120.23536867@willson.usersys.redhat.com> Hello team, Recently Alexander opened the following bug: https://fedorahosted.org/freeipa/ticket/4718 The problem with this code is that manual ASN.1 encoding is fragile and too prone to error, and I found various issues while investigating the bug. So I decided to give a shot at replacing the fragile manual code with more robust code autogenerated by the asn1c compiler. While working on replacing the code with the autogenerated one I discovered additional encoding issues of which the following ticket represent only the most evident: https://fedorahosted.org/freeipa/ticket/4728 I found numerous encoding errors which basically made the getkeytab control we implemented in both the client and the server not respect the encoding we actually defined with ASN.1 notation here: http://www.freeipa.org/page/V4/Keytab_Retrieval While digging and testing replacement functions is also became evident that the getkeytab feature was only partially working and that the bug in 4718 was not just a minor error, but cannot ever work on existing servers as there are compounding bugs that would prevent using the getkeytab protocol to ever work if the user specified enctypes via ipa-getkeytab instead of just requesting the server's defaults. Because of this and because it was just too hard *and* useless to try to be compatible with existing broken clients and servers the new code breaks compatibility for correctness of implementation. The break in compatibility is mitigated by the fact that ipa-getkeytab always falls back to the old setkeytab control in case of error, so normal operations will not be disrupted. The only feature that will not work if you have a buggy client or a buggy server is the keytab retrieval option, as that feature is only available with the new control. Given we have only recently introduced CLI and UI to actually enable the use of the retrieval option and given the fact 4.x has not yet hit major distribution stable releases I think that this patchset is acceptable as long as we can land it in 4.1.2 and/or in an immediately following patch release (also in 4.0.x possibly) so that it can land as a zero day upgrade for Fedora (and an upgrade for Debian). If you have any questions, please shoot. This code is fully tested by me on top of master. I think it should apply directly on 4.1.2 and 4.0.x with none or minor changes. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-filtering-of-enctypes-in-server-code.patch Type: text/x-patch Size: 3502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-asn1c-generated-code-for-keytab-controls.patch Type: text/x-patch Size: 352063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Use-asn1c-helpers-to-encode-decode-the-getkeytab-con.patch Type: text/x-patch Size: 25634 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 18 07:54:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Nov 2014 08:54:30 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <54631328.7030204@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> Message-ID: <546AFB36.4010302@redhat.com> Dne 12.11.2014 v 08:58 Petr Spacek napsal(a): > On 11.11.2014 12:27, Jan Cholasta wrote: >> Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a): >>> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>>>> From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001 >>>> From: Jan Cholasta >>>> Date: Mon, 10 Nov 2014 18:10:27 +0000 >>>> Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb >>>> >>>> https://fedorahosted.org/freeipa/ticket/4713 >>>> --- >>>> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>> b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>> index c8f6c76..debcd1b 100644 >>>> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>> @@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context >>>> context, >>>> ipactx->kdc_hostname, >>>> strlen(ipactx->kdc_hostname), >>>> NULL, NULL, &result) == 0) { >>>> kerr = ipadb_reinit_mspac(ipactx, true); >>>> + if (kerr != 0 && kerr != ENOENT) { >>>> + goto done; >>>> + } >>>> } >>>> } >>>> >>> I'm not sure we should drop the sign_authdata request here. If we were >>> able to re-initialize our view of trusted domains, we simply cannot >>> re-sign incoming PAC but this is handled in ipadb_verify_pac() and >>> ipadb_sign_pac() and if the former returns NULL value for PAC, we exit >>> with a return code of 0 while this change will fail a cross-realm TGT >>> request unconditionally. >>> >> >> OK, what would be a proper fix? Just ignore the return value of >> ipadb_reinit_mspac here? > > Guys, I did not see the code but all instances of "ignore return code" I have > seen were wrong, including cases where code comment explicitly said "we ignore > return code on purpose" :-) > > At least log an error message if you can't think of anything better ... > I don't disagree, if that's the proper fix. Alexander, or someone else, could you please finish the review of the patches? Thanks. -- Jan Cholasta From mbasti at redhat.com Tue Nov 18 11:07:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Nov 2014 12:07:34 +0100 Subject: [Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode In-Reply-To: <5464EA3B.3050004@redhat.com> References: <5464EA3B.3050004@redhat.com> Message-ID: <546B2876.6040301@redhat.com> On 13/11/14 18:28, Martin Basti wrote: > To allow IDNA zonemgr email, value must be unicode not ASCII > Ticket: https://fedorahosted.org/freeipa/ticket/4724 > > Patch attached. > Patch for ipa-4.0 added. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.0-mbasti-0165-Fix-zonemgr-must-be-unicode-value.patch Type: text/x-patch Size: 1102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.1-mbasti-0165-Fix-zonemgr-must-be-unicode-value.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 18 11:17:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Nov 2014 12:17:19 +0100 Subject: [Freeipa-devel] [PATCH] 0673 Do not restore SELinux settings that were not backed up Message-ID: <546B2ABF.7020407@redhat.com> This fixes https://fedorahosted.org/freeipa/ticket/4678 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0673-Do-not-restore-SELinux-settings-that-were-not-backed.patch Type: text/x-patch Size: 1836 bytes Desc: not available URL: From mkosek at redhat.com Tue Nov 18 11:27:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Nov 2014 12:27:28 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <20141114142933.3e36c17a@willson.usersys.redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> <20141114142933.3e36c17a@willson.usersys.redhat.com> Message-ID: <546B2D20.2040108@redhat.com> On 11/14/2014 08:29 PM, Simo Sorce wrote: > On Fri, 14 Nov 2014 20:05:35 +0100 > Petr Viktorin wrote: > >> On 11/14/2014 08:03 PM, Petr Viktorin wrote: >>> On 11/14/2014 07:26 PM, Simo Sorce wrote: >>>> On Fri, 14 Nov 2014 14:08:24 +0100 >>>> Petr Viktorin wrote: >>>> >>>>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: >>>>> [...] >>>>>>> >>>>>>> Nope, defaults are filled in by the client. (And also on the >>>>>>> server if they're still missing; it's part of the common >>>>>>> validation.) >>>>>> >>>>>> IMHO this is quite unfortunate behavior which may also fail >>>>>> horribly if there is a newer client and an older server -> >>>>>> backwards compatibility is on API level, not CLI level. Defaults >>>>>> should be filled by server, not a client. We should seriously >>>>>> reconsider the design of our CLI. But that's for different, >>>>>> future discussion. >>>>> >>>>> You can't use a newer client with an older server, you get a >>>>> VersionError in that case. >>>> >>>> Does it break only for this command ? >>>> Or in general. >>> >>> In general. It's been built into the framework since IPA 2.0 [0]. >>> There have been four years of development assuming this >>> compatibility scheme. >> >> I should clarify ? this is only for the API, i.e. the `ipa` command. >> Clients of the "ipa-client-install" sort don't use the API. > > I know they don't or it would be a disaster. > However it is unreasonable to keep changing the API without any 2 way > compatibility going forward. > > I expect it to be extremely common for an admin to have a much more > recent desktop then the server being used. Having to jump through hoops > to use the admin cli is not friendly. And we do not change the actual > CLI that much, so it would be unexpected. > > We need to take seriously in consideration compatibility going both > ways (of course new commands should just get "NotSupported" errors when > used against old servers. But old commands should work, there is no > good reason to break this kind of compatibility, it is just an artefact > of botched versioning we did a few years ago and it is about time we > seriously address this, also because once we make one of these APIs > public and supported we cannot willy nilly break it, and we cannot > force people to change their software if all works well except a > version number being sent in and out. > > Individual interfaces need to be versioned, and one an interface is > release it must no change (a new version need to be created if changes > are needed). Well, it is what it is. This paradigm (forward compatibility only) was there since the beginning (read - IPA 2.0) and we cannot change it that simply - it is big effort on it's own that needs to be planned, designed, implemented. To solve this, you would need to introduce some kind of version/metadata handshake between new client and old server so that the clients knows what API does the old server expects. It would need to know which attributes were changed/added in incompatible way between it's and server's version. Martin From dkupka at redhat.com Tue Nov 18 11:43:29 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 18 Nov 2014 12:43:29 +0100 Subject: [Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode In-Reply-To: <546B2876.6040301@redhat.com> References: <5464EA3B.3050004@redhat.com> <546B2876.6040301@redhat.com> Message-ID: <546B30E1.4080406@redhat.com> On 11/18/2014 12:07 PM, Martin Basti wrote: > On 13/11/14 18:28, Martin Basti wrote: >> To allow IDNA zonemgr email, value must be unicode not ASCII >> Ticket: https://fedorahosted.org/freeipa/ticket/4724 >> >> Patch attached. >> > Patch for ipa-4.0 added. > Thanks, works for me, ACK. -- David Kupka From simo at redhat.com Tue Nov 18 12:45:57 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 07:45:57 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <546B2D20.2040108@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> <20141114142933.3e36c17a@willson.usersys.redhat.com> <546B2D20.2040108@redhat.com> Message-ID: <20141118074557.4a430528@willson.usersys.redhat.com> On Tue, 18 Nov 2014 12:27:28 +0100 Martin Kosek wrote: > On 11/14/2014 08:29 PM, Simo Sorce wrote: > > On Fri, 14 Nov 2014 20:05:35 +0100 > > Petr Viktorin wrote: > > > >> On 11/14/2014 08:03 PM, Petr Viktorin wrote: > >>> On 11/14/2014 07:26 PM, Simo Sorce wrote: > >>>> On Fri, 14 Nov 2014 14:08:24 +0100 > >>>> Petr Viktorin wrote: > >>>> > >>>>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: > >>>>> [...] > >>>>>>> > >>>>>>> Nope, defaults are filled in by the client. (And also on the > >>>>>>> server if they're still missing; it's part of the common > >>>>>>> validation.) > >>>>>> > >>>>>> IMHO this is quite unfortunate behavior which may also fail > >>>>>> horribly if there is a newer client and an older server -> > >>>>>> backwards compatibility is on API level, not CLI level. > >>>>>> Defaults should be filled by server, not a client. We should > >>>>>> seriously reconsider the design of our CLI. But that's for > >>>>>> different, future discussion. > >>>>> > >>>>> You can't use a newer client with an older server, you get a > >>>>> VersionError in that case. > >>>> > >>>> Does it break only for this command ? > >>>> Or in general. > >>> > >>> In general. It's been built into the framework since IPA 2.0 [0]. > >>> There have been four years of development assuming this > >>> compatibility scheme. > >> > >> I should clarify ? this is only for the API, i.e. the `ipa` > >> command. Clients of the "ipa-client-install" sort don't use the > >> API. > > > > I know they don't or it would be a disaster. > > However it is unreasonable to keep changing the API without any 2 > > way compatibility going forward. > > > > I expect it to be extremely common for an admin to have a much more > > recent desktop then the server being used. Having to jump through > > hoops to use the admin cli is not friendly. And we do not change > > the actual CLI that much, so it would be unexpected. > > > > We need to take seriously in consideration compatibility going both > > ways (of course new commands should just get "NotSupported" errors > > when used against old servers. But old commands should work, there > > is no good reason to break this kind of compatibility, it is just > > an artefact of botched versioning we did a few years ago and it is > > about time we seriously address this, also because once we make one > > of these APIs public and supported we cannot willy nilly break it, > > and we cannot force people to change their software if all works > > well except a version number being sent in and out. > > > > Individual interfaces need to be versioned, and one an interface is > > release it must no change (a new version need to be created if > > changes are needed). > > Well, it is what it is. This paradigm (forward compatibility only) > was there since the beginning (read - IPA 2.0) and we cannot change > it that simply - it is big effort on it's own that needs to be > planned, designed, implemented. And needs to be changed, it always was supposed to be "temporary", and it is time to change it. now that we have various distributions and not just Fedora with FreeIPA we cannot make the ipa command useless unless you happen to have the same exact version that you have on the server, normally clients are always a few versions ahead of servers which move more slowly. > To solve this, you would need to introduce some kind of > version/metadata handshake between new client and old server so that > the clients knows what API does the old server expects. It would need > to know which attributes were changed/added in incompatible way > between it's and server's version. No, this would be the wrong way to go. The solution is the same Linux adopted for ABI compatibility in libraries. We version the single API command, all we need to do is add a version field in the json structure (or even just in the command name). Any time people want to "change" a command a new command is created instead and the old one stays around for older clients. This is how all successful and backwards compatible RPC APIs are built, and we need to follow suite asap. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Nov 18 14:01:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Nov 2014 15:01:11 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <5464B719.9090304@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> <546353A5.505@redhat.com> <5464AB28.5080405@redhat.com> <5464B719.9090304@redhat.com> Message-ID: <546B5127.7020205@redhat.com> Hi, Dne 13.11.2014 v 14:50 Martin Basti napsal(a): > On 13/11/14 13:59, Jan Cholasta wrote: >> Dne 12.11.2014 v 13:33 Martin Basti napsal(a): >>> On 11/11/14 16:58, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >>>>> Using specfile to create file doesn't work if named user is not on >>>>> system. >>>>> Appropriate permission have to be set during ipa-dns installation. >>>>> >>>>> Patch attached >>>>> >>>> >>>> Why is the directory set up in dnskeysyncinstance instead of >>>> bindinstance? >>> Because, dnskeysyncinstance is the daemon which requires permission >>> change. >>> (dir is created by dyndb-ldap plugin) >> >> OK. But please rename the method to something more suitable >> (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. >> >> Also please change the ticket link to >> (cloned from BZ). >> >>> >>>> >>>> The original patch was released with 4.1.1, shouldn't there be update >>>> in ipa-upgradeconfig? >>> Cases: >>> 1) fresh RPM install, no named user during RPM install -> named doesn't >>> start, user had to fix it immediately, can't wait until next release. >>> >>> 2) fresh RPM install, named user -> no impact >>> >>> 3) upgrade IPA with DNS -> no impact >>> >>> 4) upgrade IPA without DNS -> after DNS installation, same as 1) >>> >>> 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not >>> work (If user doesnt use DNSSEC) >>> >>> Only 5) looks serious for me, so here is updated patch. >> >> Could you do the update without the code duplication? In similar code >> an appropriate *instance method is usually called. The uid/gid resolution in ipa-upgradeconfig still looks like duplicated code to me. I would suggest doing something along these lines in ipa-upgradeconfig: dnskeysync = dnskeysyncinstance.DNSKeySyncInstance() dnskeysync.set_dyndb_ldap_workdir_permissions() and have DNSKeySyncInstance.set_dyndb_ldap_workdir_permissions() do all the real work. >> >>> >>> Martin^2 >>>> >>>> Honza >>>> >>> >>> >> >> Honza >> > Thanks. > updated patch attached. > Martin^2 > Honza -- Jan Cholasta From pviktori at redhat.com Tue Nov 18 15:28:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Nov 2014 16:28:34 +0100 Subject: [Freeipa-devel] [PATCH] 0674 Raise an error when a critical DS task fails Message-ID: <546B65A2.7040601@redhat.com> Backup and restore depend on DS tasks succeeding, but they only waited for the task to end and didn't check the result. This patch adds a new helper, run_task, that runs a task, waits for it, and checks the result. Backup and restore are changed to use this helper. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0674-Raise-an-error-when-a-critical-DS-tasks-fails.patch Type: text/x-patch Size: 8589 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 18 15:53:26 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Nov 2014 16:53:26 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <546B5127.7020205@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> <546353A5.505@redhat.com> <5464AB28.5080405@redhat.com> <5464B719.9090304@redhat.com> <546B5127.7020205@redhat.com> Message-ID: <546B6B76.7010602@redhat.com> On 18/11/14 15:01, Jan Cholasta wrote: > Hi, > > Dne 13.11.2014 v 14:50 Martin Basti napsal(a): >> On 13/11/14 13:59, Jan Cholasta wrote: >>> Dne 12.11.2014 v 13:33 Martin Basti napsal(a): >>>> On 11/11/14 16:58, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >>>>>> Using specfile to create file doesn't work if named user is not on >>>>>> system. >>>>>> Appropriate permission have to be set during ipa-dns installation. >>>>>> >>>>>> Patch attached >>>>>> >>>>> >>>>> Why is the directory set up in dnskeysyncinstance instead of >>>>> bindinstance? >>>> Because, dnskeysyncinstance is the daemon which requires permission >>>> change. >>>> (dir is created by dyndb-ldap plugin) >>> >>> OK. But please rename the method to something more suitable >>> (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. >>> >>> Also please change the ticket link to >>> (cloned from BZ). >>> >>>> >>>>> >>>>> The original patch was released with 4.1.1, shouldn't there be update >>>>> in ipa-upgradeconfig? >>>> Cases: >>>> 1) fresh RPM install, no named user during RPM install -> named >>>> doesn't >>>> start, user had to fix it immediately, can't wait until next release. >>>> >>>> 2) fresh RPM install, named user -> no impact >>>> >>>> 3) upgrade IPA with DNS -> no impact >>>> >>>> 4) upgrade IPA without DNS -> after DNS installation, same as 1) >>>> >>>> 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not >>>> work (If user doesnt use DNSSEC) >>>> >>>> Only 5) looks serious for me, so here is updated patch. >>> >>> Could you do the update without the code duplication? In similar code >>> an appropriate *instance method is usually called. > > The uid/gid resolution in ipa-upgradeconfig still looks like > duplicated code to me. I would suggest doing something along these > lines in ipa-upgradeconfig: > > dnskeysync = dnskeysyncinstance.DNSKeySyncInstance() > dnskeysync.set_dyndb_ldap_workdir_permissions() > > and have DNSKeySyncInstance.set_dyndb_ldap_workdir_permissions() do > all the real work. Updated patch attached. Martin^2 > >>> >>>> >>>> Martin^2 >>>>> >>>>> Honza >>>>> >>>> >>>> >>> >>> Honza >>> >> Thanks. >> updated patch attached. >> Martin^2 >> > > Honza > -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0161.3-Fix-named-working-directory-permissions.patch Type: text/x-patch Size: 7495 bytes Desc: not available URL: From npmccallum at redhat.com Tue Nov 18 16:23:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 11:23:42 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118000120.23536867@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> Message-ID: <1416327822.3141.17.camel@redhat.com> On Tue, 2014-11-18 at 00:01 -0500, Simo Sorce wrote: > Hello team, > > Recently Alexander opened the following bug: > https://fedorahosted.org/freeipa/ticket/4718 > > The problem with this code is that manual ASN.1 encoding is fragile and > too prone to error, and I found various issues while investigating the > bug. So I decided to give a shot at replacing the fragile manual code > with more robust code autogenerated by the asn1c compiler. > > While working on replacing the code with the autogenerated one I > discovered additional encoding issues of which the following ticket > represent only the most evident: > https://fedorahosted.org/freeipa/ticket/4728 > > I found numerous encoding errors which basically made the getkeytab > control we implemented in both the client and the server not respect > the encoding we actually defined with ASN.1 notation here: > http://www.freeipa.org/page/V4/Keytab_Retrieval > > While digging and testing replacement functions is also became evident > that the getkeytab feature was only partially working and that the bug > in 4718 was not just a minor error, but cannot ever work on existing > servers as there are compounding bugs that would prevent using the > getkeytab protocol to ever work if the user specified enctypes via > ipa-getkeytab instead of just requesting the server's defaults. > > Because of this and because it was just too hard *and* useless to try to > be compatible with existing broken clients and servers the new code > breaks compatibility for correctness of implementation. > > The break in compatibility is mitigated by the fact that ipa-getkeytab > always falls back to the old setkeytab control in case of error, so > normal operations will not be disrupted. The only feature that will not > work if you have a buggy client or a buggy server is the keytab > retrieval option, as that feature is only available with the new > control. Given we have only recently introduced CLI and UI to actually > enable the use of the retrieval option and given the fact 4.x has not > yet hit major distribution stable releases I think that this patchset > is acceptable as long as we can land it in 4.1.2 and/or in an > immediately following patch release (also in 4.0.x possibly) so that it > can land as a zero day upgrade for Fedora (and an upgrade for Debian). > > If you have any questions, please shoot. > > This code is fully tested by me on top of master. I think it should > apply directly on 4.1.2 and 4.0.x with none or minor changes. Patch 0001: Typo in the commit message. Otherwise LGTM. Patch 0002: I would strongly prefer that generated code live in its own directory and static library. Then the wrapper around that code should make its own library and link to the library for the generated code. Something like: * asn1/asn1c/libasn1c.a * asn1/libipaasn1.a Also, shouldn't the functions in ipa_asn1.[ch] get a prefix? Maybe ipa_asn1_? I'd love to see some function documentation in ipa_asn1.h. At the least, this should cover allocation semantics. Are there any changes in KeytabModule itself from the previous implementation? It looks like yes. NewKeys.enctypes for instance used to be SEQUENCE OF Int16, but is now SEQUENCE OF INTEGER. Isn't the Kerberos enctype Int32? Why not use this? Same with GKReply.newkvno (new_kvno), KrbKey.key, KrbKey.salt, etc. It seems to me like you're trying to resist pulling in the Kerberos ASN.1 module. If this is the only reason, it seems to me like we'll probably need it eventually anyway and we can just configure the compiler to drop the unused symbols. But maybe I'm missing something. Why does lber.h get added to ipa_krb5.h? Aren't we trying to get rid of lber with this patch? Nathaniel From npmccallum at redhat.com Tue Nov 18 16:25:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 11:25:19 -0500 Subject: [Freeipa-devel] [PATCH] Improve developers RPM builds In-Reply-To: <20141117234224.5095d1ee@willson.usersys.redhat.com> References: <20141117234224.5095d1ee@willson.usersys.redhat.com> Message-ID: <1416327919.3141.18.camel@redhat.com> On Mon, 2014-11-17 at 23:42 -0500, Simo Sorce wrote: > This small patch will add a date component to the ipa version when > building straight from git. > > This way successive builds will clearly install on top of a previous > one even if alphabetically the git commit id has gone backwards. > > It also gives a chance of remembering what/when you had installed on > older VMs at a simply rpm -qi glance. ACK And thank you! This has been bugging me. Nathaniel From npmccallum at redhat.com Tue Nov 18 16:27:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 11:27:14 -0500 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <20141118074557.4a430528@willson.usersys.redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> <20141114142933.3e36c17a@willson.usersys.redhat.com> <546B2D20.2040108@redhat.com> <20141118074557.4a430528@willson.usersys.redhat.com> Message-ID: <1416328034.3141.19.camel@redhat.com> On Tue, 2014-11-18 at 07:45 -0500, Simo Sorce wrote: > On Tue, 18 Nov 2014 12:27:28 +0100 > Martin Kosek wrote: > > > On 11/14/2014 08:29 PM, Simo Sorce wrote: > > > On Fri, 14 Nov 2014 20:05:35 +0100 > > > Petr Viktorin wrote: > > > > > >> On 11/14/2014 08:03 PM, Petr Viktorin wrote: > > >>> On 11/14/2014 07:26 PM, Simo Sorce wrote: > > >>>> On Fri, 14 Nov 2014 14:08:24 +0100 > > >>>> Petr Viktorin wrote: > > >>>> > > >>>>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: > > >>>>> [...] > > >>>>>>> > > >>>>>>> Nope, defaults are filled in by the client. (And also on the > > >>>>>>> server if they're still missing; it's part of the common > > >>>>>>> validation.) > > >>>>>> > > >>>>>> IMHO this is quite unfortunate behavior which may also fail > > >>>>>> horribly if there is a newer client and an older server -> > > >>>>>> backwards compatibility is on API level, not CLI level. > > >>>>>> Defaults should be filled by server, not a client. We should > > >>>>>> seriously reconsider the design of our CLI. But that's for > > >>>>>> different, future discussion. > > >>>>> > > >>>>> You can't use a newer client with an older server, you get a > > >>>>> VersionError in that case. > > >>>> > > >>>> Does it break only for this command ? > > >>>> Or in general. > > >>> > > >>> In general. It's been built into the framework since IPA 2.0 [0]. > > >>> There have been four years of development assuming this > > >>> compatibility scheme. > > >> > > >> I should clarify ? this is only for the API, i.e. the `ipa` > > >> command. Clients of the "ipa-client-install" sort don't use the > > >> API. > > > > > > I know they don't or it would be a disaster. > > > However it is unreasonable to keep changing the API without any 2 > > > way compatibility going forward. > > > > > > I expect it to be extremely common for an admin to have a much more > > > recent desktop then the server being used. Having to jump through > > > hoops to use the admin cli is not friendly. And we do not change > > > the actual CLI that much, so it would be unexpected. > > > > > > We need to take seriously in consideration compatibility going both > > > ways (of course new commands should just get "NotSupported" errors > > > when used against old servers. But old commands should work, there > > > is no good reason to break this kind of compatibility, it is just > > > an artefact of botched versioning we did a few years ago and it is > > > about time we seriously address this, also because once we make one > > > of these APIs public and supported we cannot willy nilly break it, > > > and we cannot force people to change their software if all works > > > well except a version number being sent in and out. > > > > > > Individual interfaces need to be versioned, and one an interface is > > > release it must no change (a new version need to be created if > > > changes are needed). > > > > Well, it is what it is. This paradigm (forward compatibility only) > > was there since the beginning (read - IPA 2.0) and we cannot change > > it that simply - it is big effort on it's own that needs to be > > planned, designed, implemented. > > And needs to be changed, it always was supposed to be "temporary", and > it is time to change it. > now that we have various distributions and not just Fedora with FreeIPA > we cannot make the ipa command useless unless you happen to have the > same exact version that you have on the server, normally clients are > always a few versions ahead of servers which move more slowly. > > > To solve this, you would need to introduce some kind of > > version/metadata handshake between new client and old server so that > > the clients knows what API does the old server expects. It would need > > to know which attributes were changed/added in incompatible way > > between it's and server's version. > > No, this would be the wrong way to go. > The solution is the same Linux adopted for ABI compatibility in > libraries. We version the single API command, all we need to do is add > a version field in the json structure (or even just in the command > name). > Any time people want to "change" a command a new command is created > instead and the old one stays around for older clients. > > This is how all successful and backwards compatible RPC APIs are > built, and we need to follow suite asap. +1 However, this is probably 4.2 material, no? If so, let's file a bug and schedule it. This patch still needs to land in 4.1.2, so is it okay as it is? Nathaniel From pvoborni at redhat.com Tue Nov 18 17:07:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Nov 2014 18:07:19 +0100 Subject: [Freeipa-devel] [PATCH] 0674 Raise an error when a critical DS task fails In-Reply-To: <546B65A2.7040601@redhat.com> References: <546B65A2.7040601@redhat.com> Message-ID: <546B7CC7.5020608@redhat.com> On 18.11.2014 16:28, Petr Viktorin wrote: > Backup and restore depend on DS tasks succeeding, but they only waited > for the task to end and didn't check the result. > > This patch adds a new helper, run_task, that runs a task, waits for it, > and checks the result. Backup and restore are changed to use this helper. > Does not fix, but helps with debugging of issues such as: * https://fedorahosted.org/freeipa/ticket/4712 * https://fedorahosted.org/freeipa/ticket/4736 (duplicate of 4712) If ACKed I would also assign it to the ticket 4712. -- Petr Vobornik From pvoborni at redhat.com Tue Nov 18 17:27:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Nov 2014 18:27:14 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <1416328034.3141.19.camel@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> <20141114142933.3e36c17a@willson.usersys.redhat.com> <546B2D20.2040108@redhat.com> <20141118074557.4a430528@willson.usersys.redhat.com> <1416328034.3141.19.camel@redhat.com> Message-ID: <546B8172.7050902@redhat.com> On 18.11.2014 17:27, Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 07:45 -0500, Simo Sorce wrote: >> On Tue, 18 Nov 2014 12:27:28 +0100 >> Martin Kosek wrote: >> >>> On 11/14/2014 08:29 PM, Simo Sorce wrote: >>>> On Fri, 14 Nov 2014 20:05:35 +0100 >>>> Petr Viktorin wrote: >>>> >>>>> On 11/14/2014 08:03 PM, Petr Viktorin wrote: >>>>>> On 11/14/2014 07:26 PM, Simo Sorce wrote: >>>>>>> On Fri, 14 Nov 2014 14:08:24 +0100 >>>>>>> Petr Viktorin wrote: >>>>>>> >>>>>>>> On 11/14/2014 01:18 PM, Petr Vobornik wrote: >>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Nope, defaults are filled in by the client. (And also on the >>>>>>>>>> server if they're still missing; it's part of the common >>>>>>>>>> validation.) >>>>>>>>> >>>>>>>>> IMHO this is quite unfortunate behavior which may also fail >>>>>>>>> horribly if there is a newer client and an older server -> >>>>>>>>> backwards compatibility is on API level, not CLI level. >>>>>>>>> Defaults should be filled by server, not a client. We should >>>>>>>>> seriously reconsider the design of our CLI. But that's for >>>>>>>>> different, future discussion. >>>>>>>> >>>>>>>> You can't use a newer client with an older server, you get a >>>>>>>> VersionError in that case. >>>>>>> >>>>>>> Does it break only for this command ? >>>>>>> Or in general. >>>>>> >>>>>> In general. It's been built into the framework since IPA 2.0 [0]. >>>>>> There have been four years of development assuming this >>>>>> compatibility scheme. >>>>> >>>>> I should clarify ? this is only for the API, i.e. the `ipa` >>>>> command. Clients of the "ipa-client-install" sort don't use the >>>>> API. >>>> >>>> I know they don't or it would be a disaster. >>>> However it is unreasonable to keep changing the API without any 2 >>>> way compatibility going forward. >>>> >>>> I expect it to be extremely common for an admin to have a much more >>>> recent desktop then the server being used. Having to jump through >>>> hoops to use the admin cli is not friendly. And we do not change >>>> the actual CLI that much, so it would be unexpected. >>>> >>>> We need to take seriously in consideration compatibility going both >>>> ways (of course new commands should just get "NotSupported" errors >>>> when used against old servers. But old commands should work, there >>>> is no good reason to break this kind of compatibility, it is just >>>> an artefact of botched versioning we did a few years ago and it is >>>> about time we seriously address this, also because once we make one >>>> of these APIs public and supported we cannot willy nilly break it, >>>> and we cannot force people to change their software if all works >>>> well except a version number being sent in and out. >>>> >>>> Individual interfaces need to be versioned, and one an interface is >>>> release it must no change (a new version need to be created if >>>> changes are needed). >>> >>> Well, it is what it is. This paradigm (forward compatibility only) >>> was there since the beginning (read - IPA 2.0) and we cannot change >>> it that simply - it is big effort on it's own that needs to be >>> planned, designed, implemented. >> >> And needs to be changed, it always was supposed to be "temporary", and >> it is time to change it. >> now that we have various distributions and not just Fedora with FreeIPA >> we cannot make the ipa command useless unless you happen to have the >> same exact version that you have on the server, normally clients are >> always a few versions ahead of servers which move more slowly. >> >>> To solve this, you would need to introduce some kind of >>> version/metadata handshake between new client and old server so that >>> the clients knows what API does the old server expects. It would need >>> to know which attributes were changed/added in incompatible way >>> between it's and server's version. >> >> No, this would be the wrong way to go. >> The solution is the same Linux adopted for ABI compatibility in >> libraries. We version the single API command, all we need to do is add >> a version field in the json structure (or even just in the command >> name). >> Any time people want to "change" a command a new command is created >> instead and the old one stays around for older clients. >> >> This is how all successful and backwards compatible RPC APIs are >> built, and we need to follow suite asap. > > +1 > > However, this is probably 4.2 material, no? If so, let's file a bug and > schedule it. Yes, https://fedorahosted.org/freeipa/ticket/4739 > > This patch still needs to land in 4.1.2, so is it okay as it is? I don't think the label is necessary but it doesn't hurt either, at least it's clear, so ACK. > > Nathaniel > -- Petr Vobornik From simo at redhat.com Tue Nov 18 17:40:44 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 12:40:44 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <1416327822.3141.17.camel@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> Message-ID: <20141118124044.06089fda@willson.usersys.redhat.com> On Tue, 18 Nov 2014 11:23:42 -0500 Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 00:01 -0500, Simo Sorce wrote: > > Hello team, > > > > Recently Alexander opened the following bug: > > https://fedorahosted.org/freeipa/ticket/4718 > > > > The problem with this code is that manual ASN.1 encoding is fragile > > and too prone to error, and I found various issues while > > investigating the bug. So I decided to give a shot at replacing the > > fragile manual code with more robust code autogenerated by the > > asn1c compiler. > > > > While working on replacing the code with the autogenerated one I > > discovered additional encoding issues of which the following ticket > > represent only the most evident: > > https://fedorahosted.org/freeipa/ticket/4728 > > > > I found numerous encoding errors which basically made the getkeytab > > control we implemented in both the client and the server not respect > > the encoding we actually defined with ASN.1 notation here: > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > While digging and testing replacement functions is also became > > evident that the getkeytab feature was only partially working and > > that the bug in 4718 was not just a minor error, but cannot ever > > work on existing servers as there are compounding bugs that would > > prevent using the getkeytab protocol to ever work if the user > > specified enctypes via ipa-getkeytab instead of just requesting the > > server's defaults. > > > > Because of this and because it was just too hard *and* useless to > > try to be compatible with existing broken clients and servers the > > new code breaks compatibility for correctness of implementation. > > > > The break in compatibility is mitigated by the fact that > > ipa-getkeytab always falls back to the old setkeytab control in > > case of error, so normal operations will not be disrupted. The only > > feature that will not work if you have a buggy client or a buggy > > server is the keytab retrieval option, as that feature is only > > available with the new control. Given we have only recently > > introduced CLI and UI to actually enable the use of the retrieval > > option and given the fact 4.x has not yet hit major distribution > > stable releases I think that this patchset is acceptable as long as > > we can land it in 4.1.2 and/or in an immediately following patch > > release (also in 4.0.x possibly) so that it can land as a zero day > > upgrade for Fedora (and an upgrade for Debian). > > > > If you have any questions, please shoot. > > > > This code is fully tested by me on top of master. I think it should > > apply directly on 4.1.2 and 4.0.x with none or minor changes. > > Patch 0001: > Typo in the commit message. Otherwise LGTM. > > Patch 0002: > I would strongly prefer that generated code live in its own directory > and static library. Then the wrapper around that code should make its > own library and link to the library for the generated code. > > Something like: > * asn1/asn1c/libasn1c.a > * asn1/libipaasn1.a Although I can see the logic, it sounds a little bit extreme to build a convenience library for a convenience library ... what's the gain ? The ipa_asn1.c code is intimately tied to the autogenerated code anyway. > Also, shouldn't the functions in ipa_asn1.[ch] get a prefix? Maybe > ipa_asn1_? uhmm maybe we should indeed. any other opinion ? > I'd love to see some function documentation in ipa_asn1.h. At the > least, this should cover allocation semantics. Yeah, I added a comment or two in the .c file but did not make it into .h file, I'll fix that. > Are there any changes in KeytabModule itself from the previous > implementation? It looks like yes. NewKeys.enctypes for instance used > to be SEQUENCE OF Int16, but is now SEQUENCE OF INTEGER. Isn't the > Kerberos enctype Int32? Why not use this? INTEGER is really all we need. > Same with GKReply.newkvno (new_kvno), KrbKey.key, KrbKey.salt, etc. > > It seems to me like you're trying to resist pulling in the Kerberos > ASN.1 module. If this is the only reason, it seems to me like we'll > probably need it eventually anyway and we can just configure the > compiler to drop the unused symbols. It would be a lot of code we do not need. I could import just the Int32 definition, but why ? INTEGER works fine for our purposes (we use system defined integers so it is limited to a 'long'). > But maybe I'm missing something. > > Why does lber.h get added to ipa_krb5.h? Aren't we trying to get rid > of lber with this patch? Because the header file uses struct berval in a function I am not touching, so it need the include to avoid compile warnings, eventually we may change things around to improve minor details, but this patch is blocking for Fedora 21 so I would like to avoid anything that is not a hard blocker. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Nov 18 18:50:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Nov 2014 19:50:29 +0100 Subject: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission In-Reply-To: <546B6B76.7010602@redhat.com> References: <546229AC.9040809@redhat.com> <5462320D.2050802@redhat.com> <546353A5.505@redhat.com> <5464AB28.5080405@redhat.com> <5464B719.9090304@redhat.com> <546B5127.7020205@redhat.com> <546B6B76.7010602@redhat.com> Message-ID: <546B94F5.5040507@redhat.com> Dne 18.11.2014 v 16:53 Martin Basti napsal(a): > On 18/11/14 15:01, Jan Cholasta wrote: >> Hi, >> >> Dne 13.11.2014 v 14:50 Martin Basti napsal(a): >>> On 13/11/14 13:59, Jan Cholasta wrote: >>>> Dne 12.11.2014 v 13:33 Martin Basti napsal(a): >>>>> On 11/11/14 16:58, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 11.11.2014 v 16:22 Martin Basti napsal(a): >>>>>>> Using specfile to create file doesn't work if named user is not on >>>>>>> system. >>>>>>> Appropriate permission have to be set during ipa-dns installation. >>>>>>> >>>>>>> Patch attached >>>>>>> >>>>>> >>>>>> Why is the directory set up in dnskeysyncinstance instead of >>>>>> bindinstance? >>>>> Because, dnskeysyncinstance is the daemon which requires permission >>>>> change. >>>>> (dir is created by dyndb-ldap plugin) >>>> >>>> OK. But please rename the method to something more suitable >>>> (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. >>>> >>>> Also please change the ticket link to >>>> (cloned from BZ). >>>> >>>>> >>>>>> >>>>>> The original patch was released with 4.1.1, shouldn't there be update >>>>>> in ipa-upgradeconfig? >>>>> Cases: >>>>> 1) fresh RPM install, no named user during RPM install -> named >>>>> doesn't >>>>> start, user had to fix it immediately, can't wait until next release. >>>>> >>>>> 2) fresh RPM install, named user -> no impact >>>>> >>>>> 3) upgrade IPA with DNS -> no impact >>>>> >>>>> 4) upgrade IPA without DNS -> after DNS installation, same as 1) >>>>> >>>>> 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 -> DNSSEC will not >>>>> work (If user doesnt use DNSSEC) >>>>> >>>>> Only 5) looks serious for me, so here is updated patch. >>>> >>>> Could you do the update without the code duplication? In similar code >>>> an appropriate *instance method is usually called. >> >> The uid/gid resolution in ipa-upgradeconfig still looks like >> duplicated code to me. I would suggest doing something along these >> lines in ipa-upgradeconfig: >> >> dnskeysync = dnskeysyncinstance.DNSKeySyncInstance() >> dnskeysync.set_dyndb_ldap_workdir_permissions() >> >> and have DNSKeySyncInstance.set_dyndb_ldap_workdir_permissions() do >> all the real work. > > Updated patch attached. > Martin^2 Thanks, ACK. Pushed to: master: 7c176b708eb855ea8774ad36ba72fd31952a8895 ipa-4-1: ba124045b9f39f8264a974c977beba6f15b1b1fb -- Jan Cholasta From jcholast at redhat.com Tue Nov 18 18:56:13 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Nov 2014 19:56:13 +0100 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 Message-ID: <546B964D.5000804@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-373-Update-Requires-on-pki-ca-to-10.2.1-0.1.patch Type: text/x-patch Size: 754 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 18 19:20:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Nov 2014 20:20:21 +0100 Subject: [Freeipa-devel] [PATCH 0165] Workaround: unable to get CA status during update Message-ID: <546B9BF5.5000902@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4676 Attached patches: * Version A: uses wget to get status of CA * Version B: write warning instead of raising exception (error is false positive, CA is running) I'm open to suggestions which approach is better Martin^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0165-A-Using-wget-to-get-status-of-CA.patch Type: text/x-patch Size: 2035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0165-B-Show-warning-instead-of-error-if-CA-did-not-start.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From pvoborni at redhat.com Tue Nov 18 19:26:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Nov 2014 20:26:30 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <54646370.1090304@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> Message-ID: <546B9D66.5010704@redhat.com> On 13.11.2014 08:53, Martin Kosek wrote: > On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: >> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: >>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>>> >>>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>>>>> how to >>>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>>>>> However, >>>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>>>>> on the >>>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>>> >>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>>>>> works >>>>>>>>>>>>> just fine. >>>>>>>>>>>> >>>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>>> attribute >>>>>>>>>>>> names. >>>>>>>>>>> >>>>>>>>>>> Thanks Nathaniel! >>>>>>>>>>> >>>>>>>>>>>> The above known issue still remains. >>>>>>>>>>> >>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>>>>> extension >>>>>>>>>>> should work just fine, AFAIK. >>>>>>>>>> >>>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>>>>> they aren't considered in the update. >>>>>>>>>> Without the blank line it works fine. >>>>>>>>> >>>>>>>>> Thanks for the catch! >>>>>>>>> >>>>>>>>> Here is a version without the blank line. >>>>>>>> >>>>>>>> I forgot to remove the old steps defines. This patch performs this >>>>>>>> cleanup. >>>>>>> >>>>>>> I am now wondering, is the global config object really the nest place to >>>>>>> add these OTP specific settings? >>>>>>> >>>>>>> I would prefer not to overload the object and instead: >>>>>>> - create new ipaOTPConfig objectclass >>>>>>> - add it to cn=otp,$SUFFIX >>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>>>>> of dnsconfig-* and trustconfig-* commands >>>>>>> >>>>>>> IMO, this would allow more flexibility for the OTP settings and would >>>>>>> also scale better for the future updates. >>>>>> >>>>>> +1 >>>>>> >>>>>> I will comment the patch as if ^^ would not exist because it will still be >>>>>> needed in the new plugin. >>>>>> >>>>>> Because of ^^ I did not test, just read. >>>>>> >>>>>> 1. Got: >>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>>>>> recommended in array initializers >>>>>> >>>>>> Please run: >>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>>> in install/ui directory >>>>>> >>>>>> The goal is no have no warnings and errors. >>>>>> >>>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>>>>> permission >>>>> >>>>> +1. Though if we go with OTP config, it should be called >>>>> >>>>> System: Read OTP Configuration >>>>> >>>>> Martin >>>> >>>> Attached is a new set of patches that replaces this single patch. This >>>> now fixes multiple issues. >>>> >>>> I now create two new entries: >>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>>> >>>> There are two corresponding CLI commands: >>>> * totpconfig-(show|mod) >>>> * hotpconfig-(show|mod) >>>> >>>> There is no UI support for this yet (pointers welcome). >>>> >>>> This is designed so that eventually tokens can grow a per-token >>>> override, but I have not yet implemented this feature (it should be easy >>>> in the future). >>>> >>>> Additionally, I had to do some shared refactoring to address issues in >>>> ipa-otp-lasttoken, which is why all of these are now merged into a >>>> single patch set. >>>> >>>> Nathaniel I'm little confused with a state of reviews. Thierry were some of the patches ACKed in different threads or are they under review (I'm not reviewing DS plugin parts)? >>>> >>> >>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want >>> to make TOTP/HOTP token config as separate entries (to enable future per-token >>> overrides), your approach should make sense. Rather adding Rob to CC for sanity. >> >> That would work too. I'm open to that. >> >>> I am just not sure we should create them as separate plugins, I think the new >>> commands should be rather added to otp plugin directly so that they show in >>> "ipa help otptoken" instead of adding 2 new topics just for OTP config. >> >> I can play with that. Do you plan to change it? I like the idea of a single point of help for OTP but I'm also unsure about the length of the commands. Current solution is also more consistent with a rest of the framework. Would it be something like: otptoken-totpconfig-(show|mod) otptoken-hotpconfig-(show|mod) Maybe it would be better to introduce more help topics for otp. This concept is used for HBAC already: $ ipa help hbac hbacsvcgroup HBAC Service Groups hbacsvc HBAC Services hbacrule Host-based access control $ ipa help hbacrule Host-based access control ... a lot of text So we could introduce otp umbrella topic: $ ipa help otp opttoken OTP tokens' totpconfig TOTP configuration options hotpconfig HOTP configuration options >> >> Nathaniel > > No worries ATM, you can wait for proper review. I was just looking at the new > API to make sure we are on the same page - we seem to mostly are. > > Martin > Commenting just patch 0004: 1. Requires rebase because of API change. 2. git diff HEAD~4 -U0 | pep8 --diff I would ignore E124 and fix E302 (5x) I did not test actual functionality yet. -- Petr Vobornik From npmccallum at redhat.com Tue Nov 18 19:28:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 14:28:08 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118124044.06089fda@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> Message-ID: <1416338888.3141.27.camel@redhat.com> On Tue, 2014-11-18 at 12:40 -0500, Simo Sorce wrote: > On Tue, 18 Nov 2014 11:23:42 -0500 > Nathaniel McCallum wrote: > > > On Tue, 2014-11-18 at 00:01 -0500, Simo Sorce wrote: > > > Hello team, > > > > > > Recently Alexander opened the following bug: > > > https://fedorahosted.org/freeipa/ticket/4718 > > > > > > The problem with this code is that manual ASN.1 encoding is fragile > > > and too prone to error, and I found various issues while > > > investigating the bug. So I decided to give a shot at replacing the > > > fragile manual code with more robust code autogenerated by the > > > asn1c compiler. > > > > > > While working on replacing the code with the autogenerated one I > > > discovered additional encoding issues of which the following ticket > > > represent only the most evident: > > > https://fedorahosted.org/freeipa/ticket/4728 > > > > > > I found numerous encoding errors which basically made the getkeytab > > > control we implemented in both the client and the server not respect > > > the encoding we actually defined with ASN.1 notation here: > > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > > > While digging and testing replacement functions is also became > > > evident that the getkeytab feature was only partially working and > > > that the bug in 4718 was not just a minor error, but cannot ever > > > work on existing servers as there are compounding bugs that would > > > prevent using the getkeytab protocol to ever work if the user > > > specified enctypes via ipa-getkeytab instead of just requesting the > > > server's defaults. > > > > > > Because of this and because it was just too hard *and* useless to > > > try to be compatible with existing broken clients and servers the > > > new code breaks compatibility for correctness of implementation. > > > > > > The break in compatibility is mitigated by the fact that > > > ipa-getkeytab always falls back to the old setkeytab control in > > > case of error, so normal operations will not be disrupted. The only > > > feature that will not work if you have a buggy client or a buggy > > > server is the keytab retrieval option, as that feature is only > > > available with the new control. Given we have only recently > > > introduced CLI and UI to actually enable the use of the retrieval > > > option and given the fact 4.x has not yet hit major distribution > > > stable releases I think that this patchset is acceptable as long as > > > we can land it in 4.1.2 and/or in an immediately following patch > > > release (also in 4.0.x possibly) so that it can land as a zero day > > > upgrade for Fedora (and an upgrade for Debian). > > > > > > If you have any questions, please shoot. > > > > > > This code is fully tested by me on top of master. I think it should > > > apply directly on 4.1.2 and 4.0.x with none or minor changes. > > > > Patch 0001: > > Typo in the commit message. Otherwise LGTM. > > > > Patch 0002: > > I would strongly prefer that generated code live in its own directory > > and static library. Then the wrapper around that code should make its > > own library and link to the library for the generated code. > > > > Something like: > > * asn1/asn1c/libasn1c.a > > * asn1/libipaasn1.a > > Although I can see the logic, it sounds a little bit extreme to build a > convenience library for a convenience library ... what's the gain ? > The ipa_asn1.c code is intimately tied to the autogenerated code anyway. Moving the files to a new directory and creating a new libtool library can hardly be called "extreme." It would probably take 5 minutes of work. It probably took you longer to respond to this email. :) I think it adds a great deal of readability to a new programmer approaching this code. And that, for me, is worth it. > > Also, shouldn't the functions in ipa_asn1.[ch] get a prefix? Maybe > > ipa_asn1_? > > uhmm maybe we should indeed. > any other opinion ? > > > I'd love to see some function documentation in ipa_asn1.h. At the > > least, this should cover allocation semantics. > > Yeah, I added a comment or two in the .c file but did not make it > into .h file, I'll fix that. > > > Are there any changes in KeytabModule itself from the previous > > implementation? It looks like yes. NewKeys.enctypes for instance used > > to be SEQUENCE OF Int16, but is now SEQUENCE OF INTEGER. Isn't the > > Kerberos enctype Int32? Why not use this? > > INTEGER is really all we need. > > > Same with GKReply.newkvno (new_kvno), KrbKey.key, KrbKey.salt, etc. > > > > It seems to me like you're trying to resist pulling in the Kerberos > > ASN.1 module. If this is the only reason, it seems to me like we'll > > probably need it eventually anyway and we can just configure the > > compiler to drop the unused symbols. > > It would be a lot of code we do not need. That would be automatically generated once and probably never touched again. > I could import just the Int32 definition, but why ? > INTEGER works fine for our purposes (we use system defined integers so > it is limited to a 'long'). It works and is easier, at the expense of readability (and perhaps some subtle bugs later for the other types). It really just seems odd to me to define a protocol for transferring Kerberos types while avoiding the use of Kerberos types solely to avoid automatically generating some code. > > But maybe I'm missing something. > > > > Why does lber.h get added to ipa_krb5.h? Aren't we trying to get rid > > of lber with this patch? > > Because the header file uses struct berval in a function I am not > touching, so it need the include to avoid compile warnings, eventually > we may change things around to improve minor details, but this patch is > blocking for Fedora 21 so I would like to avoid anything that is not a > hard blocker. Makes sense. This was mostly just a curious oddity. Nathaniel From simo at redhat.com Tue Nov 18 19:45:15 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 14:45:15 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <1416338888.3141.27.camel@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> Message-ID: <20141118144515.1e7e5d6a@willson.usersys.redhat.com> On Tue, 18 Nov 2014 14:28:08 -0500 Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 12:40 -0500, Simo Sorce wrote: > > On Tue, 18 Nov 2014 11:23:42 -0500 > > Nathaniel McCallum wrote: > > > > > On Tue, 2014-11-18 at 00:01 -0500, Simo Sorce wrote: > > > > Hello team, > > > > > > > > Recently Alexander opened the following bug: > > > > https://fedorahosted.org/freeipa/ticket/4718 > > > > > > > > The problem with this code is that manual ASN.1 encoding is > > > > fragile and too prone to error, and I found various issues while > > > > investigating the bug. So I decided to give a shot at replacing > > > > the fragile manual code with more robust code autogenerated by > > > > the asn1c compiler. > > > > > > > > While working on replacing the code with the autogenerated one I > > > > discovered additional encoding issues of which the following > > > > ticket represent only the most evident: > > > > https://fedorahosted.org/freeipa/ticket/4728 > > > > > > > > I found numerous encoding errors which basically made the > > > > getkeytab control we implemented in both the client and the > > > > server not respect the encoding we actually defined with ASN.1 > > > > notation here: http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > > > > > While digging and testing replacement functions is also became > > > > evident that the getkeytab feature was only partially working > > > > and that the bug in 4718 was not just a minor error, but cannot > > > > ever work on existing servers as there are compounding bugs > > > > that would prevent using the getkeytab protocol to ever work if > > > > the user specified enctypes via ipa-getkeytab instead of just > > > > requesting the server's defaults. > > > > > > > > Because of this and because it was just too hard *and* useless > > > > to try to be compatible with existing broken clients and > > > > servers the new code breaks compatibility for correctness of > > > > implementation. > > > > > > > > The break in compatibility is mitigated by the fact that > > > > ipa-getkeytab always falls back to the old setkeytab control in > > > > case of error, so normal operations will not be disrupted. The > > > > only feature that will not work if you have a buggy client or a > > > > buggy server is the keytab retrieval option, as that feature is > > > > only available with the new control. Given we have only recently > > > > introduced CLI and UI to actually enable the use of the > > > > retrieval option and given the fact 4.x has not yet hit major > > > > distribution stable releases I think that this patchset is > > > > acceptable as long as we can land it in 4.1.2 and/or in an > > > > immediately following patch release (also in 4.0.x possibly) so > > > > that it can land as a zero day upgrade for Fedora (and an > > > > upgrade for Debian). > > > > > > > > If you have any questions, please shoot. > > > > > > > > This code is fully tested by me on top of master. I think it > > > > should apply directly on 4.1.2 and 4.0.x with none or minor > > > > changes. > > > > > > Patch 0001: > > > Typo in the commit message. Otherwise LGTM. > > > > > > Patch 0002: > > > I would strongly prefer that generated code live in its own > > > directory and static library. Then the wrapper around that code > > > should make its own library and link to the library for the > > > generated code. > > > > > > Something like: > > > * asn1/asn1c/libasn1c.a > > > * asn1/libipaasn1.a > > > > Although I can see the logic, it sounds a little bit extreme to > > build a convenience library for a convenience library ... what's > > the gain ? The ipa_asn1.c code is intimately tied to the > > autogenerated code anyway. > > Moving the files to a new directory and creating a new libtool library > can hardly be called "extreme." It would probably take 5 minutes of > work. It probably took you longer to respond to this email. :) > > I think it adds a great deal of readability to a new programmer > approaching this code. And that, for me, is worth it. Ok, it's not the work that is extreme, it is just the additional layering that is a bit silly imo, as the asn1/libipaasn1.a would just be a very thin wrapper, the generated Makefile will probably be bigger then the wrapper it compiles :) but ok. > > > Also, shouldn't the functions in ipa_asn1.[ch] get a prefix? Maybe > > > ipa_asn1_? > > > > uhmm maybe we should indeed. > > any other opinion ? > > > > > I'd love to see some function documentation in ipa_asn1.h. At the > > > least, this should cover allocation semantics. > > > > Yeah, I added a comment or two in the .c file but did not make it > > into .h file, I'll fix that. > > > > > Are there any changes in KeytabModule itself from the previous > > > implementation? It looks like yes. NewKeys.enctypes for instance > > > used to be SEQUENCE OF Int16, but is now SEQUENCE OF INTEGER. > > > Isn't the Kerberos enctype Int32? Why not use this? > > > > INTEGER is really all we need. > > > > > Same with GKReply.newkvno (new_kvno), KrbKey.key, KrbKey.salt, > > > etc. > > > > > > It seems to me like you're trying to resist pulling in the > > > Kerberos ASN.1 module. If this is the only reason, it seems to me > > > like we'll probably need it eventually anyway and we can just > > > configure the compiler to drop the unused symbols. > > > > It would be a lot of code we do not need. > > That would be automatically generated once and probably never touched > again. > > > I could import just the Int32 definition, but why ? > > INTEGER works fine for our purposes (we use system defined integers > > so it is limited to a 'long'). > > It works and is easier, at the expense of readability (and perhaps > some subtle bugs later for the other types). It really just seems odd > to me to define a protocol for transferring Kerberos types while > avoiding the use of Kerberos types solely to avoid automatically > generating some code. Ok I'll take a stab at it now. > > > But maybe I'm missing something. > > > > > > Why does lber.h get added to ipa_krb5.h? Aren't we trying to get > > > rid of lber with this patch? > > > > Because the header file uses struct berval in a function I am not > > touching, so it need the include to avoid compile warnings, > > eventually we may change things around to improve minor details, > > but this patch is blocking for Fedora 21 so I would like to avoid > > anything that is not a hard blocker. > > Makes sense. This was mostly just a curious oddity. The irony did not escape me when I had to make the change, and was actually expecting a question about it during review :) Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Nov 18 20:01:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 15:01:15 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118144515.1e7e5d6a@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> Message-ID: <1416340875.3141.31.camel@redhat.com> On Tue, 2014-11-18 at 14:45 -0500, Simo Sorce wrote: > On Tue, 18 Nov 2014 14:28:08 -0500 > Nathaniel McCallum wrote: > > > On Tue, 2014-11-18 at 12:40 -0500, Simo Sorce wrote: > > > On Tue, 18 Nov 2014 11:23:42 -0500 > > > Nathaniel McCallum wrote: > > > > > > > On Tue, 2014-11-18 at 00:01 -0500, Simo Sorce wrote: > > > > > Hello team, > > > > > > > > > > Recently Alexander opened the following bug: > > > > > https://fedorahosted.org/freeipa/ticket/4718 > > > > > > > > > > The problem with this code is that manual ASN.1 encoding is > > > > > fragile and too prone to error, and I found various issues while > > > > > investigating the bug. So I decided to give a shot at replacing > > > > > the fragile manual code with more robust code autogenerated by > > > > > the asn1c compiler. > > > > > > > > > > While working on replacing the code with the autogenerated one I > > > > > discovered additional encoding issues of which the following > > > > > ticket represent only the most evident: > > > > > https://fedorahosted.org/freeipa/ticket/4728 > > > > > > > > > > I found numerous encoding errors which basically made the > > > > > getkeytab control we implemented in both the client and the > > > > > server not respect the encoding we actually defined with ASN.1 > > > > > notation here: http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > > > > > > > While digging and testing replacement functions is also became > > > > > evident that the getkeytab feature was only partially working > > > > > and that the bug in 4718 was not just a minor error, but cannot > > > > > ever work on existing servers as there are compounding bugs > > > > > that would prevent using the getkeytab protocol to ever work if > > > > > the user specified enctypes via ipa-getkeytab instead of just > > > > > requesting the server's defaults. > > > > > > > > > > Because of this and because it was just too hard *and* useless > > > > > to try to be compatible with existing broken clients and > > > > > servers the new code breaks compatibility for correctness of > > > > > implementation. > > > > > > > > > > The break in compatibility is mitigated by the fact that > > > > > ipa-getkeytab always falls back to the old setkeytab control in > > > > > case of error, so normal operations will not be disrupted. The > > > > > only feature that will not work if you have a buggy client or a > > > > > buggy server is the keytab retrieval option, as that feature is > > > > > only available with the new control. Given we have only recently > > > > > introduced CLI and UI to actually enable the use of the > > > > > retrieval option and given the fact 4.x has not yet hit major > > > > > distribution stable releases I think that this patchset is > > > > > acceptable as long as we can land it in 4.1.2 and/or in an > > > > > immediately following patch release (also in 4.0.x possibly) so > > > > > that it can land as a zero day upgrade for Fedora (and an > > > > > upgrade for Debian). > > > > > > > > > > If you have any questions, please shoot. > > > > > > > > > > This code is fully tested by me on top of master. I think it > > > > > should apply directly on 4.1.2 and 4.0.x with none or minor > > > > > changes. > > > > > > > > Patch 0001: > > > > Typo in the commit message. Otherwise LGTM. > > > > > > > > Patch 0002: > > > > I would strongly prefer that generated code live in its own > > > > directory and static library. Then the wrapper around that code > > > > should make its own library and link to the library for the > > > > generated code. > > > > > > > > Something like: > > > > * asn1/asn1c/libasn1c.a > > > > * asn1/libipaasn1.a > > > > > > Although I can see the logic, it sounds a little bit extreme to > > > build a convenience library for a convenience library ... what's > > > the gain ? The ipa_asn1.c code is intimately tied to the > > > autogenerated code anyway. > > > > Moving the files to a new directory and creating a new libtool library > > can hardly be called "extreme." It would probably take 5 minutes of > > work. It probably took you longer to respond to this email. :) > > > > I think it adds a great deal of readability to a new programmer > > approaching this code. And that, for me, is worth it. > > Ok, it's not the work that is extreme, it is just the additional > layering that is a bit silly imo, as the asn1/libipaasn1.a would just > be a very thin wrapper, the generated Makefile will probably be bigger > then the wrapper it compiles :) > but ok. As I see it, we're setting out a new precedent. All new ASN.1 code will take this route (which is, indeed, better). So while it is small now, it won't stay small forever. Being that we are in the business of routinely handling ASN.1 stuff, this seems to me like a sensible architecture for the future. > > > > Also, shouldn't the functions in ipa_asn1.[ch] get a prefix? Maybe > > > > ipa_asn1_? > > > > > > uhmm maybe we should indeed. > > > any other opinion ? > > > > > > > I'd love to see some function documentation in ipa_asn1.h. At the > > > > least, this should cover allocation semantics. > > > > > > Yeah, I added a comment or two in the .c file but did not make it > > > into .h file, I'll fix that. > > > > > > > Are there any changes in KeytabModule itself from the previous > > > > implementation? It looks like yes. NewKeys.enctypes for instance > > > > used to be SEQUENCE OF Int16, but is now SEQUENCE OF INTEGER. > > > > Isn't the Kerberos enctype Int32? Why not use this? > > > > > > INTEGER is really all we need. > > > > > > > Same with GKReply.newkvno (new_kvno), KrbKey.key, KrbKey.salt, > > > > etc. > > > > > > > > It seems to me like you're trying to resist pulling in the > > > > Kerberos ASN.1 module. If this is the only reason, it seems to me > > > > like we'll probably need it eventually anyway and we can just > > > > configure the compiler to drop the unused symbols. > > > > > > It would be a lot of code we do not need. > > > > That would be automatically generated once and probably never touched > > again. > > > > > I could import just the Int32 definition, but why ? > > > INTEGER works fine for our purposes (we use system defined integers > > > so it is limited to a 'long'). > > > > It works and is easier, at the expense of readability (and perhaps > > some subtle bugs later for the other types). It really just seems odd > > to me to define a protocol for transferring Kerberos types while > > avoiding the use of Kerberos types solely to avoid automatically > > generating some code. > > Ok I'll take a stab at it now. > > > > > But maybe I'm missing something. > > > > > > > > Why does lber.h get added to ipa_krb5.h? Aren't we trying to get > > > > rid of lber with this patch? > > > > > > Because the header file uses struct berval in a function I am not > > > touching, so it need the include to avoid compile warnings, > > > eventually we may change things around to improve minor details, > > > but this patch is blocking for Fedora 21 so I would like to avoid > > > anything that is not a hard blocker. > > > > Makes sense. This was mostly just a curious oddity. > > The irony did not escape me when I had to make the change, and was > actually expecting a question about it during review :) > > Simo. > From simo at redhat.com Tue Nov 18 20:25:31 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 15:25:31 -0500 Subject: [Freeipa-devel] [PATCH] Improve developers RPM builds In-Reply-To: <1416327919.3141.18.camel@redhat.com> References: <20141117234224.5095d1ee@willson.usersys.redhat.com> <1416327919.3141.18.camel@redhat.com> Message-ID: <20141118152531.20f2f434@willson.usersys.redhat.com> On Tue, 18 Nov 2014 11:25:19 -0500 Nathaniel McCallum wrote: > On Mon, 2014-11-17 at 23:42 -0500, Simo Sorce wrote: > > This small patch will add a date component to the ipa version when > > building straight from git. > > > > This way successive builds will clearly install on top of a previous > > one even if alphabetically the git commit id has gone backwards. > > > > It also gives a chance of remembering what/when you had installed on > > older VMs at a simply rpm -qi glance. > > ACK > > And thank you! This has been bugging me. > > Nathaniel > I added your reviewed-by and pushed it to master. Do people want to push it to other branches ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Nov 18 20:46:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Nov 2014 21:46:00 +0100 Subject: [Freeipa-devel] [PATCH] Improve developers RPM builds In-Reply-To: <20141118152531.20f2f434@willson.usersys.redhat.com> References: <20141117234224.5095d1ee@willson.usersys.redhat.com> <1416327919.3141.18.camel@redhat.com> <20141118152531.20f2f434@willson.usersys.redhat.com> Message-ID: <546BB008.6090800@redhat.com> On 11/18/2014 09:25 PM, Simo Sorce wrote: > On Tue, 18 Nov 2014 11:25:19 -0500 > Nathaniel McCallum wrote: > >> On Mon, 2014-11-17 at 23:42 -0500, Simo Sorce wrote: >>> This small patch will add a date component to the ipa version when >>> building straight from git. >>> >>> This way successive builds will clearly install on top of a previous >>> one even if alphabetically the git commit id has gone backwards. >>> >>> It also gives a chance of remembering what/when you had installed on >>> older VMs at a simply rpm -qi glance. >> >> ACK >> >> And thank you! This has been bugging me. >> >> Nathaniel >> > > I added your reviewed-by and pushed it to master. > > Do people want to push it to other branches ? > > Simo. > It should be harmless for release builds and should help development builds. So +1 for adding to all actively developed branches, i.e. ipa-4-1 and ipa-4-0. Thanks, Martin From mkosek at redhat.com Tue Nov 18 21:01:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Nov 2014 22:01:39 +0100 Subject: [Freeipa-devel] [PATCH 0165] Workaround: unable to get CA status during update In-Reply-To: <546B9BF5.5000902@redhat.com> References: <546B9BF5.5000902@redhat.com> Message-ID: <546BB3B3.4040805@redhat.com> On 11/18/2014 08:20 PM, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4676 > > Attached patches: > > * Version A: uses wget to get status of CA > * Version B: write warning instead of raising exception (error is false > positive, CA is running) > > I'm open to suggestions which approach is better > > Martin^2 > I like A, but I am concerned why you suddenly ignore the use_proxy option. I added it for a reason as it affects to which port we need to connect, regardless the transport library. See https://fedorahosted.org/freeipa/ticket/3973 where I added this option. Second, I am not happy by you duplicating the XML parsing code, I would rather see it splited in dogtag.py in separate "_ca_status_parse" or similar function call. Given the obstacles, I am inclining for - pushing B as a safe fix for Fedora 21 Final - fixing issues in A and pushing it for minor release after that to avoid the nasty warning and have some reasonable medium-term fix until the framework migrates to something better than httpslib, line python-requests maybe. Martin From npmccallum at redhat.com Tue Nov 18 22:29:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 17:29:04 -0500 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <546B964D.5000804@redhat.com> References: <546B964D.5000804@redhat.com> Message-ID: <1416349744.3141.32.camel@redhat.com> On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: > Hi, > > the attached patch fixes . ACK From simo at redhat.com Tue Nov 18 22:58:31 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 17:58:31 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <1416340875.3141.31.camel@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> Message-ID: <20141118175831.28d8cfc3@willson.usersys.redhat.com> On Tue, 18 Nov 2014 15:01:15 -0500 Nathaniel McCallum wrote: > As I see it, we're setting out a new precedent. All new ASN.1 code > will take this route (which is, indeed, better). So while it is small > now, it won't stay small forever. Being that we are in the business > of routinely handling ASN.1 stuff, this seems to me like a sensible > architecture for the future. Ok, I think I should have fixed all the issues you brought up. And my tests still work fine :) Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-filtering-of-enctypes-in-server-code.patch Type: text/x-patch Size: 3565 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-asn1c-generated-code-for-keytab-controls.patch Type: text/x-patch Size: 371303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Use-asn1c-helpers-to-encode-decode-the-getkeytab-con.patch Type: text/x-patch Size: 25801 bytes Desc: not available URL: From npmccallum at redhat.com Tue Nov 18 23:00:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 18 Nov 2014 18:00:49 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118175831.28d8cfc3@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> Message-ID: <1416351649.3141.33.camel@redhat.com> On Tue, 2014-11-18 at 17:58 -0500, Simo Sorce wrote: > On Tue, 18 Nov 2014 15:01:15 -0500 > Nathaniel McCallum wrote: > > > As I see it, we're setting out a new precedent. All new ASN.1 code > > will take this route (which is, indeed, better). So while it is small > > now, it won't stay small forever. Being that we are in the business > > of routinely handling ASN.1 stuff, this seems to me like a sensible > > architecture for the future. > > Ok, I think I should have fixed all the issues you brought up. Still have a typo ("wuld") in the commit message of the first patch. :) > And my tests still work fine :) > > Simo. > From simo at redhat.com Tue Nov 18 23:01:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 18:01:02 -0500 Subject: [Freeipa-devel] [PATCH] Improve developers RPM builds In-Reply-To: <546BB008.6090800@redhat.com> References: <20141117234224.5095d1ee@willson.usersys.redhat.com> <1416327919.3141.18.camel@redhat.com> <20141118152531.20f2f434@willson.usersys.redhat.com> <546BB008.6090800@redhat.com> Message-ID: <20141118180102.4054f850@willson.usersys.redhat.com> On Tue, 18 Nov 2014 21:46:00 +0100 Martin Kosek wrote: > On 11/18/2014 09:25 PM, Simo Sorce wrote: > > On Tue, 18 Nov 2014 11:25:19 -0500 > > Nathaniel McCallum wrote: > > > >> On Mon, 2014-11-17 at 23:42 -0500, Simo Sorce wrote: > >>> This small patch will add a date component to the ipa version when > >>> building straight from git. > >>> > >>> This way successive builds will clearly install on top of a > >>> previous one even if alphabetically the git commit id has gone > >>> backwards. > >>> > >>> It also gives a chance of remembering what/when you had installed > >>> on older VMs at a simply rpm -qi glance. > >> > >> ACK > >> > >> And thank you! This has been bugging me. > >> > >> Nathaniel > >> > > > > I added your reviewed-by and pushed it to master. > > > > Do people want to push it to other branches ? > > > > Simo. > > > > It should be harmless for release builds and should help development > builds. So +1 for adding to all actively developed branches, i.e. > ipa-4-1 and ipa-4-0. Ok, pushed there too. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Nov 19 01:39:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 18 Nov 2014 20:39:02 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <1416351649.3141.33.camel@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <1416351649.3141.33.camel@redhat.com> Message-ID: <20141118203902.76d79199@willson.usersys.redhat.com> On Tue, 18 Nov 2014 18:00:49 -0500 Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 17:58 -0500, Simo Sorce wrote: > > On Tue, 18 Nov 2014 15:01:15 -0500 > > Nathaniel McCallum wrote: > > > > > As I see it, we're setting out a new precedent. All new ASN.1 code > > > will take this route (which is, indeed, better). So while it is > > > small now, it won't stay small forever. Being that we are in the > > > business of routinely handling ASN.1 stuff, this seems to me like > > > a sensible architecture for the future. > > > > Ok, I think I should have fixed all the issues you brought up. > > Still have a typo ("wuld") in the commit message of the first > patch. :) I think I can fix it before pushing if that's the only issue ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Nov 19 05:51:33 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 19 Nov 2014 00:51:33 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118203902.76d79199@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <1416351649.3141.33.camel@redhat.com> <20141118203902.76d79199@willson.usersys.redhat.com> Message-ID: <1416376293.3141.43.camel@redhat.com> On Tue, 2014-11-18 at 20:39 -0500, Simo Sorce wrote: > On Tue, 18 Nov 2014 18:00:49 -0500 > Nathaniel McCallum wrote: > > > On Tue, 2014-11-18 at 17:58 -0500, Simo Sorce wrote: > > > On Tue, 18 Nov 2014 15:01:15 -0500 > > > Nathaniel McCallum wrote: > > > > > > > As I see it, we're setting out a new precedent. All new ASN.1 code > > > > will take this route (which is, indeed, better). So while it is > > > > small now, it won't stay small forever. Being that we are in the > > > > business of routinely handling ASN.1 stuff, this seems to me like > > > > a sensible architecture for the future. > > > > > > Ok, I think I should have fixed all the issues you brought up. > > > > Still have a typo ("wuld") in the commit message of the first > > patch. :) > > I think I can fix it before pushing if that's the only issue ? I'll do a more thorough review tomorrow. I haven't even looked at the third patch yet. Nathaniel From jcholast at redhat.com Wed Nov 19 07:32:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 08:32:51 +0100 Subject: [Freeipa-devel] [PATCH] 374 Fix wrong expiration date on renewed IPA CA certificates Message-ID: <546C47A3.4030803@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-374-Fix-wrong-expiration-date-on-renewed-IPA-CA-certific.patch Type: text/x-patch Size: 1848 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 19 09:17:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Nov 2014 10:17:03 +0100 Subject: [Freeipa-devel] [PATCH 0166] Workaround: warning if CA did not start at end of upgrade instead of raising error In-Reply-To: <546BB3B3.4040805@redhat.com> References: <546B9BF5.5000902@redhat.com> <546BB3B3.4040805@redhat.com> Message-ID: <546C600F.6070806@redhat.com> On 18/11/14 22:01, Martin Kosek wrote: > On 11/18/2014 08:20 PM, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >> >> Attached patches: >> >> * Version A: uses wget to get status of CA >> * Version B: write warning instead of raising exception (error is false >> positive, CA is running) >> >> I'm open to suggestions which approach is better >> >> Martin^2 >> > > I like A, but I am concerned why you suddenly ignore the use_proxy > option. I added it for a reason as it affects to which port we need to > connect, regardless the transport library. See > > https://fedorahosted.org/freeipa/ticket/3973 > > where I added this option. > > Second, I am not happy by you duplicating the XML parsing code, I > would rather see it splited in dogtag.py in separate > "_ca_status_parse" or similar function call. > > Given the obstacles, I am inclining for > - pushing B as a safe fix for Fedora 21 Final > - fixing issues in A and pushing it for minor release after that to > avoid the nasty warning and have some reasonable medium-term fix until > the framework migrates to something better than httpslib, line > python-requests maybe. > > Martin Sounds good to me. Patch required for F21 attached. (with proper number) I will send the second patch after release for fedora (or should I sooner?) Martin^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0166-Show-warning-instead-of-error-if-CA-did-not-start.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From abokovoy at redhat.com Wed Nov 19 10:53:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Nov 2014 12:53:01 +0200 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141118175831.28d8cfc3@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> Message-ID: <20141119105301.GY3493@redhat.com> On Tue, 18 Nov 2014, Simo Sorce wrote: >On Tue, 18 Nov 2014 15:01:15 -0500 >Nathaniel McCallum wrote: > >> As I see it, we're setting out a new precedent. All new ASN.1 code >> will take this route (which is, indeed, better). So while it is small >> now, it won't stay small forever. Being that we are in the business >> of routinely handling ASN.1 stuff, this seems to me like a sensible >> architecture for the future. > >Ok, I think I should have fixed all the issues you brought up. > >And my tests still work fine :) Works fine. However, I'm getting wrong TGT enctype back from the KDC when I try to obtain TGT with des-cbc-crc key: [root at master ~]# ipa host-add --force f21test.f21.test ----------------------------- Added host "f21test.f21.test" ----------------------------- Host name: f21test.f21.test Principal name: host/f21test.f21.test at F21.TEST Password: False Keytab: False Managed by: f21test.f21.test [root at master ~]# ipa service-add --force afs/f21test ------------------------------------ Added service "afs/f21test at F21.TEST" ------------------------------------ Principal: afs/f21test at F21.TEST Managed by: f21test.f21.test [root at master ~]# ipa-getkeytab -s `hostname` -p afs/f21test -k /tmp/afs.keytab -e des-cbc-crc:v4 -P New Principal Password: Verify Principal Password: Keytab successfully retrieved and stored in: /tmp/afs.keytab [root at master ~]# klist -kt /tmp/afs.keytab -K -e Keytab name: FILE:/tmp/afs.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 1 11/19/14 12:13:01 afs/f21test at F21.TEST (des-cbc-crc) (0xea1a0b29152cb383) [root at master ~]# KRB5_TRACE=/dev/stderr KRB5CCNAME=/tmp/afs.ccache kinit -kt /tmp/afs.keytab afs/f21test [28636] 1416392072.862773: Getting initial credentials for afs/f21test at F21.TEST [28636] 1416392072.864408: Looked up etypes in keytab: des-cbc-crc [28636] 1416392072.864522: Sending request (175 bytes) to F21.TEST [28636] 1416392072.865127: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.866958: Received answer (283 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.867028: Response was from master KDC [28636] 1416392072.867088: Received error from KDC: -1765328359/Additional pre-authentication required [28636] 1416392072.867140: Processing preauth types: 136, 19, 2, 133 [28636] 1416392072.867175: Selected etype info: etype des-cbc-crc, salt "F21.TESTafsf21test", params "" [28636] 1416392072.867193: Received cookie: MIT [28636] 1416392072.867234: Retrieving afs/f21test at F21.TEST from FILE:/tmp/afs.keytab (vno 0, enctype des-cbc-crc) with result: 0/Success [28636] 1416392072.867264: AS key obtained for encrypted timestamp: des-cbc-crc/0BE8 [28636] 1416392072.867304: Encrypted timestamp (for 1416392072.867050): plain 301AA011180F32303134313131393130313433325AA10502030D3AEA, encrypted 1C567557D395C0639CB417EE90C08CD41E4829D910166D62ACEDCC2168C23BAD8C70DFE4CD533A81 [28636] 1416392072.867331: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [28636] 1416392072.867349: Produced preauth for next request: 133, 2 [28636] 1416392072.867372: Sending request (252 bytes) to F21.TEST [28636] 1416392072.867416: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.946260: Received answer (649 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.946391: Response was from master KDC [28636] 1416392072.946485: Processing preauth types: 19 [28636] 1416392072.946542: Selected etype info: etype des-cbc-crc, salt "F21.TESTafsf21test", params "" [28636] 1416392072.946593: Produced preauth for next request: (empty) [28636] 1416392072.946626: AS key determined by preauth: des-cbc-crc/0BE8 [28636] 1416392072.946688: Decrypted AS reply; session key is: des-cbc-crc/9B41 [28636] 1416392072.946727: FAST negotiation: available [28636] 1416392072.946793: Initializing FILE:/tmp/afs.ccache with default princ afs/f21test at F21.TEST [28636] 1416392072.947118: Removing afs/f21test at F21.TEST -> krbtgt/F21.TEST at F21.TEST from FILE:/tmp/afs.ccache [28636] 1416392072.947146: Storing afs/f21test at F21.TEST -> krbtgt/F21.TEST at F21.TEST in FILE:/tmp/afs.ccache [28636] 1416392072.947187: Storing config in FILE:/tmp/afs.ccache for krbtgt/F21.TEST at F21.TEST: fast_avail: yes [28636] 1416392072.947219: Removing afs/f21test at F21.TEST -> krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: from FILE:/tmp/afs.ccache [28636] 1416392072.947240: Storing afs/f21test at F21.TEST -> krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: in FILE:/tmp/afs.ccache [28636] 1416392072.947419: Storing config in FILE:/tmp/afs.ccache for krbtgt/F21.TEST at F21.TEST: pa_type: 2 [28636] 1416392072.947458: Removing afs/f21test at F21.TEST -> krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: from FILE:/tmp/afs.ccache [28636] 1416392072.947480: Storing afs/f21test at F21.TEST -> krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: in FILE:/tmp/afs.ccache [root at master ~]# KRB5_TRACE=/dev/stderr KRB5CCNAME=/tmp/afs.ccache klist -edf Ticket cache: FILE:/tmp/afs.ccache Default principal: afs/f21test at F21.TEST Valid starting Expires Service principal 11/19/14 12:14:32 11/20/14 12:14:32 krbtgt/F21.TEST at F21.TEST Flags: FIA, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96 KDC logs show this: Nov 19 12:25:57 master.f21.test krb5kdc[28713](info): AS_REQ (9 etypes {1 18 17 16 23 25 26 3 2}) 192.168.5.169: NEEDED_PREAUTH: afs/f21test at F21.TEST for krbtgt/F21.TEST at F21.TEST, Additional pre-authentication required Nov 19 12:25:57 master.f21.test krb5kdc[28713](info): AS_REQ (9 etypes {1 18 17 16 23 25 26 3 2}) 192.168.5.169: ISSUE: authtime 1416392757, etypes {rep=1 tkt=18 ses=1}, afs/f21test at F21.TEST for krbtgt/F21.TEST at F21.TEST My /etc/krb5.conf has [libdefaults] allow_weak_crypto = true permitted_enctypes = DEFAULT +des supported_enctypes = DEFAULT +des We can handle weak types' response TGT after F21 release, this is certainly not limiting. I've tried with older ipa-getkeytab and it fell back to the pre-4.0 method as expected. Regarding the patchset itself: Patch 0001: fix 'wuld' in the commit message. The rest is fine. Patch 0002: - ticket number is missing in the commit message - perhaps, an instruction how to regenerate asn1 code can be made a Makefile target? We don't need to call it ourselves but this would simplify things in future - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to stderr but I guess this is something we currently cannot override with DS-specific log printing, so no big deal right now - any specific need to get asn1/compile committed? We don't commit it in the client code (ipa-client/compile). Patch 0003: OK -- / Alexander Bokovoy From tbabej at redhat.com Wed Nov 19 11:03:23 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Nov 2014 12:03:23 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find Message-ID: <546C78FB.8080008@redhat.com> Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0286-baseldap-Handle-missing-parent-objects-properly-in-f.patch Type: text/x-patch Size: 1523 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 19 11:24:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 12:24:41 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C78FB.8080008@redhat.com> References: <546C78FB.8080008@redhat.com> Message-ID: <546C7DF9.3040001@redhat.com> On 11/19/2014 12:03 PM, Tomas Babej wrote: > Hi, > > When constructing a parent DN in LDAPSearch, we should always > check that the parent object exists (hence use get_dn_if_exists), > rather than search on unexistant containers (which can happen > with get_dn). > > Replaces get_dn calls with get_dn_if_exists in *-find commands > and makes sure proper error message is raised. > > https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). From mkosek at redhat.com Wed Nov 19 11:37:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 12:37:50 +0100 Subject: [Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2 Message-ID: <546C810E.1040708@redhat.com> pki-core build in our Copr is finished: https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/ If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora branches. When done, I will trigger SRPM build in Copr. ---------- Current Dogtag 10.2 and it's requirements are not properly packaged for CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which has the patches required by FreeIPA backported and which has all dependencies avaiable. https://fedorahosted.org/freeipa/ticket/4737 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-486-lower-pki-ca-requires-to-10.1.2.patch Type: text/x-patch Size: 1329 bytes Desc: not available URL: From tbabej at redhat.com Wed Nov 19 11:41:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Nov 2014 12:41:39 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C7DF9.3040001@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> Message-ID: <546C81F3.8070407@redhat.com> On 11/19/2014 12:24 PM, Martin Kosek wrote: > On 11/19/2014 12:03 PM, Tomas Babej wrote: >> Hi, >> >> When constructing a parent DN in LDAPSearch, we should always >> check that the parent object exists (hence use get_dn_if_exists), >> rather than search on unexistant containers (which can happen >> with get_dn). >> >> Replaces get_dn calls with get_dn_if_exists in *-find commands >> and makes sure proper error message is raised. >> >> https://fedorahosted.org/freeipa/ticket/4659 > Doesn't it produce extra LDAP search thus making all our search commands > slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. > Wouldn't it be better to distinguish between LDAP > search with no results and LDAP search with missing parent DN? The reply looks > different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. > > # search result > search: 4 > result: 0 Success > > # search result > search: 4 > result: 32 No such object > matchedDN: cn=accounts,dc=mkosek-f20,dc=test > > Also, I do not think you can just stop using get_dn(), some commands override > this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Wed Nov 19 11:45:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 12:45:06 +0100 Subject: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI In-Reply-To: <5464D303.9070103@redhat.com> References: <5464D303.9070103@redhat.com> Message-ID: <546C82C2.3010103@redhat.com> On 13.11.2014 16:49, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4647 > Patch attached. > The change looses information about the zone apex record. User also might not know what is the message about because it lacks context. CLI option name as context is the cause of this bug but it could be replaced with, e.g., label. So what about: Semantic of setting Authoritative nameserver was changed. It's used only for setting the SOA MNAME attribute. NS record(s) can be edited in special zone apex record - '@'. -- Petr Vobornik From mkosek at redhat.com Wed Nov 19 11:51:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 12:51:29 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C81F3.8070407@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> Message-ID: <546C8441.3090407@redhat.com> On 11/19/2014 12:41 PM, Tomas Babej wrote: > > On 11/19/2014 12:24 PM, Martin Kosek wrote: >> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>> Hi, >>> >>> When constructing a parent DN in LDAPSearch, we should always >>> check that the parent object exists (hence use get_dn_if_exists), >>> rather than search on unexistant containers (which can happen >>> with get_dn). >>> >>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>> and makes sure proper error message is raised. >>> >>> https://fedorahosted.org/freeipa/ticket/4659 >> Doesn't it produce extra LDAP search thus making all our search commands >> slower? Is that what we want? > > No it does not make all of our LDAP search slower. It only happens for > the objects that have parent objects, such as idoverrides or dnsrecords. ... and makes them slower. >> Wouldn't it be better to distinguish between LDAP >> search with no results and LDAP search with missing parent DN? The reply looks >> different, at least in CLI: > Up to discussion. We would probably need to introduce a new exception, > like ParentObjectNotFound. > >> >> # search result >> search: 4 >> result: 0 Success >> >> # search result >> search: 4 >> result: 32 No such object >> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >> >> Also, I do not think you can just stop using get_dn(), some commands override >> this call to get more complex searches (like host-find searching for shortname). > Look into the get_dn_if_exists, it just wraps around get_dn, so no issue > here. Any custom behaviour is preserved. Ah, ok, thanks for info. > To sum up, I think this is worth changing this behaviour by default, > ignoring a non-matching value of the parent object is not a correct > general approach in my opinion. Well, that's the question. Whether we would leave DS to validate the search itself or do all the pre-check ourselves. To me, doing just one LDAP search and processing the error correctly looks better. But I can live even with your version then, I will leave the framework guardians like Honza or Petr3 to decide. Martin From abokovoy at redhat.com Wed Nov 19 11:52:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Nov 2014 13:52:00 +0200 Subject: [Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2 In-Reply-To: <546C810E.1040708@redhat.com> References: <546C810E.1040708@redhat.com> Message-ID: <20141119115200.GZ3493@redhat.com> On Wed, 19 Nov 2014, Martin Kosek wrote: >pki-core build in our Copr is finished: > >https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/ > >If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora >branches. When done, I will trigger SRPM build in Copr. > >---------- > >Current Dogtag 10.2 and it's requirements are not properly packaged for >CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the >Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which >has the patches required by FreeIPA backported and which has all >dependencies avaiable. > >https://fedorahosted.org/freeipa/ticket/4737 > ACK. -- / Alexander Bokovoy From mkosek at redhat.com Wed Nov 19 12:00:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 13:00:42 +0100 Subject: [Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2 In-Reply-To: <20141119115200.GZ3493@redhat.com> References: <546C810E.1040708@redhat.com> <20141119115200.GZ3493@redhat.com> Message-ID: <546C866A.8020403@redhat.com> On 11/19/2014 12:52 PM, Alexander Bokovoy wrote: > On Wed, 19 Nov 2014, Martin Kosek wrote: >> pki-core build in our Copr is finished: >> >> https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/ >> >> If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora >> branches. When done, I will trigger SRPM build in Copr. >> >> ---------- >> >> Current Dogtag 10.2 and it's requirements are not properly packaged for >> CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the >> Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which >> has the patches required by FreeIPA backported and which has all >> dependencies avaiable. >> >> https://fedorahosted.org/freeipa/ticket/4737 >> > ACK. > Pushed to ipa-4-1, F21+, Copr build triggered. Martin From tbabej at redhat.com Wed Nov 19 12:11:03 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Nov 2014 13:11:03 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <5465C391.7030003@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> <5465C391.7030003@redhat.com> Message-ID: <546C88D7.5040504@redhat.com> On 11/14/2014 09:55 AM, Petr Viktorin wrote: > On 10/29/2014 04:52 PM, Petr Viktorin wrote: >> On 10/29/2014 01:22 PM, Tomas Babej wrote: >>> >>> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>>> This almost completes the switch to pytest. There are two missing >>>>> things: >>>>> - the details of test results (--with-xunit) are not read >>>>> correctly by >>>>> Jenkins. I have a theory I'm investigating here. >>>>> - the beakerlib integration is still not ready >>>>> >>>>> >>>>> I'll not be available for the rest of the week so I'm sending this >>>>> early, in case someone wants to take a look. >>>> >>>> I've updated (and rearranged) the patches after some more testing. >>>> Both points above are fixed. Individual plugins are broken out; some >>>> would be nice to even release independently of IPA. (There is some >>>> demand for the BeakerLib plugin; for that I'd only need to break the >>>> dependency on ipa_log_manager.) >>>> >>>> >>>> These depend on my patches 0656-0660. >>>> >> >>> Thanks for this effort! >>> >>> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names >>> >>> There are some references to the old names in the test_ipapython and >>> test_install: >>> >>> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >>> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >>> [tbabej at thinkpad7 ipatests]$ git grep setUp >>> test_install/test_updates.py: def setUp(self): >>> test_ipapython/test_cookie.py: def setUp(self): >>> test_ipapython/test_cookie.py: def setUp(self): >>> test_ipapython/test_cookie.py: def setUp(self): >>> test_ipapython/test_dn.py: def setUp(self): >>> test_ipapython/test_dn.py: def setUp(self): >>> test_ipapython/test_dn.py: def setUp(self): >>> test_ipapython/test_dn.py: def setUp(self): >>> test_ipapython/test_dn.py: def setUp(self): >>> [tbabej at thinkpad7 ipatests]$ git grep tearDown >>> test_install/test_updates.py: def tearDown(self): >> >> These are in unittest.testCase. It would be nice to convert those as >> well, but that's for a larger cleanup. >> >>> #### Patch 0657: tests: Add configuration for pytest >>> >>> Shouldn't we rather change the class names? >> >> Ideally yes, but I don't think renaming most of our test classes would >> be worth the benefit. >> >>> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >>> get_subcls >>> >>> ACK. >>> >>> #### Patch 0659: test_automount_plugin: Fix test ordering >>> >>> ACK. >>> >>> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >>> >>> --- a/ipatests/test_ipaserver/test_changepw.py >>> +++ b/ipatests/test_ipaserver/test_changepw.py >>> @@ -33,8 +33,7 @@ >>> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >>> app_uri = '/ipa/session/change_password' >>> >>> - def setup(self): >>> - super(test_changepw, self).setup() >>> + def setup(cls): >>> try: >>> api.Command['user_add'](uid=testuser, >>> givenname=u'Test', sn=u'User') >>> api.Command['passwd'](testuser, >>> password=u'old_password') >>> @@ -43,12 +42,11 @@ def setup(self): >>> 'Cannot set up test user: %s' % e >>> ) >>> >>> - def teardown(self): >>> + def teardown(cls): >>> try: >>> api.Command['user_del']([testuser]) >>> except errors.NotFound: >>> pass >>> - super(test_changepw, self).teardown() >>> >>> The setup/teardown methods are not classmethods, so the name of the >>> first argument should remain "self". >> >> Oops, thanks for the catch! >> >>> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for >>> non-doctest >>> examples >>> >>> ACK. >>> >>> #### PATCH 0662: test_webui: Don't use __init__ for test classes >>> >>> I don't think the following change will work: >>> >>> - def __init__(self, driver=None, config=None): >>> + def setup(self, driver=None, config=None): >>> self.request_timeout = 30 >>> self.driver = driver >>> self.config = config >>> if not config: >>> self.load_config() >>> + self.get_driver().maximize_window() >>> + >>> + def teardown(self): >>> + self.driver.quit() >>> >>> def load_config(self): >>> """ >>> @@ -161,20 +165,6 @@ def load_config(self): >>> if 'type' not in c: >>> c['type'] = DEFAULT_TYPE >>> >>> - def setup(self): >>> - """ >>> - Test setup >>> - """ >>> - if not self.driver: >>> - self.driver = self.get_driver() >>> - self.driver.maximize_window() >>> - >>> - def teardown(self): >>> - """ >>> - Test clean up >>> - """ >>> - self.driver.quit() >>> >>> >>> The setup(self) method used to set the self.driver attribute on the >>> class instance, now nothing sets it. The setup method should do: >>> >>> def setup(self, driver=None, config=None): >>> self.request_timeout = 30 >>> self.driver = driver >>> self.config = config >>> if not config: >>> self.load_config() >>> if not self.driver: >>> self.driver = self.get_driver() >>> self.driver.maximize_window() >>> >>> However, I would prefer having self.driver as a cached property. >> >> Well, ideally these would be fixtures. >> >> Thanks for the catch. >> >>> #### PATCH 0663: test_ipapython: Use functions instead of classes in >>> test generators >>> >>> ACK. >>> >>> #### PATCH 0664: Configure pytest to run doctests >>> >>> ACK. >>> >>> #### PATCH 0665: Declarative tests: Move cleanup to >>> setup_class/teardown_class >>> >>> You should also remove the now redundant cleanup_generate method. >> >> Right, removed. >> >>> Also: Do we really want to print out error.NotFound or >>> errors.EmptyModList exceptions produced by cleanup commands? >> >> It's just one line, might help debugging. It should only show up on >> failures. >> >>> #### PATCH 0666: Declarative tests: Switch to pytest >>> >>> Nitpitck: declarative.py has wrong year in the copyright header. >>> Otherwise ACK. >> >> Fixed. >> >>> #### PATCH 0667: Integration tests: Port the ordering plugin to pytest >>> >>> Specfile change belongs to the previous patch, but I doubt these would >>> be separated, so not worth spending the time IMHO. >> >> Also, the previous patch doesn't actually import pytest. But a lot of >> these patches break tests by themselves, so they shouldn't be separated. >> >>> Why does TestIPACommands have ordered decorator applied? It is applied >>> on IntegrationTest directly, from which CALessBase inherits from. I >>> don't think it's necessary (unless I'm missing something), so we should >>> rather remove the occurence of the decorator in the test_caless.py than >>> fixing the import. >> >> Actually, I think only only the classes that actually need it should >> have the decorator. >> Again, cleanup for a future time. >> >>> #### PATCH 0668: Switch make-test to pytest >>> >>> Nice simplification. However, make-test does not work for me: >>> >>> I'm getting tons of errors (during the collection) along the lines of: >>> >>> ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py >>> _________________ >>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>> pyimport >>> raise self.ImportMismatchError(modname, modfile, self) >>> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >>> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >>> _______________ ERROR collecting >>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>> pyimport >>> raise self.ImportMismatchError(modname, modfile, self) >>> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >>> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >>> _______________ ERROR collecting >>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>> import file mismatch: >>> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >>> __file__ attribute: >>> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >>> which is not the same as the test file we want to collect: >>> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >>> HINT: remove __pycache__ / .pyc files and/or use a unique basename >>> for your test file modules >>> ================ 163 passed, 7 skipped, 679 error in 48.14 seconds >>> ============== >>> >>> >>> I am running this as ./make-test from the directory containing the >>> freeipa sources. The ipa-run-tests command seems to work fine though. >> >> Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? >> I've added . to PYTHONPATH, that may help (and it should also help with >> plugin loading in some cases). >> >>> #### PATCH 0669: Add local pytest plugin for --with-xunit and >>> --logging-level >>> >>> ACK. >>> >>> #### PATCH 0670: Switch ipa-run-tests to pytest >>> >>> ACK. >>> >>> #### PATCH 0671: Switch integration testing config to a fixture >>> >>> ACK. >>> >>> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >>> collection to pytest >>> >>> I didn't see any glitches, but I haven't tested this one out yet >>> functionally. >>> >>> ### General notes >>> >>> I did two IPA master installs today, one with your patches applied. >>> There were significant differences in the number of successfully >>> passing >>> tests: >>> >>> nose: FAILED (SKIP=60, errors=46, failures=14) >>> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >>> 860.47 seconds ========= >>> >>> Did you not encounter this in your testing? I will look more deeply >>> into >>> the failures themselves. >> >> I did, but it was always some stupid mistake :) >> Do you have ~/.ipa set up, and $MASTER undefined? >> >> The integration test did fail for me now when they were not configured. >> I added an additional patch to fix that. > > Ping, could you look at the updated patches? > > Sure, but the patchset requires a rebase. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From jpazdziora at redhat.com Wed Nov 19 12:22:59 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 19 Nov 2014 13:22:59 +0100 Subject: [Freeipa-devel] FreeIPA Copr repo plan In-Reply-To: <54609C82.7070403@redhat.com> References: <54609C82.7070403@redhat.com> Message-ID: <20141119122259.GN12423@redhat.com> On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote: > > 1) What Copr repos do we want to maintain and what should be the expectations? > My take: > > a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, > EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? > Does it fit your needs? It does not install, so no idea. Both the centos-7 tag of https://registry.hub.docker.com/u/adelton/freeipa-server/ and https://registry.hub.docker.com/u/centos/freeipa/ use the IdM in CentOS 7, not FreeIPA from your copr repo, at this point. > b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and > greatest release, would it make sense to have a Copr repo with *releases* per > supported branch to give users a choice? I.e. > * mkosek/freeipa-4.1 > * mkosek/freeipa-4.0 It is not just users having a choice but the ability to quickly check behaviour on older version when developing or testing regression. > These repos are there already, but not used consistently. I do not think we > should build all the dependency chain (too much overhead) for older systems > (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for > these systems if it uses "mkosek/freeipa" as additional build root in Copr. I don't think it's necessary to build dependency chain to the oldest versions. But if the release was once built on a give OS (as a nightly, for example), we should be able to keep it, including the dependencies. > Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, > 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across > projects "mkosek/freeipa-master", "someone/sssd-master", > "someone/389-ds-base-master? Second option may scale better better, the list of > such repos may be maintained somewhere (freeipa.org wiki). Having them into separate copr repos would certainly allow better insight into (for example) the dependency chains by people who know how their part should build and install. Currently when we see a huge dependency tree when installing freeipa-server package, it might not be immediatelly obvious, what is causing the possible bloat. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From tbordaz at redhat.com Wed Nov 19 12:27:43 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 19 Nov 2014 13:27:43 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C7DF9.3040001@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> Message-ID: <546C8CBF.40102@redhat.com> On 11/19/2014 12:24 PM, Martin Kosek wrote: > On 11/19/2014 12:03 PM, Tomas Babej wrote: >> Hi, >> >> When constructing a parent DN in LDAPSearch, we should always >> check that the parent object exists (hence use get_dn_if_exists), >> rather than search on unexistant containers (which can happen >> with get_dn). >> >> Replaces get_dn calls with get_dn_if_exists in *-find commands >> and makes sure proper error message is raised. >> >> https://fedorahosted.org/freeipa/ticket/4659 > Doesn't it produce extra LDAP search thus making all our search commands > slower? Is that what we want? Wouldn't it be better to distinguish between LDAP > search with no results and LDAP search with missing parent DN? The reply looks > different, at least in CLI: > > # search result > search: 4 > result: 0 Success > > # search result > search: 4 > result: 32 No such object > matchedDN: cn=accounts,dc=mkosek-f20,dc=test > > Also, I do not think you can just stop using get_dn(), some commands override > this call to get more complex searches (like host-find searching for shortname). > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, If there is an extra search, will it be done on the same connection/bind ? Testing that an entry exists, even if no attribute are requested, loads the entry in the cache and evaluate the aci. If the entry does not exist, I do not think there is a gain between search(base) and search(subtree). If the entry exists, it will add the overhead of first search (connect/bind/aci) and the benefit of the first search depends if this entry matches the filter. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Wed Nov 19 12:31:40 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 19 Nov 2014 13:31:40 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C8441.3090407@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> Message-ID: <546C8DAC.1090407@redhat.com> On 11/19/2014 12:51 PM, Martin Kosek wrote: > On 11/19/2014 12:41 PM, Tomas Babej wrote: >> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> When constructing a parent DN in LDAPSearch, we should always >>>> check that the parent object exists (hence use get_dn_if_exists), >>>> rather than search on unexistant containers (which can happen >>>> with get_dn). >>>> >>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>> and makes sure proper error message is raised. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4659 >>> Doesn't it produce extra LDAP search thus making all our search commands >>> slower? Is that what we want? >> No it does not make all of our LDAP search slower. It only happens for >> the objects that have parent objects, such as idoverrides or dnsrecords. > ... and makes them slower. > >>> Wouldn't it be better to distinguish between LDAP >>> search with no results and LDAP search with missing parent DN? The reply looks >>> different, at least in CLI: >> Up to discussion. We would probably need to introduce a new exception, >> like ParentObjectNotFound. >> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # search result >>> search: 4 >>> result: 32 No such object >>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>> >>> Also, I do not think you can just stop using get_dn(), some commands override >>> this call to get more complex searches (like host-find searching for shortname). >> Look into the get_dn_if_exists, it just wraps around get_dn, so no issue >> here. Any custom behaviour is preserved. > Ah, ok, thanks for info. > >> To sum up, I think this is worth changing this behaviour by default, >> ignoring a non-matching value of the parent object is not a correct >> general approach in my opinion. > Well, that's the question. Whether we would leave DS to validate the search > itself or do all the pre-check ourselves. To me, doing just one LDAP search and > processing the error correctly looks better. +1 > But I can live even with your > version then, I will leave the framework guardians like Honza or Petr3 to decide. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Wed Nov 19 12:39:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 13:39:14 +0100 Subject: [Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode In-Reply-To: <546B30E1.4080406@redhat.com> References: <5464EA3B.3050004@redhat.com> <546B2876.6040301@redhat.com> <546B30E1.4080406@redhat.com> Message-ID: <546C8F72.8080503@redhat.com> On 18.11.2014 12:43, David Kupka wrote: > On 11/18/2014 12:07 PM, Martin Basti wrote: >> On 13/11/14 18:28, Martin Basti wrote: >>> To allow IDNA zonemgr email, value must be unicode not ASCII >>> Ticket: https://fedorahosted.org/freeipa/ticket/4724 >>> >>> Patch attached. >>> >> Patch for ipa-4.0 added. >> > > Thanks, works for me, ACK. > Pushed to: ipa-4-0: ca6958c348edac53c40423679340967749015dd4 ipa-4-1: 53cf615ad87c6a019eca31a924abd035c375c556 master: d2ffd176176e20860998d29ede4e9bd65f398bf2 -- Petr Vobornik From tbabej at redhat.com Wed Nov 19 12:44:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Nov 2014 13:44:22 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C8441.3090407@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> Message-ID: <546C90A6.2000408@redhat.com> On 11/19/2014 12:51 PM, Martin Kosek wrote: > On 11/19/2014 12:41 PM, Tomas Babej wrote: >> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> When constructing a parent DN in LDAPSearch, we should always >>>> check that the parent object exists (hence use get_dn_if_exists), >>>> rather than search on unexistant containers (which can happen >>>> with get_dn). >>>> >>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>> and makes sure proper error message is raised. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4659 >>> Doesn't it produce extra LDAP search thus making all our search commands >>> slower? Is that what we want? >> No it does not make all of our LDAP search slower. It only happens for >> the objects that have parent objects, such as idoverrides or dnsrecords. > ... and makes them slower. What I was pointing out here is that this is not a issue for ALL *-find commands (e.g user-find, group-find will not suffer from it), as you incorrectly stated. > >>> Wouldn't it be better to distinguish between LDAP >>> search with no results and LDAP search with missing parent DN? The reply looks >>> different, at least in CLI: >> Up to discussion. We would probably need to introduce a new exception, >> like ParentObjectNotFound. >> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # search result >>> search: 4 >>> result: 32 No such object >>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>> >>> Also, I do not think you can just stop using get_dn(), some commands override >>> this call to get more complex searches (like host-find searching for shortname). >> Look into the get_dn_if_exists, it just wraps around get_dn, so no issue >> here. Any custom behaviour is preserved. > Ah, ok, thanks for info. > >> To sum up, I think this is worth changing this behaviour by default, >> ignoring a non-matching value of the parent object is not a correct >> general approach in my opinion. > Well, that's the question. Whether we would leave DS to validate the search > itself or do all the pre-check ourselves. To me, doing just one LDAP search and > processing the error correctly looks better. But I can live even with your > version then, I will leave the framework guardians like Honza or Petr3 to decide. I see now what you're trying to suggest. However, the reason boils down to ipaldap.find_entries method not differentiating between a LDAP search that returns error code 32 (No such object) and LDAP search returning error code 0 (Success), but returning no results. In both cases errors.NotFound is raised. The reason I did not go this way is that changing the find_entries method is quite more invasive as this is the method subsenqently called by almost any command. > Martin -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mbasti at redhat.com Wed Nov 19 12:47:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Nov 2014 13:47:48 +0100 Subject: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI In-Reply-To: <546C82C2.3010103@redhat.com> References: <5464D303.9070103@redhat.com> <546C82C2.3010103@redhat.com> Message-ID: <546C9174.1000809@redhat.com> On 19/11/14 12:45, Petr Vobornik wrote: > On 13.11.2014 16:49, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4647 >> Patch attached. >> > > The change looses information about the zone apex record. User also > might not know what is the message about because it lacks context. > > CLI option name as context is the cause of this bug but it could be > replaced with, e.g., label. > > So what about: > > Semantic of setting Authoritative nameserver was changed. It's > used only for setting the SOA MNAME attribute. > > NS record(s) can be edited in special zone apex record - '@'. > Updated patch attached. I used "NS record(s) can be edited in zone apex - '@'." instead of yours. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0164.2-Fix-warning-message-should-not-contain-CLI-commands.patch Type: text/x-patch Size: 3507 bytes Desc: not available URL: From pvoborni at redhat.com Wed Nov 19 12:55:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 13:55:36 +0100 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <1416349744.3141.32.camel@redhat.com> References: <546B964D.5000804@redhat.com> <1416349744.3141.32.camel@redhat.com> Message-ID: <546C9348.9040001@redhat.com> On 18.11.2014 23:29, Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . > > ACK > Shouldn't the version be 10.1.2-4 ? http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 -- Petr Vobornik From jcholast at redhat.com Wed Nov 19 12:59:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 13:59:31 +0100 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <546C9348.9040001@redhat.com> References: <546B964D.5000804@redhat.com> <1416349744.3141.32.camel@redhat.com> <546C9348.9040001@redhat.com> Message-ID: <546C9433.2070601@redhat.com> Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): > On 18.11.2014 23:29, Nathaniel McCallum wrote: >> On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >> >> ACK >> > > Shouldn't the version be 10.1.2-4 ? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 No. -- Jan Cholasta From mkosek at redhat.com Wed Nov 19 13:02:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Nov 2014 14:02:38 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C90A6.2000408@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> Message-ID: <546C94EE.1080902@redhat.com> On 11/19/2014 01:44 PM, Tomas Babej wrote: > > On 11/19/2014 12:51 PM, Martin Kosek wrote: >> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> When constructing a parent DN in LDAPSearch, we should always >>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>> rather than search on unexistant containers (which can happen >>>>> with get_dn). >>>>> >>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>> and makes sure proper error message is raised. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>> Doesn't it produce extra LDAP search thus making all our search commands >>>> slower? Is that what we want? >>> No it does not make all of our LDAP search slower. It only happens for >>> the objects that have parent objects, such as idoverrides or dnsrecords. >> ... and makes them slower. > > What I was pointing out here is that this is not a issue for ALL *-find > commands (e.g user-find, group-find will not suffer from it), as you > incorrectly stated. I understood that. But it does not make idview-* or dnsrecord-* any faster :-) > >> >>>> Wouldn't it be better to distinguish between LDAP >>>> search with no results and LDAP search with missing parent DN? The reply looks >>>> different, at least in CLI: >>> Up to discussion. We would probably need to introduce a new exception, >>> like ParentObjectNotFound. >>> >>>> # search result >>>> search: 4 >>>> result: 0 Success >>>> >>>> # search result >>>> search: 4 >>>> result: 32 No such object >>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>> >>>> Also, I do not think you can just stop using get_dn(), some commands override >>>> this call to get more complex searches (like host-find searching for shortname). >>> Look into the get_dn_if_exists, it just wraps around get_dn, so no issue >>> here. Any custom behaviour is preserved. >> Ah, ok, thanks for info. >> >>> To sum up, I think this is worth changing this behaviour by default, >>> ignoring a non-matching value of the parent object is not a correct >>> general approach in my opinion. >> Well, that's the question. Whether we would leave DS to validate the search >> itself or do all the pre-check ourselves. To me, doing just one LDAP search and >> processing the error correctly looks better. But I can live even with your >> version then, I will leave the framework guardians like Honza or Petr3 to decide. > > I see now what you're trying to suggest. However, the reason boils > down to ipaldap.find_entries method not differentiating between a > LDAP search that returns error code 32 (No such object) and LDAP > search returning error code 0 (Success), but returning no results. > > In both cases errors.NotFound is raised. > > The reason I did not go this way is that changing the find_entries method > is quite more invasive as this is the method subsenqently called by almost > any command. Right. To avoid potential issues, the ParentNotFound would need to be a subclass to NotFoundError so that "except NotFound" still works. From jcholast at redhat.com Wed Nov 19 13:03:16 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 14:03:16 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C90A6.2000408@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> Message-ID: <546C9514.1080904@redhat.com> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): > > On 11/19/2014 12:51 PM, Martin Kosek wrote: >> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> When constructing a parent DN in LDAPSearch, we should always >>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>> rather than search on unexistant containers (which can happen >>>>> with get_dn). >>>>> >>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>> and makes sure proper error message is raised. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>> Doesn't it produce extra LDAP search thus making all our search commands >>>> slower? Is that what we want? >>> No it does not make all of our LDAP search slower. It only happens for >>> the objects that have parent objects, such as idoverrides or dnsrecords. >> ... and makes them slower. > > What I was pointing out here is that this is not a issue for ALL *-find > commands (e.g user-find, group-find will not suffer from it), as you > incorrectly stated. > >> >>>> Wouldn't it be better to distinguish between LDAP >>>> search with no results and LDAP search with missing parent DN? The reply looks >>>> different, at least in CLI: >>> Up to discussion. We would probably need to introduce a new exception, >>> like ParentObjectNotFound. >>> >>>> # search result >>>> search: 4 >>>> result: 0 Success >>>> >>>> # search result >>>> search: 4 >>>> result: 32 No such object >>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>> >>>> Also, I do not think you can just stop using get_dn(), some commands override >>>> this call to get more complex searches (like host-find searching for shortname). >>> Look into the get_dn_if_exists, it just wraps around get_dn, so no issue >>> here. Any custom behaviour is preserved. >> Ah, ok, thanks for info. >> >>> To sum up, I think this is worth changing this behaviour by default, >>> ignoring a non-matching value of the parent object is not a correct >>> general approach in my opinion. >> Well, that's the question. Whether we would leave DS to validate the search >> itself or do all the pre-check ourselves. To me, doing just one LDAP search and >> processing the error correctly looks better. But I can live even with your >> version then, I will leave the framework guardians like Honza or Petr3 to decide. +1 on single LDAP search and proper error processing. > > I see now what you're trying to suggest. However, the reason boils > down to ipaldap.find_entries method not differentiating between a > LDAP search that returns error code 32 (No such object) and LDAP > search returning error code 0 (Success), but returning no results. > > In both cases errors.NotFound is raised. > > The reason I did not go this way is that changing the find_entries method > is quite more invasive as this is the method subsenqently called by almost > any command. You can always derive the new error (ParentNotFound or whatever) on NotFound, so old code won't break. -- Jan Cholasta From simo at redhat.com Wed Nov 19 13:05:34 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Nov 2014 08:05:34 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141119105301.GY3493@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> Message-ID: <20141119080534.1f8b6f7e@willson.usersys.redhat.com> On Wed, 19 Nov 2014 12:53:01 +0200 Alexander Bokovoy wrote: > On Tue, 18 Nov 2014, Simo Sorce wrote: > >On Tue, 18 Nov 2014 15:01:15 -0500 > >Nathaniel McCallum wrote: > > > >> As I see it, we're setting out a new precedent. All new ASN.1 code > >> will take this route (which is, indeed, better). So while it is > >> small now, it won't stay small forever. Being that we are in the > >> business of routinely handling ASN.1 stuff, this seems to me like > >> a sensible architecture for the future. > > > >Ok, I think I should have fixed all the issues you brought up. > > > >And my tests still work fine :) > Works fine. However, I'm getting wrong TGT enctype back from the KDC > when I try to obtain TGT with des-cbc-crc key: > > [root at master ~]# ipa host-add --force f21test.f21.test > ----------------------------- > Added host "f21test.f21.test" > ----------------------------- > Host name: f21test.f21.test > Principal name: host/f21test.f21.test at F21.TEST > Password: False > Keytab: False > Managed by: f21test.f21.test > [root at master ~]# ipa service-add --force afs/f21test > ------------------------------------ > Added service "afs/f21test at F21.TEST" > ------------------------------------ > Principal: afs/f21test at F21.TEST > Managed by: f21test.f21.test > [root at master ~]# ipa-getkeytab -s `hostname` -p afs/f21test > -k /tmp/afs.keytab -e des-cbc-crc:v4 -P New Principal Password: > Verify Principal Password: > Keytab successfully retrieved and stored in: /tmp/afs.keytab > [root at master ~]# klist -kt /tmp/afs.keytab -K -e > Keytab name: FILE:/tmp/afs.keytab > KVNO Timestamp Principal > ---- ----------------- > -------------------------------------------------------- 1 11/19/14 > 12:13:01 afs/f21test at F21.TEST (des-cbc-crc) (0xea1a0b29152cb383) The key is des-cbc-crc > > [root at master ~]# KRB5_TRACE=/dev/stderr KRB5CCNAME=/tmp/afs.ccache > kinit -kt /tmp/afs.keytab afs/f21test [28636] 1416392072.862773: > Getting initial credentials for afs/f21test at F21.TEST [28636] > 1416392072.864408: Looked up etypes in keytab: des-cbc-crc [28636] > 1416392072.864522: Sending request (175 bytes) to F21.TEST [28636] > 1416392072.865127: Sending initial UDP request to dgram > 192.168.5.169:88 [28636] 1416392072.866958: Received answer (283 > bytes) from dgram 192.168.5.169:88 [28636] 1416392072.867028: > Response was from master KDC [28636] 1416392072.867088: Received > error from KDC: -1765328359/Additional pre-authentication required > [28636] 1416392072.867140: Processing preauth types: 136, 19, 2, 133 > [28636] 1416392072.867175: Selected etype info: etype des-cbc-crc, > salt "F21.TESTafsf21test", params "" [28636] 1416392072.867193: > Received cookie: MIT [28636] 1416392072.867234: Retrieving > afs/f21test at F21.TEST from FILE:/tmp/afs.keytab (vno 0, enctype > des-cbc-crc) with result: 0/Success [28636] 1416392072.867264: AS key > obtained for encrypted timestamp: des-cbc-crc/0BE8 [28636] > 1416392072.867304: Encrypted timestamp (for 1416392072.867050): plain > 301AA011180F32303134313131393130313433325AA10502030D3AEA, encrypted > 1C567557D395C0639CB417EE90C08CD41E4829D910166D62ACEDCC2168C23BAD8C70DFE4CD533A81 > [28636] 1416392072.867331: Preauth module encrypted_timestamp (2) > (real) returned: 0/Success [28636] 1416392072.867349: Produced > preauth for next request: 133, 2 [28636] 1416392072.867372: Sending > request (252 bytes) to F21.TEST [28636] 1416392072.867416: Sending > initial UDP request to dgram 192.168.5.169:88 [28636] > 1416392072.946260: Received answer (649 bytes) from dgram > 192.168.5.169:88 [28636] 1416392072.946391: Response was from master > KDC [28636] 1416392072.946485: Processing preauth types: 19 [28636] > 1416392072.946542: Selected etype info: etype des-cbc-crc, salt > "F21.TESTafsf21test", params "" [28636] 1416392072.946593: Produced > preauth for next request: (empty) [28636] 1416392072.946626: AS key > determined by preauth: des-cbc-crc/0BE8 [28636] 1416392072.946688: > Decrypted AS reply; session key is: des-cbc-crc/9B41 [28636] > 1416392072.946727: FAST negotiation: available [28636] > 1416392072.946793: Initializing FILE:/tmp/afs.ccache with default > princ afs/f21test at F21.TEST [28636] 1416392072.947118: Removing > afs/f21test at F21.TEST -> krbtgt/F21.TEST at F21.TEST from > FILE:/tmp/afs.ccache [28636] 1416392072.947146: Storing > afs/f21test at F21.TEST -> krbtgt/F21.TEST at F21.TEST in > FILE:/tmp/afs.ccache [28636] 1416392072.947187: Storing config in > FILE:/tmp/afs.ccache for krbtgt/F21.TEST at F21.TEST: fast_avail: yes > [28636] 1416392072.947219: Removing afs/f21test at F21.TEST -> > krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: > from FILE:/tmp/afs.ccache [28636] 1416392072.947240: Storing > afs/f21test at F21.TEST -> > krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: > in FILE:/tmp/afs.ccache [28636] 1416392072.947419: Storing config in > FILE:/tmp/afs.ccache for krbtgt/F21.TEST at F21.TEST: pa_type: 2 [28636] > 1416392072.947458: Removing afs/f21test at F21.TEST -> > krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: > from FILE:/tmp/afs.ccache [28636] 1416392072.947480: Storing > afs/f21test at F21.TEST -> > krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST at X-CACHECONF: > in FILE:/tmp/afs.ccache [root at master ~]# KRB5_TRACE=/dev/stderr > KRB5CCNAME=/tmp/afs.ccache klist -edf Ticket cache: > FILE:/tmp/afs.ccache Default principal: afs/f21test at F21.TEST > > Valid starting Expires Service principal > 11/19/14 12:14:32 11/20/14 12:14:32 krbtgt/F21.TEST at F21.TEST > Flags: FIA, Etype (skey, tkt): des-cbc-crc, > aes256-cts-hmac-sha1-96 Look carefully, you got des-cbc-crc just fine, the tkt enctype is aes256-cts-hmac-sha1-96 and that does not depend on how getkeytab work, as it is negotiated at runtime by the KDC. I.E. if it is a problem it is not one of getkeytab, but we'll have to look elsewhere. > KDC logs show this: > Nov 19 12:25:57 master.f21.test krb5kdc[28713](info): AS_REQ (9 > etypes {1 18 17 16 23 25 26 3 2}) 192.168.5.169: NEEDED_PREAUTH: > afs/f21test at F21.TEST for krbtgt/F21.TEST at F21.TEST, Additional > pre-authentication required Nov 19 12:25:57 master.f21.test > krb5kdc[28713](info): AS_REQ (9 etypes {1 18 17 16 23 25 26 3 2}) > 192.168.5.169: ISSUE: authtime 1416392757, etypes {rep=1 tkt=18 > ses=1}, afs/f21test at F21.TEST for krbtgt/F21.TEST at F21.TEST > > My /etc/krb5.conf has > [libdefaults] > allow_weak_crypto = true > permitted_enctypes = DEFAULT +des > supported_enctypes = DEFAULT +des > > We can handle weak types' response TGT after F21 release, this is > certainly not limiting. > > I've tried with older ipa-getkeytab and it fell back to the pre-4.0 > method as expected. > > Regarding the patchset itself: > > Patch 0001: fix 'wuld' in the commit message. The rest is fine. > > Patch 0002: > - ticket number is missing in the commit message Well this commit does not solve any ticket in itself, it just add the library, it is the next one that uses it, but I guess I can repeat the numbers in both commits. > - perhaps, an instruction how to regenerate asn1 code can be made a > Makefile target? We don't need to call it ourselves but this would > simplify things in future I had put it in the README, will see to put it in Makefile I guess > - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to > stderr but I guess this is something we currently cannot override > with DS-specific log printing, so no big deal right now Yeah, there may be a way to override, but I had no time to look carefully into it. > - any specific need to get asn1/compile committed? We don't commit it > in the client code (ipa-client/compile). Uh, no I committed this one in error, thanks for spotting it. > Patch 0003: OK Will provide another round soon. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Wed Nov 19 13:07:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 14:07:46 +0100 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <546C9433.2070601@redhat.com> References: <546B964D.5000804@redhat.com> <1416349744.3141.32.camel@redhat.com> <546C9348.9040001@redhat.com> <546C9433.2070601@redhat.com> Message-ID: <546C9622.3050202@redhat.com> On 19.11.2014 13:59, Jan Cholasta wrote: > Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): >> On 18.11.2014 23:29, Nathaniel McCallum wrote: >>> On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>> >>> ACK >>> >> >> Shouldn't the version be 10.1.2-4 ? >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 > > No. > ok, nevermind, f21 has 10.2.1-0.1, but it doesn't list the fix in the changelog. But the patch needs a rebase because of Martin's patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=588670 -- Petr Vobornik From jcholast at redhat.com Wed Nov 19 13:27:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 14:27:50 +0100 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <546C9622.3050202@redhat.com> References: <546B964D.5000804@redhat.com> <1416349744.3141.32.camel@redhat.com> <546C9348.9040001@redhat.com> <546C9433.2070601@redhat.com> <546C9622.3050202@redhat.com> Message-ID: <546C9AD6.8060408@redhat.com> Dne 19.11.2014 v 14:07 Petr Vobornik napsal(a): > On 19.11.2014 13:59, Jan Cholasta wrote: >> Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): >>> On 18.11.2014 23:29, Nathaniel McCallum wrote: >>>> On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>> >>>> ACK >>>> >>> >>> Shouldn't the version be 10.1.2-4 ? >>> >>> http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 >> >> No. >> > > ok, nevermind, f21 has 10.2.1-0.1, but it doesn't list the fix in the > changelog. > > But the patch needs a rebase because of Martin's patch. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=588670 Rebased and pushed to ipa-4-1: 4e1193119b3e7f7c13f504f24445509958887927 -- Jan Cholasta From pvoborni at redhat.com Wed Nov 19 13:28:01 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 14:28:01 +0100 Subject: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add In-Reply-To: <546B8172.7050902@redhat.com> References: <1415306034.3273.8.camel@redhat.com> <1415861639.9222.3.camel@redhat.com> <5464A16B.7000307@redhat.com> <1415890856.9116.5.camel@redhat.com> <5464CAB6.9020501@redhat.com> <1415891956.9116.6.camel@redhat.com> <5464D0FD.2040905@redhat.com> <5464D4E5.4080003@redhat.com> <1415898171.9116.10.camel@redhat.com> <5464F474.3040807@redhat.com> <5465F333.3070008@redhat.com> <5465FEC8.4030602@redhat.com> <20141114132625.3c0a1e8b@willson.usersys.redhat.com> <54665206.90700@redhat.com> <5466527F.7060805@redhat.com> <20141114142933.3e36c17a@willson.usersys.redhat.com> <546B2D20.2040108@redhat.com> <20141118074557.4a430528@willson.usersys.redhat.com> <1416328034.3141.19.camel@redhat.com> <546B8172.7050902@redhat.com> Message-ID: <546C9AE1.90100@redhat.com> On 18.11.2014 18:27, Petr Vobornik wrote: > On 18.11.2014 17:27, Nathaniel McCallum wrote: >> This patch still needs to land in 4.1.2, so is it okay as it is? > > I don't think the label is necessary but it doesn't hurt either, at > least it's clear, so ACK. Pushed to: master: 3c900ba7a8d98a72ff4e040b688fe3213c722a64 ipa-4-1: 1cd2ca11c5b22dc3bd555e63dba69e9475817872 -- Petr Vobornik From dkupka at redhat.com Wed Nov 19 14:02:19 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Nov 2014 15:02:19 +0100 Subject: [Freeipa-devel] [PATCH] 374 Fix wrong expiration date on renewed IPA CA certificates In-Reply-To: <546C47A3.4030803@redhat.com> References: <546C47A3.4030803@redhat.com> Message-ID: <546CA2EB.5040707@redhat.com> On 11/19/2014 08:32 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, thanks, ACK. -- David Kupka From mbasti at redhat.com Wed Nov 19 14:06:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Nov 2014 15:06:15 +0100 Subject: [Freeipa-devel] [PATCH 0167] DNS: Raise proper exception instead UnicodeError Message-ID: <546CA3D7.20408@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4734 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0167-Raise-right-exception-if-domain-name-is-not-valid.patch Type: text/x-patch Size: 1774 bytes Desc: not available URL: From tbabej at redhat.com Wed Nov 19 14:12:09 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 19 Nov 2014 15:12:09 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546C9514.1080904@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> Message-ID: <546CA539.2050005@redhat.com> On 11/19/2014 02:03 PM, Jan Cholasta wrote: > Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >> >> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>>> rather than search on unexistant containers (which can happen >>>>>> with get_dn). >>>>>> >>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>> and makes sure proper error message is raised. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>> Doesn't it produce extra LDAP search thus making all our search >>>>> commands >>>>> slower? Is that what we want? >>>> No it does not make all of our LDAP search slower. It only happens for >>>> the objects that have parent objects, such as idoverrides or >>>> dnsrecords. >>> ... and makes them slower. >> >> What I was pointing out here is that this is not a issue for ALL *-find >> commands (e.g user-find, group-find will not suffer from it), as you >> incorrectly stated. >> >>> >>>>> Wouldn't it be better to distinguish between LDAP >>>>> search with no results and LDAP search with missing parent DN? The >>>>> reply looks >>>>> different, at least in CLI: >>>> Up to discussion. We would probably need to introduce a new exception, >>>> like ParentObjectNotFound. >>>> >>>>> # search result >>>>> search: 4 >>>>> result: 0 Success >>>>> >>>>> # search result >>>>> search: 4 >>>>> result: 32 No such object >>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>> >>>>> Also, I do not think you can just stop using get_dn(), some >>>>> commands override >>>>> this call to get more complex searches (like host-find searching >>>>> for shortname). >>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>> issue >>>> here. Any custom behaviour is preserved. >>> Ah, ok, thanks for info. >>> >>>> To sum up, I think this is worth changing this behaviour by default, >>>> ignoring a non-matching value of the parent object is not a correct >>>> general approach in my opinion. >>> Well, that's the question. Whether we would leave DS to validate the >>> search >>> itself or do all the pre-check ourselves. To me, doing just one LDAP >>> search and >>> processing the error correctly looks better. But I can live even >>> with your >>> version then, I will leave the framework guardians like Honza or >>> Petr3 to decide. > > +1 on single LDAP search and proper error processing. > >> >> I see now what you're trying to suggest. However, the reason boils >> down to ipaldap.find_entries method not differentiating between a >> LDAP search that returns error code 32 (No such object) and LDAP >> search returning error code 0 (Success), but returning no results. >> >> In both cases errors.NotFound is raised. >> >> The reason I did not go this way is that changing the find_entries >> method >> is quite more invasive as this is the method subsenqently called by >> almost >> any command. > > You can always derive the new error (ParentNotFound or whatever) on > NotFound, so old code won't break. > Thanks for the suggestsions. Attached is a new patch which hooks into find_entries method and differentiates between the cases. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0286-2-baseldap-Handle-missing-parent-objects-properly-in-f.patch Type: text/x-patch Size: 4193 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 19 14:26:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Nov 2014 15:26:05 +0100 Subject: [Freeipa-devel] [PATCH] 374 Fix wrong expiration date on renewed IPA CA certificates In-Reply-To: <546CA2EB.5040707@redhat.com> References: <546C47A3.4030803@redhat.com> <546CA2EB.5040707@redhat.com> Message-ID: <546CA87D.4010004@redhat.com> Dne 19.11.2014 v 15:02 David Kupka napsal(a): > On 11/19/2014 08:32 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me, thanks, ACK. > Pushed to: master: 52b141ca6a257b8f12d9ad2ade812ec1bfebf0d7 ipa-4-1: 7aa855a37b1996588d7d2084176e38145b1587be -- Jan Cholasta From pvoborni at redhat.com Wed Nov 19 14:44:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 15:44:53 +0100 Subject: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI In-Reply-To: <546C9174.1000809@redhat.com> References: <5464D303.9070103@redhat.com> <546C82C2.3010103@redhat.com> <546C9174.1000809@redhat.com> Message-ID: <546CACE5.6010400@redhat.com> On 19.11.2014 13:47, Martin Basti wrote: > On 19/11/14 12:45, Petr Vobornik wrote: >> On 13.11.2014 16:49, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4647 >>> Patch attached. >>> >> >> The change looses information about the zone apex record. User also >> might not know what is the message about because it lacks context. >> >> CLI option name as context is the cause of this bug but it could be >> replaced with, e.g., label. >> >> So what about: >> >> Semantic of setting Authoritative nameserver was changed. It's >> used only for setting the SOA MNAME attribute. >> >> NS record(s) can be edited in special zone apex record - '@'. >> > Updated patch attached. > > I used "NS record(s) can be edited in zone apex - '@'." instead of yours. > ACK Pushed to: master: 310e46452c41223afa0b1b318c503574567df105 ipa-4-1: 38130c632bda27711407f5c74f26031da5b52ad6 -- Petr Vobornik From pvoborni at redhat.com Wed Nov 19 14:48:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 15:48:18 +0100 Subject: [Freeipa-devel] [PATCH] 0673 Do not restore SELinux settings that were not backed up In-Reply-To: <546B2ABF.7020407@redhat.com> References: <546B2ABF.7020407@redhat.com> Message-ID: <546CADB2.3080700@redhat.com> On 18.11.2014 12:17, Petr Viktorin wrote: > This fixes https://fedorahosted.org/freeipa/ticket/4678 > ACK Pushed to: master: a14ce85357419f41f0994625d29d3f1af7a53d4c ipa-4-1: 1d7407c06caa06119635910d34213167d97125a0 -- Petr Vobornik From simo at redhat.com Wed Nov 19 14:57:23 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Nov 2014 09:57:23 -0500 Subject: [Freeipa-devel] [PATCH 0166] Workaround: warning if CA did not start at end of upgrade instead of raising error In-Reply-To: <546C600F.6070806@redhat.com> References: <546B9BF5.5000902@redhat.com> <546BB3B3.4040805@redhat.com> <546C600F.6070806@redhat.com> Message-ID: <20141119095724.30ca6417@willson.usersys.redhat.com> On Wed, 19 Nov 2014 10:17:03 +0100 Martin Basti wrote: > On 18/11/14 22:01, Martin Kosek wrote: > > On 11/18/2014 08:20 PM, Martin Basti wrote: > >> Ticket: https://fedorahosted.org/freeipa/ticket/4676 > >> > >> Attached patches: > >> > >> * Version A: uses wget to get status of CA > >> * Version B: write warning instead of raising exception (error is > >> false positive, CA is running) > >> > >> I'm open to suggestions which approach is better > >> > >> Martin^2 > >> > > > > I like A, but I am concerned why you suddenly ignore the use_proxy > > option. I added it for a reason as it affects to which port we need > > to connect, regardless the transport library. See > > > > https://fedorahosted.org/freeipa/ticket/3973 > > > > where I added this option. > > > > Second, I am not happy by you duplicating the XML parsing code, I > > would rather see it splited in dogtag.py in separate > > "_ca_status_parse" or similar function call. > > > > Given the obstacles, I am inclining for > > - pushing B as a safe fix for Fedora 21 Final > > - fixing issues in A and pushing it for minor release after that to > > avoid the nasty warning and have some reasonable medium-term fix > > until the framework migrates to something better than httpslib, > > line python-requests maybe. > > > > Martin > Sounds good to me. > > Patch required for F21 attached. (with proper number) > I will send the second patch after release for fedora (or should I > sooner?) Martin^2 > Ack. simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Wed Nov 19 17:51:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Nov 2014 18:51:14 +0100 Subject: [Freeipa-devel] [PATCH] 788 webui: fix potential XSS vulnerabilities Message-ID: <546CD892.7000102@redhat.com> Escape user defined text to prevent XSS attacks. Extra precaution was taken to escape also parts which are unlikely to contain user-defined text. https://fedorahosted.org/freeipa/ticket/4742 resolves CVE-2014-7850 f21 blocker candidate, requires priority review. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0788-webui-fix-potential-XSS-vulnerabilities.patch Type: text/x-patch Size: 5776 bytes Desc: not available URL: From simo at redhat.com Wed Nov 19 18:33:51 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Nov 2014 13:33:51 -0500 (EST) Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141119105301.GY3493@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> Message-ID: <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alexander Bokovoy" [...] > Regarding the patchset itself: > > Patch 0001: fix 'wuld' in the commit message. The rest is fine. Fixed. > Patch 0002: > - ticket number is missing in the commit message Added. > - perhaps, an instruction how to regenerate asn1 code can be made a > Makefile target? We don't need to call it ourselves but this would > simplify things in future Added make regenerate target to asn1c makefile > - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to > stderr but I guess this is something we currently cannot override > with DS-specific log printing, so no big deal right now ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we can later provide a replacement ASN_DEBUG function to hook debugging, but given the same code is used in both DS plugins and ipa-getkeytab binary I did not want to assume anything, and how to wire it up (if we even want to) should probably be discussed at a later time. > - any specific need to get asn1/compile committed? We don't commit it > in the client code (ipa-client/compile). Added 'compile' to .gitignore in second patch > Patch 0003: OK Nothing changed here. I also remembered the patch naming policy :-) so new patch names/numbers are 514,515,516, third revision. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-516-3-Use-asn1c-helpers-to-encode-decode-the-getkeytab-con.patch Type: text/x-patch Size: 25800 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-515-3-Add-asn1c-generated-code-for-keytab-controls.patch Type: text/x-patch Size: 363772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-514-3-Fix-filtering-of-enctypes-in-server-code.patch Type: text/x-patch Size: 3565 bytes Desc: not available URL: From npmccallum at redhat.com Wed Nov 19 21:16:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 19 Nov 2014 16:16:23 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> Message-ID: <1416431783.2902.0.camel@redhat.com> On Wed, 2014-11-19 at 13:33 -0500, Simo Sorce wrote: > ----- Original Message ----- > > From: "Alexander Bokovoy" > [...] > > > Regarding the patchset itself: > > > > Patch 0001: fix 'wuld' in the commit message. The rest is fine. > > Fixed. > > > Patch 0002: > > - ticket number is missing in the commit message > > Added. > > > - perhaps, an instruction how to regenerate asn1 code can be made a > > Makefile target? We don't need to call it ourselves but this would > > simplify things in future > > Added make regenerate target to asn1c makefile > > > - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to > > stderr but I guess this is something we currently cannot override > > with DS-specific log printing, so no big deal right now > > ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we can > later provide a replacement ASN_DEBUG function to hook debugging, but > given the same code is used in both DS plugins and ipa-getkeytab binary > I did not want to assume anything, and how to wire it up (if we even want > to) should probably be discussed at a later time. > > > - any specific need to get asn1/compile committed? We don't commit it > > in the client code (ipa-client/compile). > > Added 'compile' to .gitignore in second patch > > > Patch 0003: OK > > Nothing changed here. > > I also remembered the patch naming policy :-) so new patch names/numbers > are 514,515,516, third revision. ACK from me so long as abokovoy has nothing else. Nathaniel From dkupka at redhat.com Thu Nov 20 08:51:52 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 20 Nov 2014 09:51:52 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. Message-ID: <546DABA8.2040607@redhat.com> https://fedorahosted.org/freeipa/ticket/4620 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0030-Fix-user-group-ignore-attribute-in-migration-plugin.patch Type: text/x-patch Size: 1308 bytes Desc: not available URL: From mkosek at redhat.com Thu Nov 20 09:01:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Nov 2014 10:01:02 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DABA8.2040607@redhat.com> References: <546DABA8.2040607@redhat.com> Message-ID: <546DADCE.90505@redhat.com> On 11/20/2014 09:51 AM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4620 This should work fine, the change was also already tested by the reporter. Do we also normalize the user blacklist option so that it works if user passes for example a CamelCase'd attributes? Martin From jcholast at redhat.com Thu Nov 20 09:03:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 10:03:30 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DABA8.2040607@redhat.com> References: <546DABA8.2040607@redhat.com> Message-ID: <546DAE62.2080002@redhat.com> Dne 20.11.2014 v 09:51 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4620 IMO changing the loop to: for attr in attr_blacklist: entry_attrs.pop(attr, None) would be better, because LDAPEntry already handles case insensitivity in attribute names. -- Jan Cholasta From pviktori at redhat.com Thu Nov 20 09:12:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 10:12:01 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <546C88D7.5040504@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> <5465C391.7030003@redhat.com> <546C88D7.5040504@redhat.com> Message-ID: <546DB061.5030003@redhat.com> On 11/19/2014 01:11 PM, Tomas Babej wrote: > > On 11/14/2014 09:55 AM, Petr Viktorin wrote: >> On 10/29/2014 04:52 PM, Petr Viktorin wrote: >>> On 10/29/2014 01:22 PM, Tomas Babej wrote: >>>> >>>> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>>>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>>>> This almost completes the switch to pytest. There are two missing >>>>>> things: >>>>>> - the details of test results (--with-xunit) are not read >>>>>> correctly by >>>>>> Jenkins. I have a theory I'm investigating here. >>>>>> - the beakerlib integration is still not ready >>>>>> >>>>>> >>>>>> I'll not be available for the rest of the week so I'm sending this >>>>>> early, in case someone wants to take a look. >>>>> >>>>> I've updated (and rearranged) the patches after some more testing. >>>>> Both points above are fixed. Individual plugins are broken out; some >>>>> would be nice to even release independently of IPA. (There is some >>>>> demand for the BeakerLib plugin; for that I'd only need to break the >>>>> dependency on ipa_log_manager.) >>>>> >>>>> >>>>> These depend on my patches 0656-0660. >>>>> >>> >>>> Thanks for this effort! >>>> >>>> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names >>>> >>>> There are some references to the old names in the test_ipapython and >>>> test_install: >>>> >>>> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >>>> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >>>> [tbabej at thinkpad7 ipatests]$ git grep setUp >>>> test_install/test_updates.py: def setUp(self): >>>> test_ipapython/test_cookie.py: def setUp(self): >>>> test_ipapython/test_cookie.py: def setUp(self): >>>> test_ipapython/test_cookie.py: def setUp(self): >>>> test_ipapython/test_dn.py: def setUp(self): >>>> test_ipapython/test_dn.py: def setUp(self): >>>> test_ipapython/test_dn.py: def setUp(self): >>>> test_ipapython/test_dn.py: def setUp(self): >>>> test_ipapython/test_dn.py: def setUp(self): >>>> [tbabej at thinkpad7 ipatests]$ git grep tearDown >>>> test_install/test_updates.py: def tearDown(self): >>> >>> These are in unittest.testCase. It would be nice to convert those as >>> well, but that's for a larger cleanup. >>> >>>> #### Patch 0657: tests: Add configuration for pytest >>>> >>>> Shouldn't we rather change the class names? >>> >>> Ideally yes, but I don't think renaming most of our test classes would >>> be worth the benefit. >>> >>>> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >>>> get_subcls >>>> >>>> ACK. >>>> >>>> #### Patch 0659: test_automount_plugin: Fix test ordering >>>> >>>> ACK. >>>> >>>> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >>>> >>>> --- a/ipatests/test_ipaserver/test_changepw.py >>>> +++ b/ipatests/test_ipaserver/test_changepw.py >>>> @@ -33,8 +33,7 @@ >>>> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >>>> app_uri = '/ipa/session/change_password' >>>> >>>> - def setup(self): >>>> - super(test_changepw, self).setup() >>>> + def setup(cls): >>>> try: >>>> api.Command['user_add'](uid=testuser, >>>> givenname=u'Test', sn=u'User') >>>> api.Command['passwd'](testuser, >>>> password=u'old_password') >>>> @@ -43,12 +42,11 @@ def setup(self): >>>> 'Cannot set up test user: %s' % e >>>> ) >>>> >>>> - def teardown(self): >>>> + def teardown(cls): >>>> try: >>>> api.Command['user_del']([testuser]) >>>> except errors.NotFound: >>>> pass >>>> - super(test_changepw, self).teardown() >>>> >>>> The setup/teardown methods are not classmethods, so the name of the >>>> first argument should remain "self". >>> >>> Oops, thanks for the catch! >>> >>>> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for >>>> non-doctest >>>> examples >>>> >>>> ACK. >>>> >>>> #### PATCH 0662: test_webui: Don't use __init__ for test classes >>>> >>>> I don't think the following change will work: >>>> >>>> - def __init__(self, driver=None, config=None): >>>> + def setup(self, driver=None, config=None): >>>> self.request_timeout = 30 >>>> self.driver = driver >>>> self.config = config >>>> if not config: >>>> self.load_config() >>>> + self.get_driver().maximize_window() >>>> + >>>> + def teardown(self): >>>> + self.driver.quit() >>>> >>>> def load_config(self): >>>> """ >>>> @@ -161,20 +165,6 @@ def load_config(self): >>>> if 'type' not in c: >>>> c['type'] = DEFAULT_TYPE >>>> >>>> - def setup(self): >>>> - """ >>>> - Test setup >>>> - """ >>>> - if not self.driver: >>>> - self.driver = self.get_driver() >>>> - self.driver.maximize_window() >>>> - >>>> - def teardown(self): >>>> - """ >>>> - Test clean up >>>> - """ >>>> - self.driver.quit() >>>> >>>> >>>> The setup(self) method used to set the self.driver attribute on the >>>> class instance, now nothing sets it. The setup method should do: >>>> >>>> def setup(self, driver=None, config=None): >>>> self.request_timeout = 30 >>>> self.driver = driver >>>> self.config = config >>>> if not config: >>>> self.load_config() >>>> if not self.driver: >>>> self.driver = self.get_driver() >>>> self.driver.maximize_window() >>>> >>>> However, I would prefer having self.driver as a cached property. >>> >>> Well, ideally these would be fixtures. >>> >>> Thanks for the catch. >>> >>>> #### PATCH 0663: test_ipapython: Use functions instead of classes in >>>> test generators >>>> >>>> ACK. >>>> >>>> #### PATCH 0664: Configure pytest to run doctests >>>> >>>> ACK. >>>> >>>> #### PATCH 0665: Declarative tests: Move cleanup to >>>> setup_class/teardown_class >>>> >>>> You should also remove the now redundant cleanup_generate method. >>> >>> Right, removed. >>> >>>> Also: Do we really want to print out error.NotFound or >>>> errors.EmptyModList exceptions produced by cleanup commands? >>> >>> It's just one line, might help debugging. It should only show up on >>> failures. >>> >>>> #### PATCH 0666: Declarative tests: Switch to pytest >>>> >>>> Nitpitck: declarative.py has wrong year in the copyright header. >>>> Otherwise ACK. >>> >>> Fixed. >>> >>>> #### PATCH 0667: Integration tests: Port the ordering plugin to pytest >>>> >>>> Specfile change belongs to the previous patch, but I doubt these would >>>> be separated, so not worth spending the time IMHO. >>> >>> Also, the previous patch doesn't actually import pytest. But a lot of >>> these patches break tests by themselves, so they shouldn't be separated. >>> >>>> Why does TestIPACommands have ordered decorator applied? It is applied >>>> on IntegrationTest directly, from which CALessBase inherits from. I >>>> don't think it's necessary (unless I'm missing something), so we should >>>> rather remove the occurence of the decorator in the test_caless.py than >>>> fixing the import. >>> >>> Actually, I think only only the classes that actually need it should >>> have the decorator. >>> Again, cleanup for a future time. >>> >>>> #### PATCH 0668: Switch make-test to pytest >>>> >>>> Nice simplification. However, make-test does not work for me: >>>> >>>> I'm getting tons of errors (during the collection) along the lines of: >>>> >>>> ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py >>>> _________________ >>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>> pyimport >>>> raise self.ImportMismatchError(modname, modfile, self) >>>> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >>>> _______________ ERROR collecting >>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>> pyimport >>>> raise self.ImportMismatchError(modname, modfile, self) >>>> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >>>> _______________ ERROR collecting >>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>> import file mismatch: >>>> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >>>> __file__ attribute: >>>> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >>>> which is not the same as the test file we want to collect: >>>> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >>>> HINT: remove __pycache__ / .pyc files and/or use a unique basename >>>> for your test file modules >>>> ================ 163 passed, 7 skipped, 679 error in 48.14 seconds >>>> ============== >>>> >>>> >>>> I am running this as ./make-test from the directory containing the >>>> freeipa sources. The ipa-run-tests command seems to work fine though. >>> >>> Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? >>> I've added . to PYTHONPATH, that may help (and it should also help with >>> plugin loading in some cases). >>> >>>> #### PATCH 0669: Add local pytest plugin for --with-xunit and >>>> --logging-level >>>> >>>> ACK. >>>> >>>> #### PATCH 0670: Switch ipa-run-tests to pytest >>>> >>>> ACK. >>>> >>>> #### PATCH 0671: Switch integration testing config to a fixture >>>> >>>> ACK. >>>> >>>> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >>>> collection to pytest >>>> >>>> I didn't see any glitches, but I haven't tested this one out yet >>>> functionally. >>>> >>>> ### General notes >>>> >>>> I did two IPA master installs today, one with your patches applied. >>>> There were significant differences in the number of successfully >>>> passing >>>> tests: >>>> >>>> nose: FAILED (SKIP=60, errors=46, failures=14) >>>> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >>>> 860.47 seconds ========= >>>> >>>> Did you not encounter this in your testing? I will look more deeply >>>> into >>>> the failures themselves. >>> >>> I did, but it was always some stupid mistake :) >>> Do you have ~/.ipa set up, and $MASTER undefined? >>> >>> The integration test did fail for me now when they were not configured. >>> I added an additional patch to fix that. >> >> Ping, could you look at the updated patches? >> >> > > Sure, but the patchset requires a rebase. > Rebased onto master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0656.4-tests-Use-PEP8-compliant-setup-teardown-method-names.patch Type: text/x-patch Size: 20304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0657.4-tests-Add-configuration-for-pytest.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0658.4-ipatests.util.ClassChecker-Raise-AttributeError-in-g.patch Type: text/x-patch Size: 878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0659.4-test_automount_plugin-Fix-test-ordering.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0660.4-Use-setup_class-teardown_class-in-Declarative-tests.patch Type: text/x-patch Size: 4907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0661.4-dogtag-plugin-Don-t-use-doctest-syntax-for-non-docte.patch Type: text/x-patch Size: 2523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0662.4-test_webui-Don-t-use-__init__-for-test-classes.patch Type: text/x-patch Size: 6780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0663.4-test_ipapython-Use-functions-instead-of-classes-in-t.patch Type: text/x-patch Size: 3192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0664.4-Configure-pytest-to-run-doctests.patch Type: text/x-patch Size: 3135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0665.4-Declarative-tests-Move-cleanup-to-setup_class-teardo.patch Type: text/x-patch Size: 2829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0666.4-Declarative-tests-Switch-to-pytest.patch Type: text/x-patch Size: 5130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0667.4-Integration-tests-Port-the-ordering-plugin-to-pytest.patch Type: text/x-patch Size: 12864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0668.4-Switch-make-test-to-pytest.patch Type: text/x-patch Size: 2058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0669.4-Add-local-pytest-plugin-for-with-xunit-and-logging-l.patch Type: text/x-patch Size: 4507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0670.4-Switch-ipa-run-tests-to-pytest.patch Type: text/x-patch Size: 3002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0671.4-Switch-integration-testing-config-to-a-fixture.patch Type: text/x-patch Size: 8104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0672.4-Integration-tests-Port-the-BeakerLib-plugin-and-log-.patch Type: text/x-patch Size: 30085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0673.4-test_integration-Adjust-tests-for-pytest.patch Type: text/x-patch Size: 5933 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 20 09:33:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Nov 2014 10:33:42 +0100 Subject: [Freeipa-devel] [PATCH 0166] Workaround: warning if CA did not start at end of upgrade instead of raising error In-Reply-To: <20141119095724.30ca6417@willson.usersys.redhat.com> References: <546B9BF5.5000902@redhat.com> <546BB3B3.4040805@redhat.com> <546C600F.6070806@redhat.com> <20141119095724.30ca6417@willson.usersys.redhat.com> Message-ID: <546DB576.5020301@redhat.com> On 19.11.2014 15:57, Simo Sorce wrote: > On Wed, 19 Nov 2014 10:17:03 +0100 > Martin Basti wrote: >>> >>> Given the obstacles, I am inclining for >>> - pushing B as a safe fix for Fedora 21 Final >>> - fixing issues in A and pushing it for minor release after that to >>> avoid the nasty warning and have some reasonable medium-term fix >>> until the framework migrates to something better than httpslib, >>> line python-requests maybe. >>> >>> Martin >> Sounds good to me. >> >> Patch required for F21 attached. (with proper number) >> I will send the second patch after release for fedora (or should I >> sooner?) Martin^2 >> > > Ack. > > simo. > Pushed to: master: 43285b1fc3da7ab0c0fe411295e53a45f9a42106 ipa-4-1: 3f3f49ea93f8ca0c2cdd569a78c952492e7b520a -- Petr Vobornik From abokovoy at redhat.com Thu Nov 20 10:36:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Nov 2014 12:36:45 +0200 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> Message-ID: <20141120103645.GA3493@redhat.com> On Wed, 19 Nov 2014, Simo Sorce wrote: >----- Original Message ----- >> From: "Alexander Bokovoy" >[...] > >> Regarding the patchset itself: >> >> Patch 0001: fix 'wuld' in the commit message. The rest is fine. > >Fixed. > >> Patch 0002: >> - ticket number is missing in the commit message > >Added. > >> - perhaps, an instruction how to regenerate asn1 code can be made a >> Makefile target? We don't need to call it ourselves but this would >> simplify things in future > >Added make regenerate target to asn1c makefile > >> - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to >> stderr but I guess this is something we currently cannot override >> with DS-specific log printing, so no big deal right now > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we can >later provide a replacement ASN_DEBUG function to hook debugging, but >given the same code is used in both DS plugins and ipa-getkeytab binary >I did not want to assume anything, and how to wire it up (if we even want >to) should probably be discussed at a later time. > >> - any specific need to get asn1/compile committed? We don't commit it >> in the client code (ipa-client/compile). > >Added 'compile' to .gitignore in second patch > >> Patch 0003: OK > >Nothing changed here. > >I also remembered the patch naming policy :-) so new patch names/numbers >are 514,515,516, third revision. Thanks. The only complaint I have left is number of whitespace errors that git says are in the 515th patch. Otherwise, ACK. I've tested it again and everything works except getting stronger than asked TGT enctype but this is not an issue with getkeytab controls. -- / Alexander Bokovoy From dkupka at redhat.com Thu Nov 20 10:53:06 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 20 Nov 2014 11:53:06 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DAE62.2080002@redhat.com> References: <546DABA8.2040607@redhat.com> <546DAE62.2080002@redhat.com> Message-ID: <546DC812.6050605@redhat.com> On 11/20/2014 10:03 AM, Jan Cholasta wrote: > Dne 20.11.2014 v 09:51 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4620 > > IMO changing the loop to: > > for attr in attr_blacklist: > entry_attrs.pop(attr, None) > > would be better, because LDAPEntry already handles case insensitivity in > attribute names. > This seems better, thanks. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0030-2-Fix-user-group-ignore-attribute-in-migration-plugin.patch Type: text/x-patch Size: 1566 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 20 10:54:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 11:54:07 +0100 Subject: [Freeipa-devel] [PATCH] 0655 Add additional backup & restore checks In-Reply-To: <54354D11.4080501@redhat.com> References: <54354D11.4080501@redhat.com> Message-ID: <546DC84F.8000800@redhat.com> On 10/08/2014 04:41 PM, Petr Viktorin wrote: > This adds basic checks that PAM, DNS, and Kerberos are working before & > after the backup&restore (in addition to DS, CA & IPA CLI that were > there before). Ping, can someone review this patch? -- Petr? From mbasti at redhat.com Thu Nov 20 11:25:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Nov 2014 12:25:43 +0100 Subject: [Freeipa-devel] [PATCH] 0655 Add additional backup & restore checks In-Reply-To: <546DC84F.8000800@redhat.com> References: <54354D11.4080501@redhat.com> <546DC84F.8000800@redhat.com> Message-ID: <546DCFB7.4070609@redhat.com> On 20/11/14 11:54, Petr Viktorin wrote: > On 10/08/2014 04:41 PM, Petr Viktorin wrote: >> This adds basic checks that PAM, DNS, and Kerberos are working before & >> after the backup&restore (in addition to DS, CA & IPA CLI that were >> there before). > > Ping, can someone review this patch? > > I will review it. Martin^2 -- Martin Basti From abokovoy at redhat.com Thu Nov 20 11:59:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Nov 2014 13:59:00 +0200 Subject: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1 In-Reply-To: <546C9AD6.8060408@redhat.com> References: <546B964D.5000804@redhat.com> <1416349744.3141.32.camel@redhat.com> <546C9348.9040001@redhat.com> <546C9433.2070601@redhat.com> <546C9622.3050202@redhat.com> <546C9AD6.8060408@redhat.com> Message-ID: <20141120115900.GB3493@redhat.com> On Wed, 19 Nov 2014, Jan Cholasta wrote: >Dne 19.11.2014 v 14:07 Petr Vobornik napsal(a): >>On 19.11.2014 13:59, Jan Cholasta wrote: >>>Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): >>>>On 18.11.2014 23:29, Nathaniel McCallum wrote: >>>>>On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: >>>>>>Hi, >>>>>> >>>>>>the attached patch fixes >>>>>>. >>>>> >>>>>ACK >>>>> >>>> >>>>Shouldn't the version be 10.1.2-4 ? >>>> >>>>http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 >>> >>>No. >>> >> >>ok, nevermind, f21 has 10.2.1-0.1, but it doesn't list the fix in the >>changelog. >> >>But the patch needs a rebase because of Martin's patch. >> >>http://koji.fedoraproject.org/koji/buildinfo?buildID=588670 > >Rebased and pushed to ipa-4-1: 4e1193119b3e7f7c13f504f24445509958887927 I don't see 10.2.1-0.1 in Fedora 21. We have to remove this patch in the Fedora 21 packages because we are not going to get pki-ca FreezeException for this issue. Once F21 is released, we'll re-add the dependency in a subsequent build. https://admin.fedoraproject.org/updates/search/pki-core -- / Alexander Bokovoy From mkosek at redhat.com Thu Nov 20 12:09:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Nov 2014 13:09:08 +0100 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 Message-ID: <546DD9E4.3070807@redhat.com> Hello, We seem to have enough content to release 4.1.2 that will be required to fix some of the Fedora 21 blockers: https://bugzilla.redhat.com/show_bug.cgi?id=1165856 https://bugzilla.redhat.com/show_bug.cgi?id=1165261 and Freeze exception: https://bugzilla.redhat.com/show_bug.cgi?id=1165674 Current plan is to release stabilization release 4.1.2 with what we have as it contains the important installation and upgrade fixes. The only problem there is that some patches require components that are not in Fedora stable repos, more specifically commits: 7aa855a3 -> requiring new certmonger 4e119311 -> requiring new pki-core We can release 4.1.2 with them, but they would need to be removed from Fedora 21 downstream release and added back in normal 0day Fedora 21 update. Alternative way would be to just include selected patches for existing Fedora 21 build. Any comments, what else are missing in 4.1.2? I only know about https://fedorahosted.org/freeipa/ticket/4718 https://fedorahosted.org/freeipa/ticket/4728 which is ACKed at the moment, AFAIK. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From abokovoy at redhat.com Thu Nov 20 12:26:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Nov 2014 14:26:44 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <546DD9E4.3070807@redhat.com> References: <546DD9E4.3070807@redhat.com> Message-ID: <20141120122644.GC3493@redhat.com> On Thu, 20 Nov 2014, Martin Kosek wrote: >Hello, > >We seem to have enough content to release 4.1.2 that will be required to fix >some of the Fedora 21 blockers: > >https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >https://bugzilla.redhat.com/show_bug.cgi?id=1165261 > >and Freeze exception: >https://bugzilla.redhat.com/show_bug.cgi?id=1165674 > >Current plan is to release stabilization release 4.1.2 with what we have as it >contains the important installation and upgrade fixes. > >The only problem there is that some patches require components that are not in >Fedora stable repos, more specifically commits: > >7aa855a3 -> requiring new certmonger >4e119311 -> requiring new pki-core > >We can release 4.1.2 with them, but they would need to be removed from Fedora >21 downstream release and added back in normal 0day Fedora 21 update. >Alternative way would be to just include selected patches for existing Fedora >21 build. > >Any comments, what else are missing in 4.1.2? I only know about >https://fedorahosted.org/freeipa/ticket/4718 >https://fedorahosted.org/freeipa/ticket/4728 >which is ACKed at the moment, AFAIK. certmonger and pki-core parts can be backed out in the F21 build, they don't create issues for install time -- by definition we are not renewing certs at that point and we are not supporting becoming MS CA subordinate in the FreeIPA Server Role. Thus, we can do the release without them to Fedora 21 (and with them to rawhide) and have 0day update. -- / Alexander Bokovoy From jcholast at redhat.com Thu Nov 20 13:11:34 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 14:11:34 +0100 Subject: [Freeipa-devel] [PATCH] 375 Restore file extended attributes and SELinux context in ipa-restore Message-ID: <546DE886.9060903@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-375-Restore-file-extended-attributes-and-SELinux-context.patch Type: text/x-patch Size: 1091 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 20 13:31:38 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Nov 2014 14:31:38 +0100 Subject: [Freeipa-devel] [PATCH] 0655 Add additional backup & restore checks In-Reply-To: <546DCFB7.4070609@redhat.com> References: <54354D11.4080501@redhat.com> <546DC84F.8000800@redhat.com> <546DCFB7.4070609@redhat.com> Message-ID: <546DED3A.9030501@redhat.com> On 20/11/14 12:25, Martin Basti wrote: > On 20/11/14 11:54, Petr Viktorin wrote: >> On 10/08/2014 04:41 PM, Petr Viktorin wrote: >>> This adds basic checks that PAM, DNS, and Kerberos are working before & >>> after the backup&restore (in addition to DS, CA & IPA CLI that were >>> there before). >> >> Ping, can someone review this patch? >> >> > I will review it. > Martin^2 > ACK, works fine -- Martin Basti From mbasti at redhat.com Thu Nov 20 13:51:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Nov 2014 14:51:36 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DC812.6050605@redhat.com> References: <546DABA8.2040607@redhat.com> <546DAE62.2080002@redhat.com> <546DC812.6050605@redhat.com> Message-ID: <546DF1E8.6050708@redhat.com> On 20/11/14 11:53, David Kupka wrote: > On 11/20/2014 10:03 AM, Jan Cholasta wrote: >> Dne 20.11.2014 v 09:51 David Kupka napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4620 >> >> IMO changing the loop to: >> >> for attr in attr_blacklist: >> entry_attrs.pop(attr, None) >> >> would be better, because LDAPEntry already handles case insensitivity in >> attribute names. >> > This seems better, thanks. > > IMO the same problem is with objectclasses. # do not migrate all object classes if 'objectclass' in entry_attrs: for object_class in kwargs.get('oc_blacklist', []): try: entry_attrs['objectclass'].remove(object_class) # this is case sensitive except ValueError: # object class not present pass Am I right? Martin^2 -- Martin Basti From simo at redhat.com Thu Nov 20 14:12:04 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Nov 2014 09:12:04 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141120103645.GA3493@redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> Message-ID: <20141120091204.5202a09e@willson.usersys.redhat.com> On Thu, 20 Nov 2014 12:36:45 +0200 Alexander Bokovoy wrote: > On Wed, 19 Nov 2014, Simo Sorce wrote: > >----- Original Message ----- > >> From: "Alexander Bokovoy" > >[...] > > > >> Regarding the patchset itself: > >> > >> Patch 0001: fix 'wuld' in the commit message. The rest is fine. > > > >Fixed. > > > >> Patch 0002: > >> - ticket number is missing in the commit message > > > >Added. > > > >> - perhaps, an instruction how to regenerate asn1 code can be made > >> a Makefile target? We don't need to call it ourselves but this > >> would simplify things in future > > > >Added make regenerate target to asn1c makefile > > > >> - I'm little uncomfortable how ASN_DEBUG() output goes explicitly > >> to stderr but I guess this is something we currently cannot > >> override with DS-specific log printing, so no big deal right now > > > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we > >can later provide a replacement ASN_DEBUG function to hook > >debugging, but given the same code is used in both DS plugins and > >ipa-getkeytab binary I did not want to assume anything, and how to > >wire it up (if we even want to) should probably be discussed at a > >later time. > > > >> - any specific need to get asn1/compile committed? We don't > >> commit it in the client code (ipa-client/compile). > > > >Added 'compile' to .gitignore in second patch > > > >> Patch 0003: OK > > > >Nothing changed here. > > > >I also remembered the patch naming policy :-) so new patch > >names/numbers are 514,515,516, third revision. > Thanks. The only complaint I have left is number of whitespace errors > that git says are in the 515th patch. Yeah the autogenerated code is not a pretty sight style-wise, do we want to run an automatic indenter on it ? I was hesitant to do so, but I wouldn't mind adding that, if we feel strongly about it. > Otherwise, ACK. I've tested it again and everything works except > getting stronger than asked TGT enctype but this is not an issue with > getkeytab controls. ok, Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Nov 20 14:15:57 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Nov 2014 15:15:57 +0100 Subject: [Freeipa-devel] [PATCH] 789 restore: clear httpd ccache after restore Message-ID: <546DF79D.6000001@redhat.com> so that httpd ccache won't contain old credentials which would make ipa CLI fail with error: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Decrypt integrity check failed) https://fedorahosted.org/freeipa/ticket/4726 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0789-restore-clear-httpd-ccache-after-restore.patch Type: text/x-patch Size: 1208 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 20 14:19:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Nov 2014 09:19:08 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141120091204.5202a09e@willson.usersys.redhat.com> References: <20141118000120.23536867@willson.usersys.redhat.com> <1416327822.3141.17.camel@redhat.com> <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> <20141120091204.5202a09e@willson.usersys.redhat.com> Message-ID: <1416493148.2902.7.camel@redhat.com> On Thu, 2014-11-20 at 09:12 -0500, Simo Sorce wrote: > On Thu, 20 Nov 2014 12:36:45 +0200 > Alexander Bokovoy wrote: > > > On Wed, 19 Nov 2014, Simo Sorce wrote: > > >----- Original Message ----- > > >> From: "Alexander Bokovoy" > > >[...] > > > > > >> Regarding the patchset itself: > > >> > > >> Patch 0001: fix 'wuld' in the commit message. The rest is fine. > > > > > >Fixed. > > > > > >> Patch 0002: > > >> - ticket number is missing in the commit message > > > > > >Added. > > > > > >> - perhaps, an instruction how to regenerate asn1 code can be made > > >> a Makefile target? We don't need to call it ourselves but this > > >> would simplify things in future > > > > > >Added make regenerate target to asn1c makefile > > > > > >> - I'm little uncomfortable how ASN_DEBUG() output goes explicitly > > >> to stderr but I guess this is something we currently cannot > > >> override with DS-specific log printing, so no big deal right now > > > > > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we > > >can later provide a replacement ASN_DEBUG function to hook > > >debugging, but given the same code is used in both DS plugins and > > >ipa-getkeytab binary I did not want to assume anything, and how to > > >wire it up (if we even want to) should probably be discussed at a > > >later time. > > > > > >> - any specific need to get asn1/compile committed? We don't > > >> commit it in the client code (ipa-client/compile). > > > > > >Added 'compile' to .gitignore in second patch > > > > > >> Patch 0003: OK > > > > > >Nothing changed here. > > > > > >I also remembered the patch naming policy :-) so new patch > > >names/numbers are 514,515,516, third revision. > > Thanks. The only complaint I have left is number of whitespace errors > > that git says are in the 515th patch. > > Yeah the autogenerated code is not a pretty sight style-wise, do we > want to run an automatic indenter on it ? > I was hesitant to do so, but I wouldn't mind adding that, if we feel > strongly about it. Let's please not try to correct autogenerated code. > > Otherwise, ACK. I've tested it again and everything works except > > getting stronger than asked TGT enctype but this is not an issue with > > getkeytab controls. From jcholast at redhat.com Thu Nov 20 14:21:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 15:21:14 +0100 Subject: [Freeipa-devel] [PATCH] 376 Stop tracking certificates before restoring them in ipa-restore Message-ID: <546DF8DA.4060604@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-376-Stop-tracking-certificates-before-restoring-them-in-.patch Type: text/x-patch Size: 2189 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-376-Stop-tracking-certificates-before-restoring-them-in--ipa-4-1.patch Type: text/x-patch Size: 2176 bytes Desc: not available URL: From jcholast at redhat.com Thu Nov 20 14:25:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 15:25:44 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DF1E8.6050708@redhat.com> References: <546DABA8.2040607@redhat.com> <546DAE62.2080002@redhat.com> <546DC812.6050605@redhat.com> <546DF1E8.6050708@redhat.com> Message-ID: <546DF9E8.5010108@redhat.com> Dne 20.11.2014 v 14:51 Martin Basti napsal(a): > On 20/11/14 11:53, David Kupka wrote: >> On 11/20/2014 10:03 AM, Jan Cholasta wrote: >>> Dne 20.11.2014 v 09:51 David Kupka napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4620 >>> >>> IMO changing the loop to: >>> >>> for attr in attr_blacklist: >>> entry_attrs.pop(attr, None) >>> >>> would be better, because LDAPEntry already handles case insensitivity in >>> attribute names. >>> >> This seems better, thanks. >> >> > IMO the same problem is with objectclasses. > > > # do not migrate all object classes > if 'objectclass' in entry_attrs: > for object_class in kwargs.get('oc_blacklist', []): > try: > entry_attrs['objectclass'].remove(object_class) # > this is case sensitive > except ValueError: # object class not present > pass > > Am I right? Yes. LDAPEntry does not support case insensitivity in this case, although I plan to implement it in 4.2. -- Jan Cholasta From mbasti at redhat.com Thu Nov 20 14:35:33 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Nov 2014 15:35:33 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DF9E8.5010108@redhat.com> References: <546DABA8.2040607@redhat.com> <546DAE62.2080002@redhat.com> <546DC812.6050605@redhat.com> <546DF1E8.6050708@redhat.com> <546DF9E8.5010108@redhat.com> Message-ID: <546DFC35.8000704@redhat.com> On 20/11/14 15:25, Jan Cholasta wrote: > Dne 20.11.2014 v 14:51 Martin Basti napsal(a): >> On 20/11/14 11:53, David Kupka wrote: >>> On 11/20/2014 10:03 AM, Jan Cholasta wrote: >>>> Dne 20.11.2014 v 09:51 David Kupka napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4620 >>>> >>>> IMO changing the loop to: >>>> >>>> for attr in attr_blacklist: >>>> entry_attrs.pop(attr, None) >>>> >>>> would be better, because LDAPEntry already handles case >>>> insensitivity in >>>> attribute names. >>>> >>> This seems better, thanks. >>> >>> >> IMO the same problem is with objectclasses. >> >> >> # do not migrate all object classes >> if 'objectclass' in entry_attrs: >> for object_class in kwargs.get('oc_blacklist', []): >> try: >> entry_attrs['objectclass'].remove(object_class) # >> this is case sensitive >> except ValueError: # object class not present >> pass >> >> Am I right? > > Yes. LDAPEntry does not support case insensitivity in this case, > although I plan to implement it in 4.2. > objectclasses are normalized to lowercase before, so it is not a issue. The patch works fine, ACK :-) . -- Martin Basti From tbabej at redhat.com Thu Nov 20 14:38:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Nov 2014 15:38:04 +0100 Subject: [Freeipa-devel] [PATCH] 788 webui: fix potential XSS vulnerabilities In-Reply-To: <546CD892.7000102@redhat.com> References: <546CD892.7000102@redhat.com> Message-ID: <546DFCCC.4080704@redhat.com> On 11/19/2014 06:51 PM, Petr Vobornik wrote: > Escape user defined text to prevent XSS attacks. Extra precaution was > taken to escape also parts which are unlikely to contain user-defined > text. > > https://fedorahosted.org/freeipa/ticket/4742 > > resolves CVE-2014-7850 > > f21 blocker candidate, requires priority review. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Resolves issue described in CVE-2014-7850. Pushed to: master: bff97e8b2e8d80e75e989b661e873c8e72cd7429 ipa-4-1: af9fd4dfe2c18e52127480c959c35ad37b566095 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Nov 20 14:42:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 15:42:07 +0100 Subject: [Freeipa-devel] [PATCH 0167] DNS: Raise proper exception instead UnicodeError In-Reply-To: <546CA3D7.20408@redhat.com> References: <546CA3D7.20408@redhat.com> Message-ID: <546DFDBF.7040108@redhat.com> Hi, Dne 19.11.2014 v 15:06 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4734 > Patch attached. ACK, pushed to: master: c80a59eff479dbdc26eaaa18f18256f1f7471880 ipa-4-1: 1a6de2a9281fa239e5d51062692f18981a4c22ca Honza -- Jan Cholasta From abokovoy at redhat.com Thu Nov 20 14:47:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Nov 2014 16:47:29 +0200 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <1416493148.2902.7.camel@redhat.com> References: <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> <20141120091204.5202a09e@willson.usersys.redhat.com> <1416493148.2902.7.camel@redhat.com> Message-ID: <20141120144729.GE3493@redhat.com> On Thu, 20 Nov 2014, Nathaniel McCallum wrote: >On Thu, 2014-11-20 at 09:12 -0500, Simo Sorce wrote: >> On Thu, 20 Nov 2014 12:36:45 +0200 >> Alexander Bokovoy wrote: >> >> > On Wed, 19 Nov 2014, Simo Sorce wrote: >> > >----- Original Message ----- >> > >> From: "Alexander Bokovoy" >> > >[...] >> > > >> > >> Regarding the patchset itself: >> > >> >> > >> Patch 0001: fix 'wuld' in the commit message. The rest is fine. >> > > >> > >Fixed. >> > > >> > >> Patch 0002: >> > >> - ticket number is missing in the commit message >> > > >> > >Added. >> > > >> > >> - perhaps, an instruction how to regenerate asn1 code can be made >> > >> a Makefile target? We don't need to call it ourselves but this >> > >> would simplify things in future >> > > >> > >Added make regenerate target to asn1c makefile >> > > >> > >> - I'm little uncomfortable how ASN_DEBUG() output goes explicitly >> > >> to stderr but I guess this is something we currently cannot >> > >> override with DS-specific log printing, so no big deal right now >> > > >> > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we >> > >can later provide a replacement ASN_DEBUG function to hook >> > >debugging, but given the same code is used in both DS plugins and >> > >ipa-getkeytab binary I did not want to assume anything, and how to >> > >wire it up (if we even want to) should probably be discussed at a >> > >later time. >> > > >> > >> - any specific need to get asn1/compile committed? We don't >> > >> commit it in the client code (ipa-client/compile). >> > > >> > >Added 'compile' to .gitignore in second patch >> > > >> > >> Patch 0003: OK >> > > >> > >Nothing changed here. >> > > >> > >I also remembered the patch naming policy :-) so new patch >> > >names/numbers are 514,515,516, third revision. >> > Thanks. The only complaint I have left is number of whitespace errors >> > that git says are in the 515th patch. >> >> Yeah the autogenerated code is not a pretty sight style-wise, do we >> want to run an automatic indenter on it ? >> I was hesitant to do so, but I wouldn't mind adding that, if we feel >> strongly about it. > >Let's please not try to correct autogenerated code. I'm not tied to this but Simo now thinks it is better to run indenter in the generator rule as this will give less problems in actual comparison noise that git diff would give. I'll make sure to talk back to asn1c author to see if we can improve its generators upstream. -- / Alexander Bokovoy From pviktori at redhat.com Thu Nov 20 14:48:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 15:48:33 +0100 Subject: [Freeipa-devel] [PATCH] 0655 Add additional backup & restore checks In-Reply-To: <546DED3A.9030501@redhat.com> References: <54354D11.4080501@redhat.com> <546DC84F.8000800@redhat.com> <546DCFB7.4070609@redhat.com> <546DED3A.9030501@redhat.com> Message-ID: <546DFF41.5090505@redhat.com> On 11/20/2014 02:31 PM, Martin Basti wrote: > On 20/11/14 12:25, Martin Basti wrote: >> On 20/11/14 11:54, Petr Viktorin wrote: >>> On 10/08/2014 04:41 PM, Petr Viktorin wrote: >>>> This adds basic checks that PAM, DNS, and Kerberos are working before & >>>> after the backup&restore (in addition to DS, CA & IPA CLI that were >>>> there before). >>> >>> Ping, can someone review this patch? >>> >>> >> I will review it. >> Martin^2 >> > ACK, > > works fine Thank you! Pushed to: master: 93422a54a3ab4e15decbab0b098fd44479b459f7 ipa-4-1: 768cccdefd803f34a88dd29a78130f316c1bd6a9 -- Petr? From abokovoy at redhat.com Thu Nov 20 14:49:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Nov 2014 16:49:33 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <20141120122644.GC3493@redhat.com> References: <546DD9E4.3070807@redhat.com> <20141120122644.GC3493@redhat.com> Message-ID: <20141120144933.GF3493@redhat.com> On Thu, 20 Nov 2014, Alexander Bokovoy wrote: >On Thu, 20 Nov 2014, Martin Kosek wrote: >>Hello, >> >>We seem to have enough content to release 4.1.2 that will be required to fix >>some of the Fedora 21 blockers: >> >>https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >>https://bugzilla.redhat.com/show_bug.cgi?id=1165261 >> >>and Freeze exception: >>https://bugzilla.redhat.com/show_bug.cgi?id=1165674 >> >>Current plan is to release stabilization release 4.1.2 with what we have as it >>contains the important installation and upgrade fixes. >> >>The only problem there is that some patches require components that are not in >>Fedora stable repos, more specifically commits: >> >>7aa855a3 -> requiring new certmonger >>4e119311 -> requiring new pki-core >> >>We can release 4.1.2 with them, but they would need to be removed from Fedora >>21 downstream release and added back in normal 0day Fedora 21 update. >>Alternative way would be to just include selected patches for existing Fedora >>21 build. >> >>Any comments, what else are missing in 4.1.2? I only know about >>https://fedorahosted.org/freeipa/ticket/4718 >>https://fedorahosted.org/freeipa/ticket/4728 >>which is ACKed at the moment, AFAIK. > >certmonger and pki-core parts can be backed out in the F21 build, they >don't create issues for install time -- by definition we are not >renewing certs at that point and we are not supporting becoming MS CA >subordinate in the FreeIPA Server Role. > >Thus, we can do the release without them to Fedora 21 (and with them to >rawhide) and have 0day update. It looks like we'll have to pick up required fixes and do a build with just them for Fedora 21 final to make sure we don't violate release rules. We can do the full release after it and push it to updates-testing once stable updates consumed the fixed build for the Fedora 21 release. -- / Alexander Bokovoy From jcholast at redhat.com Thu Nov 20 15:01:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Nov 2014 16:01:36 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546CA539.2050005@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> <546CA539.2050005@redhat.com> Message-ID: <546E0250.5000401@redhat.com> Dne 19.11.2014 v 15:12 Tomas Babej napsal(a): > > On 11/19/2014 02:03 PM, Jan Cholasta wrote: >> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >>> >>> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>>>> rather than search on unexistant containers (which can happen >>>>>>> with get_dn). >>>>>>> >>>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>>> and makes sure proper error message is raised. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>>> Doesn't it produce extra LDAP search thus making all our search >>>>>> commands >>>>>> slower? Is that what we want? >>>>> No it does not make all of our LDAP search slower. It only happens for >>>>> the objects that have parent objects, such as idoverrides or >>>>> dnsrecords. >>>> ... and makes them slower. >>> >>> What I was pointing out here is that this is not a issue for ALL *-find >>> commands (e.g user-find, group-find will not suffer from it), as you >>> incorrectly stated. >>> >>>> >>>>>> Wouldn't it be better to distinguish between LDAP >>>>>> search with no results and LDAP search with missing parent DN? The >>>>>> reply looks >>>>>> different, at least in CLI: >>>>> Up to discussion. We would probably need to introduce a new exception, >>>>> like ParentObjectNotFound. >>>>> >>>>>> # search result >>>>>> search: 4 >>>>>> result: 0 Success >>>>>> >>>>>> # search result >>>>>> search: 4 >>>>>> result: 32 No such object >>>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>>> >>>>>> Also, I do not think you can just stop using get_dn(), some >>>>>> commands override >>>>>> this call to get more complex searches (like host-find searching >>>>>> for shortname). >>>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>>> issue >>>>> here. Any custom behaviour is preserved. >>>> Ah, ok, thanks for info. >>>> >>>>> To sum up, I think this is worth changing this behaviour by default, >>>>> ignoring a non-matching value of the parent object is not a correct >>>>> general approach in my opinion. >>>> Well, that's the question. Whether we would leave DS to validate the >>>> search >>>> itself or do all the pre-check ourselves. To me, doing just one LDAP >>>> search and >>>> processing the error correctly looks better. But I can live even >>>> with your >>>> version then, I will leave the framework guardians like Honza or >>>> Petr3 to decide. >> >> +1 on single LDAP search and proper error processing. >> >>> >>> I see now what you're trying to suggest. However, the reason boils >>> down to ipaldap.find_entries method not differentiating between a >>> LDAP search that returns error code 32 (No such object) and LDAP >>> search returning error code 0 (Success), but returning no results. >>> >>> In both cases errors.NotFound is raised. >>> >>> The reason I did not go this way is that changing the find_entries >>> method >>> is quite more invasive as this is the method subsenqently called by >>> almost >>> any command. >> >> You can always derive the new error (ParentNotFound or whatever) on >> NotFound, so old code won't break. >> > > Thanks for the suggestsions. > > Attached is a new patch which hooks into find_entries method and > differentiates between the cases. > Why are you special casing base scope search? -- Jan Cholasta From dkupka at redhat.com Thu Nov 20 15:31:36 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 20 Nov 2014 16:31:36 +0100 Subject: [Freeipa-devel] [PATCH 0163] Fix compiler warning for pk11helper module In-Reply-To: <546472F3.7000002@redhat.com> References: <546374E2.2040205@redhat.com> <546472F3.7000002@redhat.com> Message-ID: <546E0958.5060509@redhat.com> On 11/13/2014 09:59 AM, Martin Basti wrote: > On 12/11/14 15:55, Martin Basti wrote: >> Part of ticket: https://fedorahosted.org/freeipa/ticket/4657 >> > And here is the patch, sorry :-) > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, thanks, ACK. -- David Kupka From pviktori at redhat.com Thu Nov 20 15:44:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 16:44:20 +0100 Subject: [Freeipa-devel] [PATCH] 375 Restore file extended attributes and SELinux context in ipa-restore In-Reply-To: <546DE886.9060903@redhat.com> References: <546DE886.9060903@redhat.com> Message-ID: <546E0C54.8020001@redhat.com> On 11/20/2014 02:11 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Thank you! ACK, pushed to: master: 3d1e9813e641db59b7dff52f809949bff6c90ce0 ipa-4-1: 215f5451b284c627e9c298ebbc4ee786ced43720 -- Petr? From pviktori at redhat.com Thu Nov 20 15:44:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 16:44:44 +0100 Subject: [Freeipa-devel] [PATCH] 789 restore: clear httpd ccache after restore In-Reply-To: <546DF79D.6000001@redhat.com> References: <546DF79D.6000001@redhat.com> Message-ID: <546E0C6C.7020002@redhat.com> On 11/20/2014 03:15 PM, Petr Vobornik wrote: > so that httpd ccache won't contain old credentials which would make ipa > CLI fail with error: > > Insufficient access: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information > (Decrypt integrity check failed) > > https://fedorahosted.org/freeipa/ticket/4726 > Thank you! ACK, pushed to: master: a3c799f2f4769c1ae8516600e3729a2188ca539f ipa-4-1: 7745e0fd563adae5aa7f58fc07488098fed97dc3 -- Petr? From pviktori at redhat.com Thu Nov 20 15:46:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 16:46:49 +0100 Subject: [Freeipa-devel] [PATCH 0163] Fix compiler warning for pk11helper module In-Reply-To: <546E0958.5060509@redhat.com> References: <546374E2.2040205@redhat.com> <546472F3.7000002@redhat.com> <546E0958.5060509@redhat.com> Message-ID: <546E0CE9.3020005@redhat.com> On 11/20/2014 04:31 PM, David Kupka wrote: > On 11/13/2014 09:59 AM, Martin Basti wrote: >> On 12/11/14 15:55, Martin Basti wrote: >>> Part of ticket: https://fedorahosted.org/freeipa/ticket/4657 >>> >> And here is the patch, sorry :-) > Works for me, thanks, ACK. Pushed to: master: 58737c7791b44d9d7cd011d3385bf66ea24d9830 ipa-4-1: b902ec294387eef29d07ab2ccff9ff17625aaa9c -- Petr? From simo at redhat.com Thu Nov 20 15:47:35 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Nov 2014 10:47:35 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141120144729.GE3493@redhat.com> References: <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> <20141120091204.5202a09e@willson.usersys.redhat.com> <1416493148.2902.7.camel@redhat.com> <20141120144729.GE3493@redhat.com> Message-ID: <20141120104735.4148efb6@willson.usersys.redhat.com> On Thu, 20 Nov 2014 16:47:29 +0200 Alexander Bokovoy wrote: > On Thu, 20 Nov 2014, Nathaniel McCallum wrote: > >On Thu, 2014-11-20 at 09:12 -0500, Simo Sorce wrote: > >> On Thu, 20 Nov 2014 12:36:45 +0200 > >> Alexander Bokovoy wrote: > >> > >> > On Wed, 19 Nov 2014, Simo Sorce wrote: > >> > >----- Original Message ----- > >> > >> From: "Alexander Bokovoy" > >> > >[...] > >> > > > >> > >> Regarding the patchset itself: > >> > >> > >> > >> Patch 0001: fix 'wuld' in the commit message. The rest is > >> > >> fine. > >> > > > >> > >Fixed. > >> > > > >> > >> Patch 0002: > >> > >> - ticket number is missing in the commit message > >> > > > >> > >Added. > >> > > > >> > >> - perhaps, an instruction how to regenerate asn1 code can be > >> > >> made a Makefile target? We don't need to call it ourselves > >> > >> but this would simplify things in future > >> > > > >> > >Added make regenerate target to asn1c makefile > >> > > > >> > >> - I'm little uncomfortable how ASN_DEBUG() output goes > >> > >> explicitly to stderr but I guess this is something we > >> > >> currently cannot override with DS-specific log printing, so > >> > >> no big deal right now > >> > > > >> > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is > >> > >undefined, we can later provide a replacement ASN_DEBUG > >> > >function to hook debugging, but given the same code is used in > >> > >both DS plugins and ipa-getkeytab binary I did not want to > >> > >assume anything, and how to wire it up (if we even want to) > >> > >should probably be discussed at a later time. > >> > > > >> > >> - any specific need to get asn1/compile committed? We don't > >> > >> commit it in the client code (ipa-client/compile). > >> > > > >> > >Added 'compile' to .gitignore in second patch > >> > > > >> > >> Patch 0003: OK > >> > > > >> > >Nothing changed here. > >> > > > >> > >I also remembered the patch naming policy :-) so new patch > >> > >names/numbers are 514,515,516, third revision. > >> > Thanks. The only complaint I have left is number of whitespace > >> > errors that git says are in the 515th patch. > >> > >> Yeah the autogenerated code is not a pretty sight style-wise, do we > >> want to run an automatic indenter on it ? > >> I was hesitant to do so, but I wouldn't mind adding that, if we > >> feel strongly about it. > > > >Let's please not try to correct autogenerated code. > I'm not tied to this but Simo now thinks it is better to run indenter > in the generator rule as this will give less problems in actual > comparison noise that git diff would give. > > I'll make sure to talk back to asn1c author to see if we can improve > its generators upstream. So given Nathaniel doesn't like to touch autogenerated code I'll leave it as it is. I am going to push with the only change being to remove asn1/config.h.in~ with was added to the second commit by mistake. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Nov 20 15:48:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Nov 2014 10:48:34 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141120104735.4148efb6@willson.usersys.redhat.com> References: <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> <20141120091204.5202a09e@willson.usersys.redhat.com> <1416493148.2902.7.camel@redhat.com> <20141120144729.GE3493@redhat.com> <20141120104735.4148efb6@willson.usersys.redhat.com> Message-ID: <1416498514.2902.8.camel@redhat.com> On Thu, 2014-11-20 at 10:47 -0500, Simo Sorce wrote: > On Thu, 20 Nov 2014 16:47:29 +0200 > Alexander Bokovoy wrote: > > > On Thu, 20 Nov 2014, Nathaniel McCallum wrote: > > >On Thu, 2014-11-20 at 09:12 -0500, Simo Sorce wrote: > > >> On Thu, 20 Nov 2014 12:36:45 +0200 > > >> Alexander Bokovoy wrote: > > >> > > >> > On Wed, 19 Nov 2014, Simo Sorce wrote: > > >> > >----- Original Message ----- > > >> > >> From: "Alexander Bokovoy" > > >> > >[...] > > >> > > > > >> > >> Regarding the patchset itself: > > >> > >> > > >> > >> Patch 0001: fix 'wuld' in the commit message. The rest is > > >> > >> fine. > > >> > > > > >> > >Fixed. > > >> > > > > >> > >> Patch 0002: > > >> > >> - ticket number is missing in the commit message > > >> > > > > >> > >Added. > > >> > > > > >> > >> - perhaps, an instruction how to regenerate asn1 code can be > > >> > >> made a Makefile target? We don't need to call it ourselves > > >> > >> but this would simplify things in future > > >> > > > > >> > >Added make regenerate target to asn1c makefile > > >> > > > > >> > >> - I'm little uncomfortable how ASN_DEBUG() output goes > > >> > >> explicitly to stderr but I guess this is something we > > >> > >> currently cannot override with DS-specific log printing, so > > >> > >> no big deal right now > > >> > > > > >> > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is > > >> > >undefined, we can later provide a replacement ASN_DEBUG > > >> > >function to hook debugging, but given the same code is used in > > >> > >both DS plugins and ipa-getkeytab binary I did not want to > > >> > >assume anything, and how to wire it up (if we even want to) > > >> > >should probably be discussed at a later time. > > >> > > > > >> > >> - any specific need to get asn1/compile committed? We don't > > >> > >> commit it in the client code (ipa-client/compile). > > >> > > > > >> > >Added 'compile' to .gitignore in second patch > > >> > > > > >> > >> Patch 0003: OK > > >> > > > > >> > >Nothing changed here. > > >> > > > > >> > >I also remembered the patch naming policy :-) so new patch > > >> > >names/numbers are 514,515,516, third revision. > > >> > Thanks. The only complaint I have left is number of whitespace > > >> > errors that git says are in the 515th patch. > > >> > > >> Yeah the autogenerated code is not a pretty sight style-wise, do we > > >> want to run an automatic indenter on it ? > > >> I was hesitant to do so, but I wouldn't mind adding that, if we > > >> feel strongly about it. > > > > > >Let's please not try to correct autogenerated code. > > I'm not tied to this but Simo now thinks it is better to run indenter > > in the generator rule as this will give less problems in actual > > comparison noise that git diff would give. > > > > I'll make sure to talk back to asn1c author to see if we can improve > > its generators upstream. > > So given Nathaniel doesn't like to touch autogenerated code I'll leave > it as it is. > I am going to push with the only change being to remove > asn1/config.h.in~ with was added to the second commit by mistake. LGTM From pviktori at redhat.com Thu Nov 20 15:50:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 16:50:03 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Fix --{user, group}-ignore-attribute in migration plugin. In-Reply-To: <546DFC35.8000704@redhat.com> References: <546DABA8.2040607@redhat.com> <546DAE62.2080002@redhat.com> <546DC812.6050605@redhat.com> <546DF1E8.6050708@redhat.com> <546DF9E8.5010108@redhat.com> <546DFC35.8000704@redhat.com> Message-ID: <546E0DAB.7040702@redhat.com> On 11/20/2014 03:35 PM, Martin Basti wrote: > On 20/11/14 15:25, Jan Cholasta wrote: >> Dne 20.11.2014 v 14:51 Martin Basti napsal(a): >>> On 20/11/14 11:53, David Kupka wrote: >>>> On 11/20/2014 10:03 AM, Jan Cholasta wrote: >>>>> Dne 20.11.2014 v 09:51 David Kupka napsal(a): >>>>>> https://fedorahosted.org/freeipa/ticket/4620 >>>>> >>>>> IMO changing the loop to: >>>>> >>>>> for attr in attr_blacklist: >>>>> entry_attrs.pop(attr, None) >>>>> >>>>> would be better, because LDAPEntry already handles case >>>>> insensitivity in >>>>> attribute names. >>>>> >>>> This seems better, thanks. >>>> >>>> >>> IMO the same problem is with objectclasses. >>> >>> >>> # do not migrate all object classes >>> if 'objectclass' in entry_attrs: >>> for object_class in kwargs.get('oc_blacklist', []): >>> try: >>> entry_attrs['objectclass'].remove(object_class) # >>> this is case sensitive >>> except ValueError: # object class not present >>> pass >>> >>> Am I right? >> >> Yes. LDAPEntry does not support case insensitivity in this case, >> although I plan to implement it in 4.2. >> > objectclasses are normalized to lowercase before, so it is not a issue. > > The patch works fine, ACK :-) . > Pushed to: master: 35dad9684b22819a2c848e7ebb78cfbc438a30e6 ipa-4-1: 8ab85f161513b376c95094ccfe2b60202fe41baa -- Petr? From simo at redhat.com Thu Nov 20 16:07:09 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Nov 2014 11:07:09 -0500 Subject: [Freeipa-devel] [PATCHES] Fix getkeytab operation In-Reply-To: <20141120104735.4148efb6@willson.usersys.redhat.com> References: <20141118124044.06089fda@willson.usersys.redhat.com> <1416338888.3141.27.camel@redhat.com> <20141118144515.1e7e5d6a@willson.usersys.redhat.com> <1416340875.3141.31.camel@redhat.com> <20141118175831.28d8cfc3@willson.usersys.redhat.com> <20141119105301.GY3493@redhat.com> <697792298.6265651.1416422031444.JavaMail.zimbra@redhat.com> <20141120103645.GA3493@redhat.com> <20141120091204.5202a09e@willson.usersys.redhat.com> <1416493148.2902.7.camel@redhat.com> <20141120144729.GE3493@redhat.com> <20141120104735.4148efb6@willson.usersys.redhat.com> Message-ID: <20141120110709.7edd4d6a@willson.usersys.redhat.com> On Thu, 20 Nov 2014 10:47:35 -0500 Simo Sorce wrote: > On Thu, 20 Nov 2014 16:47:29 +0200 > Alexander Bokovoy wrote: > > > On Thu, 20 Nov 2014, Nathaniel McCallum wrote: > > >On Thu, 2014-11-20 at 09:12 -0500, Simo Sorce wrote: > > >> On Thu, 20 Nov 2014 12:36:45 +0200 > > >> Alexander Bokovoy wrote: > > >> > > >> > On Wed, 19 Nov 2014, Simo Sorce wrote: > > >> > >----- Original Message ----- > > >> > >> From: "Alexander Bokovoy" > > >> > >[...] > > >> > > > > >> > >> Regarding the patchset itself: > > >> > >> > > >> > >> Patch 0001: fix 'wuld' in the commit message. The rest is > > >> > >> fine. > > >> > > > > >> > >Fixed. > > >> > > > > >> > >> Patch 0002: > > >> > >> - ticket number is missing in the commit message > > >> > > > > >> > >Added. > > >> > > > > >> > >> - perhaps, an instruction how to regenerate asn1 code can > > >> > >> be made a Makefile target? We don't need to call it > > >> > >> ourselves but this would simplify things in future > > >> > > > > >> > >Added make regenerate target to asn1c makefile > > >> > > > > >> > >> - I'm little uncomfortable how ASN_DEBUG() output goes > > >> > >> explicitly to stderr but I guess this is something we > > >> > >> currently cannot override with DS-specific log printing, so > > >> > >> no big deal right now > > >> > > > > >> > >ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is > > >> > >undefined, we can later provide a replacement ASN_DEBUG > > >> > >function to hook debugging, but given the same code is used in > > >> > >both DS plugins and ipa-getkeytab binary I did not want to > > >> > >assume anything, and how to wire it up (if we even want to) > > >> > >should probably be discussed at a later time. > > >> > > > > >> > >> - any specific need to get asn1/compile committed? We don't > > >> > >> commit it in the client code (ipa-client/compile). > > >> > > > > >> > >Added 'compile' to .gitignore in second patch > > >> > > > > >> > >> Patch 0003: OK > > >> > > > > >> > >Nothing changed here. > > >> > > > > >> > >I also remembered the patch naming policy :-) so new patch > > >> > >names/numbers are 514,515,516, third revision. > > >> > Thanks. The only complaint I have left is number of whitespace > > >> > errors that git says are in the 515th patch. > > >> > > >> Yeah the autogenerated code is not a pretty sight style-wise, do > > >> we want to run an automatic indenter on it ? > > >> I was hesitant to do so, but I wouldn't mind adding that, if we > > >> feel strongly about it. > > > > > >Let's please not try to correct autogenerated code. > > I'm not tied to this but Simo now thinks it is better to run > > indenter in the generator rule as this will give less problems in > > actual comparison noise that git diff would give. > > > > I'll make sure to talk back to asn1c author to see if we can improve > > its generators upstream. > > So given Nathaniel doesn't like to touch autogenerated code I'll leave > it as it is. > I am going to push with the only change being to remove > asn1/config.h.in~ with was added to the second commit by mistake. Pushed to master: b170851058d6712442d553ef3d11ecd21b282443 c6afc489a1c9d86fd593bd47c4a8dae6d9a008d2 b1a30bff04fe9763b8b270590ec37084fd19b4e0 ipa-4-1: f065cec8a58bf4fee0334afdfb63db02f76c1ff7 45ceef14f9ffa5f3abf19088e991f427b7c5bd92 dd3e91639bc3e87b5a95e344b7d190136ad30de0 ipa-4-0: 55578e9cb33924085969102186250ee60c0a9d85 598b54716c6e177a6b5bfdbccf483d28bf40e0b8 aa988311d1b5eefe16eb60c04227900814468e9f Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Nov 20 16:13:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Nov 2014 11:13:08 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP Message-ID: <1416499988.2902.11.camel@redhat.com> This tests the general workflow for OTP including most possible token combinations. This includes 5872 tests. Further optimization is possible to reduce the number of duplicate tests run. Things not yet tested: * ipa-kdb * ipa-otpd * otptoken-sync * RADIUS proxy * token self-management * type specific attributes -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0081-Add-initial-tests-for-OTP.patch Type: text/x-patch Size: 13897 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 20 16:32:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Nov 2014 17:32:28 +0100 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1416499988.2902.11.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> Message-ID: <546E179C.8010800@redhat.com> On 11/20/2014 05:13 PM, Nathaniel McCallum wrote: > This tests the general workflow for OTP including most possible > token combinations. This includes 5872 tests. Further optimization > is possible to reduce the number of duplicate tests run. > > Things not yet tested: > * ipa-kdb > * ipa-otpd > * otptoken-sync > * RADIUS proxy > * token self-management > * type specific attributes Hello, This reimplements functionality that I'm changing in the pytest patches. I'd like to rewrite these tests to use pytest best practices, both to make them work after the switch and as an example of pytest usage. Would that work for you? -- Petr? From mbasti at redhat.com Thu Nov 20 16:52:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Nov 2014 17:52:03 +0100 Subject: [Freeipa-devel] [PATCH 0169] Fix: read_ip_address should return CheckedIPAddress instance instead of string Message-ID: <546E1C33.6060301@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4747 Patch attached: -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0169-Fix-read_ip_addresses-should-return-ipaddr-object.patch Type: text/x-patch Size: 977 bytes Desc: not available URL: From npmccallum at redhat.com Thu Nov 20 18:03:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Nov 2014 13:03:34 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <546E179C.8010800@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <546E179C.8010800@redhat.com> Message-ID: <1416506614.2902.28.camel@redhat.com> On Thu, 2014-11-20 at 17:32 +0100, Petr Viktorin wrote: > On 11/20/2014 05:13 PM, Nathaniel McCallum wrote: > > This tests the general workflow for OTP including most possible > > token combinations. This includes 5872 tests. Further optimization > > is possible to reduce the number of duplicate tests run. > > > > Things not yet tested: > > * ipa-kdb > > * ipa-otpd > > * otptoken-sync > > * RADIUS proxy > > * token self-management > > * type specific attributes > > Hello, > This reimplements functionality that I'm changing in the pytest patches. > > I'd like to rewrite these tests to use pytest best practices, both to > make them work after the switch and as an example of pytest usage. > Would that work for you? If you're volunteering, have at it! Is there any planned functionality around parallelizing the tests? We could get a big speed boost, at least for these tests, by running token tests in parallel. Nathaniel From rcritten at redhat.com Thu Nov 20 22:26:57 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Nov 2014 17:26:57 -0500 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter Message-ID: <546E6AB1.4090504@redhat.com> Use new capability in python-nss-0.16 to use the NSS protocol range setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. I made this configurable via tls_protocol_range in case somebody wants to override it. There isn't a whole ton of error handling on bad input but there is enough, I think, to point the user in the the right direction. Added a couple more lines of debug output to include the negotiated protocol and cipher. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1111-protocol.patch Type: text/x-patch Size: 6481 bytes Desc: not available URL: From npmccallum at redhat.com Fri Nov 21 01:37:47 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 20 Nov 2014 20:37:47 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1416506614.2902.28.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <546E179C.8010800@redhat.com> <1416506614.2902.28.camel@redhat.com> Message-ID: <1416533867.4661.2.camel@redhat.com> On Thu, 2014-11-20 at 13:03 -0500, Nathaniel McCallum wrote: > On Thu, 2014-11-20 at 17:32 +0100, Petr Viktorin wrote: > > On 11/20/2014 05:13 PM, Nathaniel McCallum wrote: > > > This tests the general workflow for OTP including most possible > > > token combinations. This includes 5872 tests. Further optimization > > > is possible to reduce the number of duplicate tests run. > > > > > > Things not yet tested: > > > * ipa-kdb > > > * ipa-otpd > > > * otptoken-sync > > > * RADIUS proxy > > > * token self-management > > > * type specific attributes > > > > Hello, > > This reimplements functionality that I'm changing in the pytest patches. > > > > I'd like to rewrite these tests to use pytest best practices, both to > > make them work after the switch and as an example of pytest usage. > > Would that work for you? > > If you're volunteering, have at it! > > Is there any planned functionality around parallelizing the tests? We > could get a big speed boost, at least for these tests, by running token > tests in parallel. FYI, I fixed a bug with pyotp which caused failures with non-sha1 digests. https://github.com/nathforge/pyotp/pull/9 With this change, I did another run: 3.25 hours. Aside from some spurious LimitsExceeded errors (which I get occasionally on my system; it might be me), all tests passed. Nathaniel From mkosek at redhat.com Fri Nov 21 07:49:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Nov 2014 08:49:26 +0100 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1416499988.2902.11.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> Message-ID: <546EEE86.5060409@redhat.com> On 11/20/2014 05:13 PM, Nathaniel McCallum wrote: > This tests the general workflow for OTP including most possible > token combinations. This includes 5872 tests. Further optimization > is possible to reduce the number of duplicate tests run. Good job! Yup, heavy optimization will be needed later. > Things not yet tested: > * ipa-kdb Here you would just call kinit instead if LDAP BIND, right? > * ipa-otpd How would ipa-otpd tested? Wouldn't it be tested if simple kinit is made instead of direct LDAP BIND? > * otptoken-sync Petr1 can help to provide a Web UI test for this area. Or alternatively for the test we could use the LDAP extended operation directly, right? > * RADIUS proxy > * token self-management > * type specific attributes +1 What about password changes with OTP, can it be also covered? Also, note that the freeipa-tests would suddenly grow a python-pyotp dependency, this should be considered. Martin From jcholast at redhat.com Fri Nov 21 08:11:15 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 09:11:15 +0100 Subject: [Freeipa-devel] [PATCH] 377 Use correct service name in cainstance.backup_config Message-ID: <546EF3A3.60705@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-377-Use-correct-service-name-in-cainstance.backup_config.patch Type: text/x-patch Size: 1074 bytes Desc: not available URL: From jcholast at redhat.com Fri Nov 21 08:55:13 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 09:55:13 +0100 Subject: [Freeipa-devel] [PATCH 0169] Fix: read_ip_address should return CheckedIPAddress instance instead of string In-Reply-To: <546E1C33.6060301@redhat.com> References: <546E1C33.6060301@redhat.com> Message-ID: <546EFDF1.4070403@redhat.com> Hi, Dne 20.11.2014 v 17:52 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4747 > > Patch attached: ACK! Pushed to: master: 7de424f42541e73ed24a95f1dd90ff4a61e111fa ipa-4-1: 5b397dced1ef4a1eea7b3636fc71c2b7108a0b25 Honza -- Jan Cholasta From tbabej at redhat.com Fri Nov 21 10:28:29 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 11:28:29 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546E0250.5000401@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> <546CA539.2050005@redhat.com> <546E0250.5000401@redhat.com> Message-ID: <546F13CD.9020803@redhat.com> On 11/20/2014 04:01 PM, Jan Cholasta wrote: > Dne 19.11.2014 v 15:12 Tomas Babej napsal(a): >> >> On 11/19/2014 02:03 PM, Jan Cholasta wrote: >>> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >>>> >>>> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>>>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>>>>> rather than search on unexistant containers (which can happen >>>>>>>> with get_dn). >>>>>>>> >>>>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>>>> and makes sure proper error message is raised. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>>>> Doesn't it produce extra LDAP search thus making all our search >>>>>>> commands >>>>>>> slower? Is that what we want? >>>>>> No it does not make all of our LDAP search slower. It only >>>>>> happens for >>>>>> the objects that have parent objects, such as idoverrides or >>>>>> dnsrecords. >>>>> ... and makes them slower. >>>> >>>> What I was pointing out here is that this is not a issue for ALL >>>> *-find >>>> commands (e.g user-find, group-find will not suffer from it), as you >>>> incorrectly stated. >>>> >>>>> >>>>>>> Wouldn't it be better to distinguish between LDAP >>>>>>> search with no results and LDAP search with missing parent DN? The >>>>>>> reply looks >>>>>>> different, at least in CLI: >>>>>> Up to discussion. We would probably need to introduce a new >>>>>> exception, >>>>>> like ParentObjectNotFound. >>>>>> >>>>>>> # search result >>>>>>> search: 4 >>>>>>> result: 0 Success >>>>>>> >>>>>>> # search result >>>>>>> search: 4 >>>>>>> result: 32 No such object >>>>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>>>> >>>>>>> Also, I do not think you can just stop using get_dn(), some >>>>>>> commands override >>>>>>> this call to get more complex searches (like host-find searching >>>>>>> for shortname). >>>>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>>>> issue >>>>>> here. Any custom behaviour is preserved. >>>>> Ah, ok, thanks for info. >>>>> >>>>>> To sum up, I think this is worth changing this behaviour by default, >>>>>> ignoring a non-matching value of the parent object is not a correct >>>>>> general approach in my opinion. >>>>> Well, that's the question. Whether we would leave DS to validate the >>>>> search >>>>> itself or do all the pre-check ourselves. To me, doing just one LDAP >>>>> search and >>>>> processing the error correctly looks better. But I can live even >>>>> with your >>>>> version then, I will leave the framework guardians like Honza or >>>>> Petr3 to decide. >>> >>> +1 on single LDAP search and proper error processing. >>> >>>> >>>> I see now what you're trying to suggest. However, the reason boils >>>> down to ipaldap.find_entries method not differentiating between a >>>> LDAP search that returns error code 32 (No such object) and LDAP >>>> search returning error code 0 (Success), but returning no results. >>>> >>>> In both cases errors.NotFound is raised. >>>> >>>> The reason I did not go this way is that changing the find_entries >>>> method >>>> is quite more invasive as this is the method subsenqently called by >>>> almost >>>> any command. >>> >>> You can always derive the new error (ParentNotFound or whatever) on >>> NotFound, so old code won't break. >>> >> >> Thanks for the suggestsions. >> >> Attached is a new patch which hooks into find_entries method and >> differentiates between the cases. >> > > Why are you special casing base scope search? > Since base search is performed only on the entry specified by the DN, there is no need to differentiate between ContainerNotFound and NotFound. So the logic is as follows: subtree search - ContainerNotFound is raised when container does not exist, NotFound if search provided no results onelevel search - the same base search - NotFound is raised if the specified DN does not exist -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Fri Nov 21 10:47:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 11:47:32 +0100 Subject: [Freeipa-devel] [PATCH 0287] Re-initialize NSS database after otptoken plugin tests Message-ID: <546F1844.9000503@redhat.com> Hi, OTP token tests do not properly reinitialize the NSS db, thus making subsequent xmlrpc tests fail on SSL cert validation. Make sure NSS db is re-initalized in the teardown method. https://fedorahosted.org/freeipa/ticket/4748 Note for reviewers: Requires Petr^3's pytest patchset, which I am pushing right now. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0287-Re-initialize-NSS-database-after-otptoken-plugin-tes.patch Type: text/x-patch Size: 3041 bytes Desc: not available URL: From tbabej at redhat.com Fri Nov 21 11:17:31 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 12:17:31 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <546DB061.5030003@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> <5465C391.7030003@redhat.com> <546C88D7.5040504@redhat.com> <546DB061.5030003@redhat.com> Message-ID: <546F1F4B.20306@redhat.com> On 11/20/2014 10:12 AM, Petr Viktorin wrote: > On 11/19/2014 01:11 PM, Tomas Babej wrote: >> >> On 11/14/2014 09:55 AM, Petr Viktorin wrote: >>> On 10/29/2014 04:52 PM, Petr Viktorin wrote: >>>> On 10/29/2014 01:22 PM, Tomas Babej wrote: >>>>> >>>>> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>>>>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>>>>> This almost completes the switch to pytest. There are two missing >>>>>>> things: >>>>>>> - the details of test results (--with-xunit) are not read >>>>>>> correctly by >>>>>>> Jenkins. I have a theory I'm investigating here. >>>>>>> - the beakerlib integration is still not ready >>>>>>> >>>>>>> >>>>>>> I'll not be available for the rest of the week so I'm sending this >>>>>>> early, in case someone wants to take a look. >>>>>> >>>>>> I've updated (and rearranged) the patches after some more testing. >>>>>> Both points above are fixed. Individual plugins are broken out; some >>>>>> would be nice to even release independently of IPA. (There is some >>>>>> demand for the BeakerLib plugin; for that I'd only need to break the >>>>>> dependency on ipa_log_manager.) >>>>>> >>>>>> >>>>>> These depend on my patches 0656-0660. >>>>>> >>>> >>>>> Thanks for this effort! >>>>> >>>>> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method >>>>> names >>>>> >>>>> There are some references to the old names in the test_ipapython and >>>>> test_install: >>>>> >>>>> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >>>>> [tbabej at thinkpad7 ipatests]$ git grep setUp >>>>> test_install/test_updates.py: def setUp(self): >>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>> test_ipapython/test_dn.py: def setUp(self): >>>>> test_ipapython/test_dn.py: def setUp(self): >>>>> test_ipapython/test_dn.py: def setUp(self): >>>>> test_ipapython/test_dn.py: def setUp(self): >>>>> test_ipapython/test_dn.py: def setUp(self): >>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDown >>>>> test_install/test_updates.py: def tearDown(self): >>>> >>>> These are in unittest.testCase. It would be nice to convert those as >>>> well, but that's for a larger cleanup. >>>> >>>>> #### Patch 0657: tests: Add configuration for pytest >>>>> >>>>> Shouldn't we rather change the class names? >>>> >>>> Ideally yes, but I don't think renaming most of our test classes would >>>> be worth the benefit. >>>> >>>>> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >>>>> get_subcls >>>>> >>>>> ACK. >>>>> >>>>> #### Patch 0659: test_automount_plugin: Fix test ordering >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >>>>> >>>>> --- a/ipatests/test_ipaserver/test_changepw.py >>>>> +++ b/ipatests/test_ipaserver/test_changepw.py >>>>> @@ -33,8 +33,7 @@ >>>>> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >>>>> app_uri = '/ipa/session/change_password' >>>>> >>>>> - def setup(self): >>>>> - super(test_changepw, self).setup() >>>>> + def setup(cls): >>>>> try: >>>>> api.Command['user_add'](uid=testuser, >>>>> givenname=u'Test', sn=u'User') >>>>> api.Command['passwd'](testuser, >>>>> password=u'old_password') >>>>> @@ -43,12 +42,11 @@ def setup(self): >>>>> 'Cannot set up test user: %s' % e >>>>> ) >>>>> >>>>> - def teardown(self): >>>>> + def teardown(cls): >>>>> try: >>>>> api.Command['user_del']([testuser]) >>>>> except errors.NotFound: >>>>> pass >>>>> - super(test_changepw, self).teardown() >>>>> >>>>> The setup/teardown methods are not classmethods, so the name of the >>>>> first argument should remain "self". >>>> >>>> Oops, thanks for the catch! >>>> >>>>> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for >>>>> non-doctest >>>>> examples >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0662: test_webui: Don't use __init__ for test classes >>>>> >>>>> I don't think the following change will work: >>>>> >>>>> - def __init__(self, driver=None, config=None): >>>>> + def setup(self, driver=None, config=None): >>>>> self.request_timeout = 30 >>>>> self.driver = driver >>>>> self.config = config >>>>> if not config: >>>>> self.load_config() >>>>> + self.get_driver().maximize_window() >>>>> + >>>>> + def teardown(self): >>>>> + self.driver.quit() >>>>> >>>>> def load_config(self): >>>>> """ >>>>> @@ -161,20 +165,6 @@ def load_config(self): >>>>> if 'type' not in c: >>>>> c['type'] = DEFAULT_TYPE >>>>> >>>>> - def setup(self): >>>>> - """ >>>>> - Test setup >>>>> - """ >>>>> - if not self.driver: >>>>> - self.driver = self.get_driver() >>>>> - self.driver.maximize_window() >>>>> - >>>>> - def teardown(self): >>>>> - """ >>>>> - Test clean up >>>>> - """ >>>>> - self.driver.quit() >>>>> >>>>> >>>>> The setup(self) method used to set the self.driver attribute on the >>>>> class instance, now nothing sets it. The setup method should do: >>>>> >>>>> def setup(self, driver=None, config=None): >>>>> self.request_timeout = 30 >>>>> self.driver = driver >>>>> self.config = config >>>>> if not config: >>>>> self.load_config() >>>>> if not self.driver: >>>>> self.driver = self.get_driver() >>>>> self.driver.maximize_window() >>>>> >>>>> However, I would prefer having self.driver as a cached property. >>>> >>>> Well, ideally these would be fixtures. >>>> >>>> Thanks for the catch. >>>> >>>>> #### PATCH 0663: test_ipapython: Use functions instead of classes in >>>>> test generators >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0664: Configure pytest to run doctests >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0665: Declarative tests: Move cleanup to >>>>> setup_class/teardown_class >>>>> >>>>> You should also remove the now redundant cleanup_generate method. >>>> >>>> Right, removed. >>>> >>>>> Also: Do we really want to print out error.NotFound or >>>>> errors.EmptyModList exceptions produced by cleanup commands? >>>> >>>> It's just one line, might help debugging. It should only show up on >>>> failures. >>>> >>>>> #### PATCH 0666: Declarative tests: Switch to pytest >>>>> >>>>> Nitpitck: declarative.py has wrong year in the copyright header. >>>>> Otherwise ACK. >>>> >>>> Fixed. >>>> >>>>> #### PATCH 0667: Integration tests: Port the ordering plugin to >>>>> pytest >>>>> >>>>> Specfile change belongs to the previous patch, but I doubt these >>>>> would >>>>> be separated, so not worth spending the time IMHO. >>>> >>>> Also, the previous patch doesn't actually import pytest. But a lot of >>>> these patches break tests by themselves, so they shouldn't be >>>> separated. >>>> >>>>> Why does TestIPACommands have ordered decorator applied? It is >>>>> applied >>>>> on IntegrationTest directly, from which CALessBase inherits from. I >>>>> don't think it's necessary (unless I'm missing something), so we >>>>> should >>>>> rather remove the occurence of the decorator in the test_caless.py >>>>> than >>>>> fixing the import. >>>> >>>> Actually, I think only only the classes that actually need it should >>>> have the decorator. >>>> Again, cleanup for a future time. >>>> >>>>> #### PATCH 0668: Switch make-test to pytest >>>>> >>>>> Nice simplification. However, make-test does not work for me: >>>>> >>>>> I'm getting tons of errors (during the collection) along the lines >>>>> of: >>>>> >>>>> ________________ ERROR collecting >>>>> ipatests/test_xmlrpc/testcert.py >>>>> _________________ >>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>> pyimport >>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >>>>> _______________ ERROR collecting >>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>> pyimport >>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >>>>> >>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >>>>> _______________ ERROR collecting >>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>> import file mismatch: >>>>> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >>>>> __file__ attribute: >>>>> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >>>>> which is not the same as the test file we want to collect: >>>>> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >>>>> HINT: remove __pycache__ / .pyc files and/or use a unique >>>>> basename >>>>> for your test file modules >>>>> ================ 163 passed, 7 skipped, 679 error in 48.14 >>>>> seconds >>>>> ============== >>>>> >>>>> >>>>> I am running this as ./make-test from the directory containing the >>>>> freeipa sources. The ipa-run-tests command seems to work fine though. >>>> >>>> Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? >>>> I've added . to PYTHONPATH, that may help (and it should also help >>>> with >>>> plugin loading in some cases). >>>> >>>>> #### PATCH 0669: Add local pytest plugin for --with-xunit and >>>>> --logging-level >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0670: Switch ipa-run-tests to pytest >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0671: Switch integration testing config to a fixture >>>>> >>>>> ACK. >>>>> >>>>> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >>>>> collection to pytest >>>>> >>>>> I didn't see any glitches, but I haven't tested this one out yet >>>>> functionally. >>>>> >>>>> ### General notes >>>>> >>>>> I did two IPA master installs today, one with your patches applied. >>>>> There were significant differences in the number of successfully >>>>> passing >>>>> tests: >>>>> >>>>> nose: FAILED (SKIP=60, errors=46, failures=14) >>>>> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >>>>> 860.47 seconds ========= >>>>> >>>>> Did you not encounter this in your testing? I will look more deeply >>>>> into >>>>> the failures themselves. >>>> >>>> I did, but it was always some stupid mistake :) >>>> Do you have ~/.ipa set up, and $MASTER undefined? >>>> >>>> The integration test did fail for me now when they were not >>>> configured. >>>> I added an additional patch to fix that. >>> >>> Ping, could you look at the updated patches? >>> >>> >> >> Sure, but the patchset requires a rebase. >> > > Rebased onto master. > I've read through the patches, they seem ok now. Thanks for fixing the issues from the first iterations. ACK. Pushed to master: d42c26c542cfa02c6ba3465ce529ef0cc8f37eda -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mkosek at redhat.com Fri Nov 21 12:23:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Nov 2014 13:23:22 +0100 Subject: [Freeipa-devel] [PATCH] 377 Use correct service name in cainstance.backup_config In-Reply-To: <546EF3A3.60705@redhat.com> References: <546EF3A3.60705@redhat.com> Message-ID: <546F2EBA.6050506@redhat.com> On 11/21/2014 09:11 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza ACK, works fine. Pushed to: master: 71c4d3e979584e9f841bc8565e69b53fc111c8c6 ipa-4-1: 1b5cd5b2271240526177810f7340400db695aafc ipa-4-0: 1ef2d080c4d8a0edc20ab96591b03aad5372ae76 Martin From dkupka at redhat.com Fri Nov 21 12:33:40 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 21 Nov 2014 13:33:40 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. Message-ID: <546F3124.3040803@redhat.com> https://fedorahosted.org/freeipa/ticket/4683 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0031-ipa-restore-Check-if-directory-is-provided-better-er.patch Type: text/x-patch Size: 1574 bytes Desc: not available URL: From tbabej at redhat.com Fri Nov 21 12:42:42 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 13:42:42 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3124.3040803@redhat.com> References: <546F3124.3040803@redhat.com> Message-ID: <546F3342.7040105@redhat.com> On 11/21/2014 01:33 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4683 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - self.read_header() + try: + self.read_header() + except: + raise admintool.ScriptError('Cannot read backup metadata') Is the bare except clause really necessary? https://docs.python.org/2.7/howto/doanddont.html#except -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Nov 21 12:46:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 13:46:05 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546F13CD.9020803@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> <546CA539.2050005@redhat.com> <546E0250.5000401@redhat.com> <546F13CD.9020803@redhat.com> Message-ID: <546F340D.7090104@redhat.com> Dne 21.11.2014 v 11:28 Tomas Babej napsal(a): > > On 11/20/2014 04:01 PM, Jan Cholasta wrote: >> Dne 19.11.2014 v 15:12 Tomas Babej napsal(a): >>> >>> On 11/19/2014 02:03 PM, Jan Cholasta wrote: >>>> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >>>>> >>>>> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>>>>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>>>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>>>>> check that the parent object exists (hence use get_dn_if_exists), >>>>>>>>> rather than search on unexistant containers (which can happen >>>>>>>>> with get_dn). >>>>>>>>> >>>>>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>>>>> and makes sure proper error message is raised. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>>>>> Doesn't it produce extra LDAP search thus making all our search >>>>>>>> commands >>>>>>>> slower? Is that what we want? >>>>>>> No it does not make all of our LDAP search slower. It only >>>>>>> happens for >>>>>>> the objects that have parent objects, such as idoverrides or >>>>>>> dnsrecords. >>>>>> ... and makes them slower. >>>>> >>>>> What I was pointing out here is that this is not a issue for ALL >>>>> *-find >>>>> commands (e.g user-find, group-find will not suffer from it), as you >>>>> incorrectly stated. >>>>> >>>>>> >>>>>>>> Wouldn't it be better to distinguish between LDAP >>>>>>>> search with no results and LDAP search with missing parent DN? The >>>>>>>> reply looks >>>>>>>> different, at least in CLI: >>>>>>> Up to discussion. We would probably need to introduce a new >>>>>>> exception, >>>>>>> like ParentObjectNotFound. >>>>>>> >>>>>>>> # search result >>>>>>>> search: 4 >>>>>>>> result: 0 Success >>>>>>>> >>>>>>>> # search result >>>>>>>> search: 4 >>>>>>>> result: 32 No such object >>>>>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>>>>> >>>>>>>> Also, I do not think you can just stop using get_dn(), some >>>>>>>> commands override >>>>>>>> this call to get more complex searches (like host-find searching >>>>>>>> for shortname). >>>>>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>>>>> issue >>>>>>> here. Any custom behaviour is preserved. >>>>>> Ah, ok, thanks for info. >>>>>> >>>>>>> To sum up, I think this is worth changing this behaviour by default, >>>>>>> ignoring a non-matching value of the parent object is not a correct >>>>>>> general approach in my opinion. >>>>>> Well, that's the question. Whether we would leave DS to validate the >>>>>> search >>>>>> itself or do all the pre-check ourselves. To me, doing just one LDAP >>>>>> search and >>>>>> processing the error correctly looks better. But I can live even >>>>>> with your >>>>>> version then, I will leave the framework guardians like Honza or >>>>>> Petr3 to decide. >>>> >>>> +1 on single LDAP search and proper error processing. >>>> >>>>> >>>>> I see now what you're trying to suggest. However, the reason boils >>>>> down to ipaldap.find_entries method not differentiating between a >>>>> LDAP search that returns error code 32 (No such object) and LDAP >>>>> search returning error code 0 (Success), but returning no results. >>>>> >>>>> In both cases errors.NotFound is raised. >>>>> >>>>> The reason I did not go this way is that changing the find_entries >>>>> method >>>>> is quite more invasive as this is the method subsenqently called by >>>>> almost >>>>> any command. >>>> >>>> You can always derive the new error (ParentNotFound or whatever) on >>>> NotFound, so old code won't break. >>>> >>> >>> Thanks for the suggestsions. >>> >>> Attached is a new patch which hooks into find_entries method and >>> differentiates between the cases. >>> >> >> Why are you special casing base scope search? >> > > Since base search is performed only on the entry specified by the DN, > there is no need to differentiate between ContainerNotFound and NotFound. > > So the logic is as follows: > > subtree search - ContainerNotFound is raised when container does not > exist, NotFound if search provided no results > onelevel search - the same > base search - NotFound is raised if the specified DN does not exist > There is a difference between a search on a non-existent entry and a search on an existent entry with a non-matching filter. This difference exists on LDAP level and applies to all search scopes, not just the base scope. I don't think hiding this difference is useful at all. Remember that this bug exists because we were hiding the difference in the first place. Also, after giving this some thought, I think it would be better to create a new error for the case where there is no match instead of the case where the entry does not exist. NotFound pretty much corresponds to LDAP's NO_SUCH_OBJECT, something like NoMatchingEntry or EmptyResult would fit the no-match result better. -- Jan Cholasta From dkupka at redhat.com Fri Nov 21 12:56:52 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 21 Nov 2014 13:56:52 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3342.7040105@redhat.com> References: <546F3124.3040803@redhat.com> <546F3342.7040105@redhat.com> Message-ID: <546F3694.8030305@redhat.com> On 11/21/2014 01:42 PM, Tomas Babej wrote: > > On 11/21/2014 01:33 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4683 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > - self.read_header() > + try: > + self.read_header() > + except: > + raise admintool.ScriptError('Cannot read backup metadata') > > > Is the bare except clause really necessary? > > https://docs.python.org/2.7/howto/doanddont.html#except > > Not really. I can't imagine other reaction to any exception raised in read_header() than complain and exit. But you're right that it can hide code errors and make debugging more complicated. Fixed patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0031-2-ipa-restore-Check-if-directory-is-provided-better-er.patch Type: text/x-patch Size: 1595 bytes Desc: not available URL: From tbabej at redhat.com Fri Nov 21 13:12:55 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 14:12:55 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3694.8030305@redhat.com> References: <546F3124.3040803@redhat.com> <546F3342.7040105@redhat.com> <546F3694.8030305@redhat.com> Message-ID: <546F3A57.4010300@redhat.com> On 11/21/2014 01:56 PM, David Kupka wrote: > On 11/21/2014 01:42 PM, Tomas Babej wrote: >> >> On 11/21/2014 01:33 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4683 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> - self.read_header() >> + try: >> + self.read_header() >> + except: >> + raise admintool.ScriptError('Cannot read backup >> metadata') >> >> >> Is the bare except clause really necessary? >> >> https://docs.python.org/2.7/howto/doanddont.html#except >> >> > Not really. I can't imagine other reaction to any exception raised in > read_header() than complain and exit. > But you're right that it can hide code errors and make debugging more > complicated. > Fixed patch attached. > On another note, I also noticed that read_header leaves leaking file descriptor fd. Can you convert that part to use the with statement? This is a perfect opportunity to fix this as you're touching related code. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From dkupka at redhat.com Fri Nov 21 13:28:25 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 21 Nov 2014 14:28:25 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3A57.4010300@redhat.com> References: <546F3124.3040803@redhat.com> <546F3342.7040105@redhat.com> <546F3694.8030305@redhat.com> <546F3A57.4010300@redhat.com> Message-ID: <546F3DF9.5090904@redhat.com> On 11/21/2014 02:12 PM, Tomas Babej wrote: > > On 11/21/2014 01:56 PM, David Kupka wrote: >> On 11/21/2014 01:42 PM, Tomas Babej wrote: >>> >>> On 11/21/2014 01:33 PM, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4683 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> - self.read_header() >>> + try: >>> + self.read_header() >>> + except: >>> + raise admintool.ScriptError('Cannot read backup >>> metadata') >>> >>> >>> Is the bare except clause really necessary? >>> >>> https://docs.python.org/2.7/howto/doanddont.html#except >>> >>> >> Not really. I can't imagine other reaction to any exception raised in >> read_header() than complain and exit. >> But you're right that it can hide code errors and make debugging more >> complicated. >> Fixed patch attached. >> > On another note, I also noticed that read_header leaves leaking file > descriptor fd. > > Can you convert that part to use the with statement? This is a perfect > opportunity to fix this as you're touching related code. > I thought that python takes care of it. Thanks. Fixed patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0031-3-ipa-restore-Check-if-directory-is-provided-better-er.patch Type: text/x-patch Size: 2094 bytes Desc: not available URL: From jcholast at redhat.com Fri Nov 21 13:49:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 14:49:45 +0100 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <546E6AB1.4090504@redhat.com> References: <546E6AB1.4090504@redhat.com> Message-ID: <546F42F9.50902@redhat.com> Hi, Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a): > Use new capability in python-nss-0.16 to use the NSS protocol range > setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. > > I made this configurable via tls_protocol_range in case somebody wants > to override it. > > There isn't a whole ton of error handling on bad input but there is > enough, I think, to point the user in the the right direction. > > Added a couple more lines of debug output to include the negotiated > protocol and cipher. > > rob 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master) 2) Could you split the option into two options, say "tls_version_min" and "tls_version_max"? IMO it would be easier to manage the version range that way, when for example you have to lower just the minimal version on a client to make it able to connect to a SSL3-only server. 3) Would it make sense to print a warning when the configured minimal TLS version is not safe and the connection uses a safe TLS version? This is for the case when you have to lower the minimal version on the client because of an old server, then the server gets updated, then you probably no longer want to have unsafe minimal version configured on the client. Functionally the patch is OK. Honza -- Jan Cholasta From pvoborni at redhat.com Fri Nov 21 14:00:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Nov 2014 15:00:29 +0100 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <20141120144933.GF3493@redhat.com> References: <546DD9E4.3070807@redhat.com> <20141120122644.GC3493@redhat.com> <20141120144933.GF3493@redhat.com> Message-ID: <546F457D.4090201@redhat.com> On 20.11.2014 15:49, Alexander Bokovoy wrote: > On Thu, 20 Nov 2014, Alexander Bokovoy wrote: >> On Thu, 20 Nov 2014, Martin Kosek wrote: >>> Hello, >>> >>> We seem to have enough content to release 4.1.2 that will be required >>> to fix >>> some of the Fedora 21 blockers: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165261 >>> >>> and Freeze exception: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165674 >>> >>> Current plan is to release stabilization release 4.1.2 with what we >>> have as it >>> contains the important installation and upgrade fixes. >>> >>> The only problem there is that some patches require components that >>> are not in >>> Fedora stable repos, more specifically commits: >>> >>> 7aa855a3 -> requiring new certmonger >>> 4e119311 -> requiring new pki-core >>> >>> We can release 4.1.2 with them, but they would need to be removed >>> from Fedora >>> 21 downstream release and added back in normal 0day Fedora 21 update. >>> Alternative way would be to just include selected patches for >>> existing Fedora >>> 21 build. >>> >>> Any comments, what else are missing in 4.1.2? I only know about >>> https://fedorahosted.org/freeipa/ticket/4718 >>> https://fedorahosted.org/freeipa/ticket/4728 >>> which is ACKed at the moment, AFAIK. >> >> certmonger and pki-core parts can be backed out in the F21 build, they >> don't create issues for install time -- by definition we are not >> renewing certs at that point and we are not supporting becoming MS CA >> subordinate in the FreeIPA Server Role. >> >> Thus, we can do the release without them to Fedora 21 (and with them to >> rawhide) and have 0day update. > It looks like we'll have to pick up required fixes and do a build with > just them for Fedora 21 final to make sure we don't violate release > rules. > > We can do the full release after it and push it to updates-testing once > stable updates consumed the fixed build for the Fedora 21 release. Fedora 21 build and update with fixes for blockers created: https://admin.fedoraproject.org/updates/freeipa-4.1.1-2.fc21 -- Petr Vobornik From tbabej at redhat.com Fri Nov 21 14:20:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 15:20:37 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3DF9.5090904@redhat.com> References: <546F3124.3040803@redhat.com> <546F3342.7040105@redhat.com> <546F3694.8030305@redhat.com> <546F3A57.4010300@redhat.com> <546F3DF9.5090904@redhat.com> Message-ID: <546F4A35.6060700@redhat.com> On 11/21/2014 02:28 PM, David Kupka wrote: > On 11/21/2014 02:12 PM, Tomas Babej wrote: >> >> On 11/21/2014 01:56 PM, David Kupka wrote: >>> On 11/21/2014 01:42 PM, Tomas Babej wrote: >>>> >>>> On 11/21/2014 01:33 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4683 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> - self.read_header() >>>> + try: >>>> + self.read_header() >>>> + except: >>>> + raise admintool.ScriptError('Cannot read backup >>>> metadata') >>>> >>>> >>>> Is the bare except clause really necessary? >>>> >>>> https://docs.python.org/2.7/howto/doanddont.html#except >>>> >>>> >>> Not really. I can't imagine other reaction to any exception raised in >>> read_header() than complain and exit. >>> But you're right that it can hide code errors and make debugging more >>> complicated. >>> Fixed patch attached. >>> >> On another note, I also noticed that read_header leaves leaking file >> descriptor fd. >> >> Can you convert that part to use the with statement? This is a perfect >> opportunity to fix this as you're touching related code. >> > I thought that python takes care of it. Thanks. > Fixed patch attached. > Works quite nicely. Thanks, ACK. Pushed to: master: 373bbee4e3c25fd6fb41a75b62b09d60da1a5d82 ipa-4-1: b40cf4b283c9df7d960ec80124b45d5361c75320 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From npmccallum at redhat.com Fri Nov 21 14:43:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 21 Nov 2014 09:43:16 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <546EEE86.5060409@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <546EEE86.5060409@redhat.com> Message-ID: <1416580996.3505.10.camel@redhat.com> On Fri, 2014-11-21 at 08:49 +0100, Martin Kosek wrote: > On 11/20/2014 05:13 PM, Nathaniel McCallum wrote: > > This tests the general workflow for OTP including most possible > > token combinations. This includes 5872 tests. Further optimization > > is possible to reduce the number of duplicate tests run. > > Good job! Yup, heavy optimization will be needed later. > > > Things not yet tested: > > * ipa-kdb > > Here you would just call kinit instead if LDAP BIND, right? "just" :) Mostly yes. Special care will be needed around FAST, password changes and not stomping on the admin ticket for running the tests. > > * ipa-otpd > > How would ipa-otpd tested? Wouldn't it be tested if simple kinit is made > instead of direct LDAP BIND? Yes. If desired, it could also be tested directly by sending RADIUS packets. > > * otptoken-sync > > Petr1 can help to provide a Web UI test for this area. Or alternatively for the > test we could use the LDAP extended operation directly, right? If we can't just call api.Command['otptoken_sync'], we can just do the special bind. It isn't too hard, I just wanted to get patches public. > > * RADIUS proxy > > * token self-management > > * type specific attributes > > +1 > > What about password changes with OTP, can it be also covered? That is included in ipa-kdb, but yes. :) > Also, note that the freeipa-tests would suddenly grow a python-pyotp > dependency, this should be considered. I'm probably going to change this to python-cryptography since we now have it in Fedora. I hear IPA will grow a python-cryptography dependency anyway. Nathaniel From rcritten at redhat.com Fri Nov 21 15:09:51 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Nov 2014 10:09:51 -0500 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <546F42F9.50902@redhat.com> References: <546E6AB1.4090504@redhat.com> <546F42F9.50902@redhat.com> Message-ID: <546F55BF.9090708@redhat.com> Jan Cholasta wrote: > Hi, > > Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a): >> Use new capability in python-nss-0.16 to use the NSS protocol range >> setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. >> >> I made this configurable via tls_protocol_range in case somebody wants >> to override it. >> >> There isn't a whole ton of error handling on bad input but there is >> enough, I think, to point the user in the the right direction. >> >> Added a couple more lines of debug output to include the negotiated >> protocol and cipher. >> >> rob > > 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master) Attached. > 2) Could you split the option into two options, say "tls_version_min" > and "tls_version_max"? IMO it would be easier to manage the version > range that way, when for example you have to lower just the minimal > version on a client to make it able to connect to a SSL3-only server. Sure. I waffled back and forth before deciding on a single value. Separate values are probably less error-prone. > 3) Would it make sense to print a warning when the configured minimal > TLS version is not safe and the connection uses a safe TLS version? This > is for the case when you have to lower the minimal version on the client > because of an old server, then the server gets updated, then you > probably no longer want to have unsafe minimal version configured on the > client. I see what you're saying but I think it could end up being just spam that user's get used to. That and given that I'd probably want to set it up to require tls1.1 as a minimum but we can't do that because dogtag only supports through tls1.0 right now AFAICT. That'd be a lot of warnings. > Functionally the patch is OK. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1111-2-4.1-protocol.patch Type: text/x-patch Size: 6726 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1111-2-protocol.patch Type: text/x-patch Size: 6699 bytes Desc: not available URL: From dkupka at redhat.com Fri Nov 21 15:11:03 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 21 Nov 2014 16:11:03 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. Message-ID: <546F5607.7030900@redhat.com> https://fedorahosted.org/freeipa/ticket/4643 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0032-Fix-error-message-for-nonexistent-members-and-add-te.patch Type: text/x-patch Size: 3679 bytes Desc: not available URL: From tbabej at redhat.com Fri Nov 21 15:23:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Nov 2014 16:23:40 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <546F5607.7030900@redhat.com> References: <546F5607.7030900@redhat.com> Message-ID: <546F58FC.5010602@redhat.com> On 11/21/2014 04:11 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4643 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - obj.get_dn_if_exists(name) + try: + obj.get_dn(name) + except errors.NotFound: + obj.handle_not_found(*keys) You switched from get_dn_if_exists to get_dn, why? The get_dn method never raises the NotFound error, it just constructs the dn regardless of the fact whether the actual entry at that dn exists. You need to use get_dn_if_exists here. Some negative tests for this would be welcome :). Indeed, by testing the patch: [tbabej at vm-218 ~]$ ipa automember_rebuild --users=doesnotexist -------------------------------------------------------- Automember rebuild task finished. Processed (0) entries. -------------------------------------------------------- Where the old behaviour was: [tbabej at vm-218 ~]$ ipa automember_rebuild --users=test ipa: ERROR: no such entry -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Nov 21 15:24:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 21 Nov 2014 16:24:20 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <546F5607.7030900@redhat.com> References: <546F5607.7030900@redhat.com> Message-ID: <546F5924.4030401@redhat.com> Hi, Dne 21.11.2014 v 16:11 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4643 You probably don't want to change get_dn_if_exists to get_dn, as the latter does not usually raise NotFound when the entry does not exist. Honza -- Jan Cholasta From pvoborni at redhat.com Fri Nov 21 15:35:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Nov 2014 16:35:41 +0100 Subject: [Freeipa-devel] [PATCH] 376 Stop tracking certificates before restoring them in ipa-restore In-Reply-To: <546DF8DA.4060604@redhat.com> References: <546DF8DA.4060604@redhat.com> Message-ID: <546F5BCD.3030509@redhat.com> On 20.11.2014 15:21, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > ACK Pushed to master: aa9ecb253a60d9d15cd41c5c38695fe64058669a Pushed to ipa-4-1: 66db7b910ddddff0dcc6f2bbce01c3c2b1ce6442 -- Petr Vobornik From rcritten at redhat.com Fri Nov 21 21:13:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 21 Nov 2014 16:13:44 -0500 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <546F1F4B.20306@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> <5465C391.7030003@redhat.com> <546C88D7.5040504@redhat.com> <546DB061.5030003@redhat.com> <546F1F4B.20306@redhat.com> Message-ID: <546FAB08.7070607@redhat.com> Tomas Babej wrote: > > On 11/20/2014 10:12 AM, Petr Viktorin wrote: >> On 11/19/2014 01:11 PM, Tomas Babej wrote: >>> >>> On 11/14/2014 09:55 AM, Petr Viktorin wrote: >>>> On 10/29/2014 04:52 PM, Petr Viktorin wrote: >>>>> On 10/29/2014 01:22 PM, Tomas Babej wrote: >>>>>> >>>>>> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>>>>>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>>>>>> This almost completes the switch to pytest. There are two missing >>>>>>>> things: >>>>>>>> - the details of test results (--with-xunit) are not read >>>>>>>> correctly by >>>>>>>> Jenkins. I have a theory I'm investigating here. >>>>>>>> - the beakerlib integration is still not ready >>>>>>>> >>>>>>>> >>>>>>>> I'll not be available for the rest of the week so I'm sending this >>>>>>>> early, in case someone wants to take a look. >>>>>>> >>>>>>> I've updated (and rearranged) the patches after some more testing. >>>>>>> Both points above are fixed. Individual plugins are broken out; some >>>>>>> would be nice to even release independently of IPA. (There is some >>>>>>> demand for the BeakerLib plugin; for that I'd only need to break the >>>>>>> dependency on ipa_log_manager.) >>>>>>> >>>>>>> >>>>>>> These depend on my patches 0656-0660. >>>>>>> >>>>> >>>>>> Thanks for this effort! >>>>>> >>>>>> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method >>>>>> names >>>>>> >>>>>> There are some references to the old names in the test_ipapython and >>>>>> test_install: >>>>>> >>>>>> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >>>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >>>>>> [tbabej at thinkpad7 ipatests]$ git grep setUp >>>>>> test_install/test_updates.py: def setUp(self): >>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDown >>>>>> test_install/test_updates.py: def tearDown(self): >>>>> >>>>> These are in unittest.testCase. It would be nice to convert those as >>>>> well, but that's for a larger cleanup. >>>>> >>>>>> #### Patch 0657: tests: Add configuration for pytest >>>>>> >>>>>> Shouldn't we rather change the class names? >>>>> >>>>> Ideally yes, but I don't think renaming most of our test classes would >>>>> be worth the benefit. >>>>> >>>>>> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >>>>>> get_subcls >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### Patch 0659: test_automount_plugin: Fix test ordering >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >>>>>> >>>>>> --- a/ipatests/test_ipaserver/test_changepw.py >>>>>> +++ b/ipatests/test_ipaserver/test_changepw.py >>>>>> @@ -33,8 +33,7 @@ >>>>>> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >>>>>> app_uri = '/ipa/session/change_password' >>>>>> >>>>>> - def setup(self): >>>>>> - super(test_changepw, self).setup() >>>>>> + def setup(cls): >>>>>> try: >>>>>> api.Command['user_add'](uid=testuser, >>>>>> givenname=u'Test', sn=u'User') >>>>>> api.Command['passwd'](testuser, >>>>>> password=u'old_password') >>>>>> @@ -43,12 +42,11 @@ def setup(self): >>>>>> 'Cannot set up test user: %s' % e >>>>>> ) >>>>>> >>>>>> - def teardown(self): >>>>>> + def teardown(cls): >>>>>> try: >>>>>> api.Command['user_del']([testuser]) >>>>>> except errors.NotFound: >>>>>> pass >>>>>> - super(test_changepw, self).teardown() >>>>>> >>>>>> The setup/teardown methods are not classmethods, so the name of the >>>>>> first argument should remain "self". >>>>> >>>>> Oops, thanks for the catch! >>>>> >>>>>> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for >>>>>> non-doctest >>>>>> examples >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0662: test_webui: Don't use __init__ for test classes >>>>>> >>>>>> I don't think the following change will work: >>>>>> >>>>>> - def __init__(self, driver=None, config=None): >>>>>> + def setup(self, driver=None, config=None): >>>>>> self.request_timeout = 30 >>>>>> self.driver = driver >>>>>> self.config = config >>>>>> if not config: >>>>>> self.load_config() >>>>>> + self.get_driver().maximize_window() >>>>>> + >>>>>> + def teardown(self): >>>>>> + self.driver.quit() >>>>>> >>>>>> def load_config(self): >>>>>> """ >>>>>> @@ -161,20 +165,6 @@ def load_config(self): >>>>>> if 'type' not in c: >>>>>> c['type'] = DEFAULT_TYPE >>>>>> >>>>>> - def setup(self): >>>>>> - """ >>>>>> - Test setup >>>>>> - """ >>>>>> - if not self.driver: >>>>>> - self.driver = self.get_driver() >>>>>> - self.driver.maximize_window() >>>>>> - >>>>>> - def teardown(self): >>>>>> - """ >>>>>> - Test clean up >>>>>> - """ >>>>>> - self.driver.quit() >>>>>> >>>>>> >>>>>> The setup(self) method used to set the self.driver attribute on the >>>>>> class instance, now nothing sets it. The setup method should do: >>>>>> >>>>>> def setup(self, driver=None, config=None): >>>>>> self.request_timeout = 30 >>>>>> self.driver = driver >>>>>> self.config = config >>>>>> if not config: >>>>>> self.load_config() >>>>>> if not self.driver: >>>>>> self.driver = self.get_driver() >>>>>> self.driver.maximize_window() >>>>>> >>>>>> However, I would prefer having self.driver as a cached property. >>>>> >>>>> Well, ideally these would be fixtures. >>>>> >>>>> Thanks for the catch. >>>>> >>>>>> #### PATCH 0663: test_ipapython: Use functions instead of classes in >>>>>> test generators >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0664: Configure pytest to run doctests >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0665: Declarative tests: Move cleanup to >>>>>> setup_class/teardown_class >>>>>> >>>>>> You should also remove the now redundant cleanup_generate method. >>>>> >>>>> Right, removed. >>>>> >>>>>> Also: Do we really want to print out error.NotFound or >>>>>> errors.EmptyModList exceptions produced by cleanup commands? >>>>> >>>>> It's just one line, might help debugging. It should only show up on >>>>> failures. >>>>> >>>>>> #### PATCH 0666: Declarative tests: Switch to pytest >>>>>> >>>>>> Nitpitck: declarative.py has wrong year in the copyright header. >>>>>> Otherwise ACK. >>>>> >>>>> Fixed. >>>>> >>>>>> #### PATCH 0667: Integration tests: Port the ordering plugin to >>>>>> pytest >>>>>> >>>>>> Specfile change belongs to the previous patch, but I doubt these >>>>>> would >>>>>> be separated, so not worth spending the time IMHO. >>>>> >>>>> Also, the previous patch doesn't actually import pytest. But a lot of >>>>> these patches break tests by themselves, so they shouldn't be >>>>> separated. >>>>> >>>>>> Why does TestIPACommands have ordered decorator applied? It is >>>>>> applied >>>>>> on IntegrationTest directly, from which CALessBase inherits from. I >>>>>> don't think it's necessary (unless I'm missing something), so we >>>>>> should >>>>>> rather remove the occurence of the decorator in the test_caless.py >>>>>> than >>>>>> fixing the import. >>>>> >>>>> Actually, I think only only the classes that actually need it should >>>>> have the decorator. >>>>> Again, cleanup for a future time. >>>>> >>>>>> #### PATCH 0668: Switch make-test to pytest >>>>>> >>>>>> Nice simplification. However, make-test does not work for me: >>>>>> >>>>>> I'm getting tons of errors (during the collection) along the lines >>>>>> of: >>>>>> >>>>>> ________________ ERROR collecting >>>>>> ipatests/test_xmlrpc/testcert.py >>>>>> _________________ >>>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>>> pyimport >>>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >>>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >>>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >>>>>> _______________ ERROR collecting >>>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>>> pyimport >>>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >>>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >>>>>> >>>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >>>>>> _______________ ERROR collecting >>>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>>> import file mismatch: >>>>>> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >>>>>> __file__ attribute: >>>>>> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >>>>>> which is not the same as the test file we want to collect: >>>>>> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >>>>>> HINT: remove __pycache__ / .pyc files and/or use a unique >>>>>> basename >>>>>> for your test file modules >>>>>> ================ 163 passed, 7 skipped, 679 error in 48.14 >>>>>> seconds >>>>>> ============== >>>>>> >>>>>> >>>>>> I am running this as ./make-test from the directory containing the >>>>>> freeipa sources. The ipa-run-tests command seems to work fine though. >>>>> >>>>> Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? >>>>> I've added . to PYTHONPATH, that may help (and it should also help >>>>> with >>>>> plugin loading in some cases). >>>>> >>>>>> #### PATCH 0669: Add local pytest plugin for --with-xunit and >>>>>> --logging-level >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0670: Switch ipa-run-tests to pytest >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0671: Switch integration testing config to a fixture >>>>>> >>>>>> ACK. >>>>>> >>>>>> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >>>>>> collection to pytest >>>>>> >>>>>> I didn't see any glitches, but I haven't tested this one out yet >>>>>> functionally. >>>>>> >>>>>> ### General notes >>>>>> >>>>>> I did two IPA master installs today, one with your patches applied. >>>>>> There were significant differences in the number of successfully >>>>>> passing >>>>>> tests: >>>>>> >>>>>> nose: FAILED (SKIP=60, errors=46, failures=14) >>>>>> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >>>>>> 860.47 seconds ========= >>>>>> >>>>>> Did you not encounter this in your testing? I will look more deeply >>>>>> into >>>>>> the failures themselves. >>>>> >>>>> I did, but it was always some stupid mistake :) >>>>> Do you have ~/.ipa set up, and $MASTER undefined? >>>>> >>>>> The integration test did fail for me now when they were not >>>>> configured. >>>>> I added an additional patch to fix that. >>>> >>>> Ping, could you look at the updated patches? >>>> >>>> >>> >>> Sure, but the patchset requires a rebase. >>> >> >> Rebased onto master. >> > > I've read through the patches, they seem ok now. Thanks for fixing the > issues from the first iterations. > > ACK. > > Pushed to master: d42c26c542cfa02c6ba3465ce529ef0cc8f37eda > How do you debug with tests with pytest? ipa-run-tests -s doesn't stop on pdb embedded in tree. rob From redhatrises at gmail.com Mon Nov 24 03:43:02 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sun, 23 Nov 2014 20:43:02 -0700 Subject: [Freeipa-devel] [PATCH 0037] ipa-managed-entries prompts for password with -p option and incorrect passowrd Message-ID: Hello, I have a fix for https://fedorahosted.org/freeipa/ticket/4089 thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0037-ipa-managed-entries-requires-password-with-bad-passw.patch Type: text/x-patch Size: 1143 bytes Desc: not available URL: From ftweedal at redhat.com Mon Nov 24 07:39:36 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 24 Nov 2014 17:39:36 +1000 Subject: [Freeipa-devel] Meaning of "Needs UI design" field in Trac? Message-ID: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> Hi all, The precise meaning and usage of the "Needs UI design" field in Trac is not clear to me. It has five values: - - Not needed - Review - Consult - Design What is the purpose of this field and the meanings of the different values? And a more general question: is there a resource anywhere that explains the various fields in the FreeIPA Trac? Fraser From mkosek at redhat.com Mon Nov 24 08:23:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Nov 2014 09:23:50 +0100 Subject: [Freeipa-devel] Meaning of "Needs UI design" field in Trac? In-Reply-To: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> References: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> Message-ID: <5472EB16.4060200@redhat.com> On 11/24/2014 08:39 AM, Fraser Tweedale wrote: > Hi all, > > The precise meaning and usage of the "Needs UI design" field in Trac > is not clear to me. It has five values: > > - > - Not needed > - Review > - Consult > - Design > > What is the purpose of this field and the meanings of the different > values? And a more general question: is there a resource anywhere > that explains the various fields in the FreeIPA Trac? Hi Fraser, The addition Trac ticket metadata are usually added quite organically, as they are needed. I am not aware of a page that would describe them. If the field is not clear just from the description, it means it is possibly badly designed :-) Needs UI design in particular was used to select tickets that needs, well, UI review from UX specialist. But given it is not used on a frequent basis (https://fedorahosted.org/freeipa/query?uxd=!&uxd=!Not+needed&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component) I would personally just remove it and use keyword for this one time usage (like "ux-required") to make tickets smaller. HTH, Martin From pviktori at redhat.com Mon Nov 24 08:57:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Nov 2014 09:57:01 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <546FAB08.7070607@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <54510D29.1020804@redhat.com> <5465C391.7030003@redhat.com> <546C88D7.5040504@redhat.com> <546DB061.5030003@redhat.com> <546F1F4B.20306@redhat.com> <546FAB08.7070607@redhat.com> Message-ID: <5472F2DD.8090408@redhat.com> On 11/21/2014 10:13 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> >> On 11/20/2014 10:12 AM, Petr Viktorin wrote: >>> On 11/19/2014 01:11 PM, Tomas Babej wrote: >>>> >>>> On 11/14/2014 09:55 AM, Petr Viktorin wrote: >>>>> On 10/29/2014 04:52 PM, Petr Viktorin wrote: >>>>>> On 10/29/2014 01:22 PM, Tomas Babej wrote: >>>>>>> >>>>>>> On 10/27/2014 04:38 PM, Petr Viktorin wrote: >>>>>>>> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>>>>>>>> This almost completes the switch to pytest. There are two missing >>>>>>>>> things: >>>>>>>>> - the details of test results (--with-xunit) are not read >>>>>>>>> correctly by >>>>>>>>> Jenkins. I have a theory I'm investigating here. >>>>>>>>> - the beakerlib integration is still not ready >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll not be available for the rest of the week so I'm sending this >>>>>>>>> early, in case someone wants to take a look. >>>>>>>> >>>>>>>> I've updated (and rearranged) the patches after some more testing. >>>>>>>> Both points above are fixed. Individual plugins are broken out; some >>>>>>>> would be nice to even release independently of IPA. (There is some >>>>>>>> demand for the BeakerLib plugin; for that I'd only need to break the >>>>>>>> dependency on ipa_log_manager.) >>>>>>>> >>>>>>>> >>>>>>>> These depend on my patches 0656-0660. >>>>>>>> >>>>>> >>>>>>> Thanks for this effort! >>>>>>> >>>>>>> #### Patch 0656: tests: Use PEP8-compliant setup/teardown method >>>>>>> names >>>>>>> >>>>>>> There are some references to the old names in the test_ipapython and >>>>>>> test_install: >>>>>>> >>>>>>> [tbabej at thinkpad7 ipatests]$ git grep setUpClass >>>>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDownClass >>>>>>> [tbabej at thinkpad7 ipatests]$ git grep setUp >>>>>>> test_install/test_updates.py: def setUp(self): >>>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>>> test_ipapython/test_cookie.py: def setUp(self): >>>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>>> test_ipapython/test_dn.py: def setUp(self): >>>>>>> [tbabej at thinkpad7 ipatests]$ git grep tearDown >>>>>>> test_install/test_updates.py: def tearDown(self): >>>>>> >>>>>> These are in unittest.testCase. It would be nice to convert those as >>>>>> well, but that's for a larger cleanup. >>>>>> >>>>>>> #### Patch 0657: tests: Add configuration for pytest >>>>>>> >>>>>>> Shouldn't we rather change the class names? >>>>>> >>>>>> Ideally yes, but I don't think renaming most of our test classes would >>>>>> be worth the benefit. >>>>>> >>>>>>> #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in >>>>>>> get_subcls >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### Patch 0659: test_automount_plugin: Fix test ordering >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0660: Use setup_class/teardown_class in Declarative tests >>>>>>> >>>>>>> --- a/ipatests/test_ipaserver/test_changepw.py >>>>>>> +++ b/ipatests/test_ipaserver/test_changepw.py >>>>>>> @@ -33,8 +33,7 @@ >>>>>>> class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): >>>>>>> app_uri = '/ipa/session/change_password' >>>>>>> >>>>>>> - def setup(self): >>>>>>> - super(test_changepw, self).setup() >>>>>>> + def setup(cls): >>>>>>> try: >>>>>>> api.Command['user_add'](uid=testuser, >>>>>>> givenname=u'Test', sn=u'User') >>>>>>> api.Command['passwd'](testuser, >>>>>>> password=u'old_password') >>>>>>> @@ -43,12 +42,11 @@ def setup(self): >>>>>>> 'Cannot set up test user: %s' % e >>>>>>> ) >>>>>>> >>>>>>> - def teardown(self): >>>>>>> + def teardown(cls): >>>>>>> try: >>>>>>> api.Command['user_del']([testuser]) >>>>>>> except errors.NotFound: >>>>>>> pass >>>>>>> - super(test_changepw, self).teardown() >>>>>>> >>>>>>> The setup/teardown methods are not classmethods, so the name of the >>>>>>> first argument should remain "self". >>>>>> >>>>>> Oops, thanks for the catch! >>>>>> >>>>>>> #### PATCH 0661: dogtag plugin: Don't use doctest syntax for >>>>>>> non-doctest >>>>>>> examples >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0662: test_webui: Don't use __init__ for test classes >>>>>>> >>>>>>> I don't think the following change will work: >>>>>>> >>>>>>> - def __init__(self, driver=None, config=None): >>>>>>> + def setup(self, driver=None, config=None): >>>>>>> self.request_timeout = 30 >>>>>>> self.driver = driver >>>>>>> self.config = config >>>>>>> if not config: >>>>>>> self.load_config() >>>>>>> + self.get_driver().maximize_window() >>>>>>> + >>>>>>> + def teardown(self): >>>>>>> + self.driver.quit() >>>>>>> >>>>>>> def load_config(self): >>>>>>> """ >>>>>>> @@ -161,20 +165,6 @@ def load_config(self): >>>>>>> if 'type' not in c: >>>>>>> c['type'] = DEFAULT_TYPE >>>>>>> >>>>>>> - def setup(self): >>>>>>> - """ >>>>>>> - Test setup >>>>>>> - """ >>>>>>> - if not self.driver: >>>>>>> - self.driver = self.get_driver() >>>>>>> - self.driver.maximize_window() >>>>>>> - >>>>>>> - def teardown(self): >>>>>>> - """ >>>>>>> - Test clean up >>>>>>> - """ >>>>>>> - self.driver.quit() >>>>>>> >>>>>>> >>>>>>> The setup(self) method used to set the self.driver attribute on the >>>>>>> class instance, now nothing sets it. The setup method should do: >>>>>>> >>>>>>> def setup(self, driver=None, config=None): >>>>>>> self.request_timeout = 30 >>>>>>> self.driver = driver >>>>>>> self.config = config >>>>>>> if not config: >>>>>>> self.load_config() >>>>>>> if not self.driver: >>>>>>> self.driver = self.get_driver() >>>>>>> self.driver.maximize_window() >>>>>>> >>>>>>> However, I would prefer having self.driver as a cached property. >>>>>> >>>>>> Well, ideally these would be fixtures. >>>>>> >>>>>> Thanks for the catch. >>>>>> >>>>>>> #### PATCH 0663: test_ipapython: Use functions instead of classes in >>>>>>> test generators >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0664: Configure pytest to run doctests >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0665: Declarative tests: Move cleanup to >>>>>>> setup_class/teardown_class >>>>>>> >>>>>>> You should also remove the now redundant cleanup_generate method. >>>>>> >>>>>> Right, removed. >>>>>> >>>>>>> Also: Do we really want to print out error.NotFound or >>>>>>> errors.EmptyModList exceptions produced by cleanup commands? >>>>>> >>>>>> It's just one line, might help debugging. It should only show up on >>>>>> failures. >>>>>> >>>>>>> #### PATCH 0666: Declarative tests: Switch to pytest >>>>>>> >>>>>>> Nitpitck: declarative.py has wrong year in the copyright header. >>>>>>> Otherwise ACK. >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> #### PATCH 0667: Integration tests: Port the ordering plugin to >>>>>>> pytest >>>>>>> >>>>>>> Specfile change belongs to the previous patch, but I doubt these >>>>>>> would >>>>>>> be separated, so not worth spending the time IMHO. >>>>>> >>>>>> Also, the previous patch doesn't actually import pytest. But a lot of >>>>>> these patches break tests by themselves, so they shouldn't be >>>>>> separated. >>>>>> >>>>>>> Why does TestIPACommands have ordered decorator applied? It is >>>>>>> applied >>>>>>> on IntegrationTest directly, from which CALessBase inherits from. I >>>>>>> don't think it's necessary (unless I'm missing something), so we >>>>>>> should >>>>>>> rather remove the occurence of the decorator in the test_caless.py >>>>>>> than >>>>>>> fixing the import. >>>>>> >>>>>> Actually, I think only only the classes that actually need it should >>>>>> have the decorator. >>>>>> Again, cleanup for a future time. >>>>>> >>>>>>> #### PATCH 0668: Switch make-test to pytest >>>>>>> >>>>>>> Nice simplification. However, make-test does not work for me: >>>>>>> >>>>>>> I'm getting tons of errors (during the collection) along the lines >>>>>>> of: >>>>>>> >>>>>>> ________________ ERROR collecting >>>>>>> ipatests/test_xmlrpc/testcert.py >>>>>>> _________________ >>>>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>>>> pyimport >>>>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', >>>>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', >>>>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) >>>>>>> _______________ ERROR collecting >>>>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>>>> /usr/lib/python2.7/site-packages/py/_path/local.py:661: in >>>>>>> pyimport >>>>>>> raise self.ImportMismatchError(modname, modfile, self) >>>>>>> E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', >>>>>>> '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', >>>>>>> >>>>>>> local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) >>>>>>> _______________ ERROR collecting >>>>>>> ipatests/test_xmlrpc/xmlrpc_test.py _______________ >>>>>>> import file mismatch: >>>>>>> imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this >>>>>>> __file__ attribute: >>>>>>> /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py >>>>>>> which is not the same as the test file we want to collect: >>>>>>> /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py >>>>>>> HINT: remove __pycache__ / .pyc files and/or use a unique >>>>>>> basename >>>>>>> for your test file modules >>>>>>> ================ 163 passed, 7 skipped, 679 error in 48.14 >>>>>>> seconds >>>>>>> ============== >>>>>>> >>>>>>> >>>>>>> I am running this as ./make-test from the directory containing the >>>>>>> freeipa sources. The ipa-run-tests command seems to work fine though. >>>>>> >>>>>> Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? >>>>>> I've added . to PYTHONPATH, that may help (and it should also help >>>>>> with >>>>>> plugin loading in some cases). >>>>>> >>>>>>> #### PATCH 0669: Add local pytest plugin for --with-xunit and >>>>>>> --logging-level >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0670: Switch ipa-run-tests to pytest >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0671: Switch integration testing config to a fixture >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>> #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log >>>>>>> collection to pytest >>>>>>> >>>>>>> I didn't see any glitches, but I haven't tested this one out yet >>>>>>> functionally. >>>>>>> >>>>>>> ### General notes >>>>>>> >>>>>>> I did two IPA master installs today, one with your patches applied. >>>>>>> There were significant differences in the number of successfully >>>>>>> passing >>>>>>> tests: >>>>>>> >>>>>>> nose: FAILED (SKIP=60, errors=46, failures=14) >>>>>>> pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in >>>>>>> 860.47 seconds ========= >>>>>>> >>>>>>> Did you not encounter this in your testing? I will look more deeply >>>>>>> into >>>>>>> the failures themselves. >>>>>> >>>>>> I did, but it was always some stupid mistake :) >>>>>> Do you have ~/.ipa set up, and $MASTER undefined? >>>>>> >>>>>> The integration test did fail for me now when they were not >>>>>> configured. >>>>>> I added an additional patch to fix that. >>>>> >>>>> Ping, could you look at the updated patches? >>>>> >>>>> >>>> >>>> Sure, but the patchset requires a rebase. >>>> >>> >>> Rebased onto master. >>> >> >> I've read through the patches, they seem ok now. Thanks for fixing the >> issues from the first iterations. >> >> ACK. >> >> Pushed to master: d42c26c542cfa02c6ba3465ce529ef0cc8f37eda >> > > How do you debug with tests with pytest? ipa-run-tests -s doesn't stop > on pdb embedded in tree. > > rob Use --pdb instead of -s. (See --help output.) -- Petr? From pviktori at redhat.com Mon Nov 24 09:08:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Nov 2014 10:08:36 +0100 Subject: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors. In-Reply-To: <546F3DF9.5090904@redhat.com> References: <546F3124.3040803@redhat.com> <546F3342.7040105@redhat.com> <546F3694.8030305@redhat.com> <546F3A57.4010300@redhat.com> <546F3DF9.5090904@redhat.com> Message-ID: <5472F594.9040902@redhat.com> On 11/21/2014 02:28 PM, David Kupka wrote: > On 11/21/2014 02:12 PM, Tomas Babej wrote: >> >> On 11/21/2014 01:56 PM, David Kupka wrote: [...] >>> >> On another note, I also noticed that read_header leaves leaking file >> descriptor fd. >> >> Can you convert that part to use the with statement? This is a perfect >> opportunity to fix this as you're touching related code. >> > I thought that python takes care of it.[...] Python does take care of it eventually, but relying on this is messy ? a bit like relying on the OS to close files when the process exits. CPython will currently close the file as soon as there are no more references to the object, but different garbage collectors might take much longer. Python 3 will issue warnings when opened files are left around. -- Petr? From dkupka at redhat.com Mon Nov 24 12:20:47 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 24 Nov 2014 13:20:47 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <546F58FC.5010602@redhat.com> References: <546F5607.7030900@redhat.com> <546F58FC.5010602@redhat.com> Message-ID: <5473229F.6090306@redhat.com> On 11/21/2014 04:23 PM, Tomas Babej wrote: > > On 11/21/2014 04:11 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4643 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > - obj.get_dn_if_exists(name) > + try: > + obj.get_dn(name) > + except errors.NotFound: > + obj.handle_not_found(*keys) > > You switched from get_dn_if_exists to get_dn, why? The get_dn method > never raises the NotFound error, it just constructs the dn regardless of > the fact whether the actual entry at that dn exists. > > You need to use get_dn_if_exists here. Some negative tests for this > would be welcome :). > > Indeed, by testing the patch: > > [tbabej at vm-218 ~]$ ipa automember_rebuild --users=doesnotexist > -------------------------------------------------------- > Automember rebuild task finished. Processed (0) entries. > -------------------------------------------------------- > > Where the old behaviour was: > > [tbabej at vm-218 ~]$ ipa automember_rebuild --users=test > ipa: ERROR: no such entry > Thanks for catching this Friday-afternoon brain error. Attached patch should work as expected. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0032-2-Fix-error-message-for-nonexistent-members-and-add-te.patch Type: text/x-patch Size: 3461 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 24 13:01:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Nov 2014 14:01:12 +0100 Subject: [Freeipa-devel] [PATCH 0171] Fix encoding detection of zonemgr option Message-ID: <54732C18.8020807@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4762 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0171-Fix-detection-of-encoding-in-zonemgr-option.patch Type: text/x-patch Size: 1425 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 24 13:13:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Nov 2014 14:13:00 +0100 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <546F55BF.9090708@redhat.com> References: <546E6AB1.4090504@redhat.com> <546F42F9.50902@redhat.com> <546F55BF.9090708@redhat.com> Message-ID: <54732EDC.5060404@redhat.com> Dne 21.11.2014 v 16:09 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Hi, >> >> Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a): >>> Use new capability in python-nss-0.16 to use the NSS protocol range >>> setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. >>> >>> I made this configurable via tls_protocol_range in case somebody wants >>> to override it. >>> >>> There isn't a whole ton of error handling on bad input but there is >>> enough, I think, to point the user in the the right direction. >>> >>> Added a couple more lines of debug output to include the negotiated >>> protocol and cipher. >>> >>> rob >> >> 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master) > > Attached. > >> 2) Could you split the option into two options, say "tls_version_min" >> and "tls_version_max"? IMO it would be easier to manage the version >> range that way, when for example you have to lower just the minimal >> version on a client to make it able to connect to a SSL3-only server. > > Sure. I waffled back and forth before deciding on a single value. > Separate values are probably less error-prone. > >> 3) Would it make sense to print a warning when the configured minimal >> TLS version is not safe and the connection uses a safe TLS version? This >> is for the case when you have to lower the minimal version on the client >> because of an old server, then the server gets updated, then you >> probably no longer want to have unsafe minimal version configured on the >> client. > > I see what you're saying but I think it could end up being just spam > that user's get used to. That and given that I'd probably want to set it > up to require tls1.1 as a minimum but we can't do that because dogtag > only supports through tls1.0 right now AFAICT. That'd be a lot of warnings. You are probably right about the spam. Nevermind then. > >> Functionally the patch is OK. > > rob > Thanks for the patch, ACK. Fixed option names in commit message and pushed to: master: 5c0ad221e815e8c7b95c1d1095ebd6cf18e7e11c ipa-4-1: 8ef191448f0511b9c1749f47615437d649db0777 BTW before we can close the ticket, we are going to need a couple more fixes: 1) Bump required versions of 389-ds-base, pki-core and openldap, once the necessary fixes are available. 2) Configure mod_nss to also support TLS 1.2. It should be done on both server install and upgrade. This requires a new version of mod_nss. -- Jan Cholasta From jcholast at redhat.com Mon Nov 24 13:21:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Nov 2014 14:21:11 +0100 Subject: [Freeipa-devel] [PATCH 0171] Fix encoding detection of zonemgr option In-Reply-To: <54732C18.8020807@redhat.com> References: <54732C18.8020807@redhat.com> Message-ID: <547330C7.8040203@redhat.com> Hi, Dne 24.11.2014 v 14:01 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4762 > > Patch attached. Thanks, ACK. Pushed to: master: 230df95ed9e043069da0008d046b6b0135b0a8d1 ipa-4-1: 880f1e5c277a8826e3334723cd840cae4e65dfb8 Honza -- Jan Cholasta From abokovoy at redhat.com Mon Nov 24 13:23:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 15:23:19 +0200 Subject: [Freeipa-devel] [PATCH] 0170 AD Trust: improve trust validation Message-ID: <20141124132319.GD28400@redhat.com> Hi, Trust validation requires AD DC to contact IPA server to verify that trust account actually works. It can fail due to DNS or firewall issue or if AD DC was able to resolve IPA master(s) via SRV records, it still may contact a replica that has no trust data replicated yet. In case AD DC still returns 'access denied', wait 5 seconds and try validation again. Repeat validation until we hit a limit of 10 attempts, at which point raise exception telling what's happening. https://fedorahosted.org/freeipa/ticket/4764 -- / Alexander Bokovoy -------------- next part -------------- From 9b2bbe9d229f7c720d39766d3b76646358dce6a8 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 24 Nov 2014 15:07:49 +0200 Subject: [PATCH] AD trust: improve trust validation Trust validation requires AD DC to contact IPA server to verify that trust account actually works. It can fail due to DNS or firewall issue or if AD DC was able to resolve IPA master(s) via SRV records, it still may contact a replica that has no trust data replicated yet. In case AD DC still returns 'access denied', wait 5 seconds and try validation again. Repeat validation until we hit a limit of 10 attempts, at which point raise exception telling what's happening. https://fedorahosted.org/freeipa/ticket/4764 --- ipaserver/dcerpc.py | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index caeca3c..e342c49 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -58,6 +58,7 @@ import pysss from ipaplatform.paths import paths from ldap.filter import escape_filter_chars +from time import sleep __doc__ = _(""" Classes to manage trust joins using DCE-RPC calls @@ -93,6 +94,8 @@ dcerpc_error_codes = { dcerpc_error_messages = { "NT_STATUS_OBJECT_NAME_NOT_FOUND": errors.NotFound(reason=_('Cannot find specified domain or server name')), + "WERR_NO_LOGON_SERVERS": + errors.RemoteRetrieveError(reason=_('AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue')), "NT_STATUS_INVALID_PARAMETER_MIX": errors.RequirementError(name=_('At least the domain or IP address should be specified')), } @@ -699,6 +702,7 @@ class TrustDomainInstance(object): self._policy_handle = None self.read_only = False self.ftinfo_records = None + self.validation_attempts = 0 def __gen_lsa_connection(self, binding): if self.creds is None: @@ -1011,9 +1015,18 @@ class TrustDomainInstance(object): netlogon.NETLOGON_CONTROL_TC_VERIFY, another_domain.info['dns_domain']) if (result and (result.flags and netlogon.NETLOGON_VERIFY_STATUS_RETURNED)): - # netr_LogonControl2Ex() returns non-None result only if overall call - # result was WERR_OK which means verification was correct. - # We only check that it was indeed status for verification process + if (result.pdc_connection_status[0] != 0) and (result.tc_connection_status[0] != 0): + if result.pdc_connection_status[1] == "WERR_ACCESS_DENIED": + # Most likely AD DC hit another IPA replica which yet has no trust secret replicated + # Sleep and repeat again + self.validation_attempts += 1 + if self.validation_attempts < 10: + sleep(5) + return self.verify_trust(another_domain) + raise errors.ACIError(reason=_('IPA master denied trust validation requests from AD DC ' + '%(count)d times. Most likely AD DC contacted a replica ' + 'that has no trust information replicated yet.' % (self.validation_attempts))) + raise assess_dcerpc_exception(*result.pdc_connection_status) return True return False -- 2.1.0 From abokovoy at redhat.com Mon Nov 24 13:33:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 15:33:57 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <546102FF.9080307@redhat.com> References: <546102FF.9080307@redhat.com> Message-ID: <20141124133357.GE28400@redhat.com> On Mon, 10 Nov 2014, Jan Cholasta wrote: >From 63846b20707b194d0be635fa086fbbe463561d02 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 18:10:59 +0000 >Subject: [PATCH 5/7] Fix unchecked return values in ipa-winsync > >https://fedorahosted.org/freeipa/ticket/4651 ACK >--- > .../ipa-winsync/ipa-winsync-config.c | 40 +++++++++++----------- > 1 file changed, 20 insertions(+), 20 deletions(-) > >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 65ceaea..8b62aed 100644 >--- a/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c >+++ b/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c >@@ -905,9 +905,9 @@ ipa_winsync_config_refresh_domain( > > if (!iwdc->realm_name) { > /* error - could not find the IPA config entry with the realm name */ >- LOG_FATAL("Error: could not find the entry containing the realm name for " >- "ds subtree [%s] filter [%s] attr [%s]\n", >- slapi_sdn_get_dn(ds_subtree), realm_filter, realm_attr); >+ LOG_FATAL("Error: could not find the entry containing the realm name " >+ "[%d] ds subtree [%s] filter [%s] attr [%s]\n", >+ ret, slapi_sdn_get_dn(ds_subtree), realm_filter, realm_attr); > goto out; > } > >@@ -918,9 +918,9 @@ ipa_winsync_config_refresh_domain( > &new_user_objclasses, NULL); > if (!new_user_objclasses) { > /* error - could not find the entry containing list of objectclasses */ >- LOG_FATAL("Error: could not find the entry containing the new user objectclass list for " >- "ds subtree [%s] filter [%s] attr [%s]\n", >- slapi_sdn_get_dn(ds_subtree), new_entry_filter, new_user_oc_attr); >+ LOG_FATAL("Error: could not find the entry containing the new user objectclass list " >+ "[%d] ds subtree [%s] filter [%s] attr [%s]\n", >+ ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, new_user_oc_attr); > goto out; > } > >@@ -933,9 +933,9 @@ ipa_winsync_config_refresh_domain( > NULL, &iwdc->homedir_prefix); > if (!iwdc->homedir_prefix) { > /* error - could not find the home dir prefix */ >- LOG_FATAL("Error: could not find the entry containing the home directory prefix for " >- "ds subtree [%s] filter [%s] attr [%s]\n", >- slapi_sdn_get_dn(ds_subtree), new_entry_filter, homedir_prefix_attr); >+ LOG_FATAL("Error: could not find the entry containing the home directory prefix " >+ "[%d] ds subtree [%s] filter [%s] attr [%s]\n", >+ ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, homedir_prefix_attr); > goto out; > } > >@@ -950,8 +950,8 @@ ipa_winsync_config_refresh_domain( > NULL, &iwdc->login_shell); > if (!iwdc->login_shell) { > LOG("Warning: could not find the entry containing the login shell " >- "attribute for ds subtree [%s] filter [%s] attr [%s]\n", >- slapi_sdn_get_dn(ds_subtree), new_entry_filter, >+ "attribute [%d] ds subtree [%s] filter [%s] attr [%s]\n", >+ ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, > login_shell_attr); > } > } >@@ -969,9 +969,9 @@ ipa_winsync_config_refresh_domain( > NULL, &default_group_name); > if (!default_group_name) { > /* error - could not find the default group name */ >- LOG_FATAL("Error: could not find the entry containing the default group name for " >- "ds subtree [%s] filter [%s] attr [%s]\n", >- slapi_sdn_get_dn(ds_subtree), new_entry_filter, default_group_attr); >+ LOG_FATAL("Error: could not find the entry containing the default group name " >+ "[%d] ds subtree [%s] filter [%s] attr [%s]\n", >+ ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, default_group_attr); > goto out; > } > >@@ -1014,9 +1014,9 @@ ipa_winsync_config_refresh_domain( > NULL, &inactivated_group_dn); > if (!inactivated_group_dn) { > /* error - could not find the inactivated group dn */ >- LOG("Could not find the DN of the inactivated users group ds " >- "subtree [%s] filter [%s]. Ignoring\n", >- slapi_sdn_get_dn(ds_subtree), inactivated_filter); >+ LOG("Could not find the DN of the inactivated users group " >+ "[%d] ds subtree [%s] filter [%s]. Ignoring\n", >+ ret, slapi_sdn_get_dn(ds_subtree), inactivated_filter); > goto out; > } > } >@@ -1026,9 +1026,9 @@ ipa_winsync_config_refresh_domain( > NULL, &activated_group_dn); > if (!activated_group_dn) { > /* error - could not find the activated group dn */ >- LOG("Could not find the DN of the activated users group ds " >- "subtree [%s] filter [%s]. Ignoring\n", >- slapi_sdn_get_dn(ds_subtree), activated_filter); >+ LOG("Could not find the DN of the activated users group " >+ "[%d] ds subtree [%s] filter [%s]. Ignoring\n", >+ ret, slapi_sdn_get_dn(ds_subtree), activated_filter); > goto out; > } > } >-- >2.1.0 > -- / Alexander Bokovoy From abokovoy at redhat.com Mon Nov 24 13:34:27 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 15:34:27 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <546102FF.9080307@redhat.com> References: <546102FF.9080307@redhat.com> Message-ID: <20141124133427.GF28400@redhat.com> On Mon, 10 Nov 2014, Jan Cholasta wrote: >From 5cfc5d50ef7d2e42f10488ddf0d11fa405a8cb84 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 18:12:02 +0000 >Subject: [PATCH 6/7] Fix unchecked return value in ipa-join > >https://fedorahosted.org/freeipa/ticket/4651 >--- > ipa-client/ipa-join.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > >diff --git a/ipa-client/ipa-join.c b/ipa-client/ipa-join.c >index 46f6457..ac8251f 100644 >--- a/ipa-client/ipa-join.c >+++ b/ipa-client/ipa-join.c >@@ -208,8 +208,11 @@ connect_ldap(const char *hostname, const char *binddn, const char *bindpw) { > struct berval bindpw_bv; > > if (debug) { >- ldapdebug=2; >+ ldapdebug = 2; > ret = ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, &ldapdebug); >+ if (ret != LDAP_OPT_SUCCESS) { >+ goto fail; >+ } > } > > if (ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, CAFILE) != LDAP_OPT_SUCCESS) ACK -- / Alexander Bokovoy From mbasti at redhat.com Mon Nov 24 13:35:50 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Nov 2014 14:35:50 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration Message-ID: <54733436.8030703@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4721 Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 10465 bytes Desc: not available URL: From abokovoy at redhat.com Mon Nov 24 13:42:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 15:42:55 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <546102FF.9080307@redhat.com> References: <546102FF.9080307@redhat.com> Message-ID: <20141124134255.GG28400@redhat.com> On Mon, 10 Nov 2014, Jan Cholasta wrote: >From 4e4600da5cd9c42b76a56cdbdb4c1314ee7b0a2a Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 18:12:52 +0000 >Subject: [PATCH 7/7] Fix unchecked return value in krb5 common utils > >https://fedorahosted.org/freeipa/ticket/4651 >--- > util/ipa_krb5.c | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c >index 6334ed3..feb23ea 100644 >--- a/util/ipa_krb5.c >+++ b/util/ipa_krb5.c >@@ -730,6 +730,10 @@ struct berval *create_key_control(struct keys_container *keys, > > if (ksdata[i].salttype == NO_SALT) { > ret = ber_printf(be, "}"); >+ if (ret == -1) { >+ ber_free(be, 1); >+ return NULL; >+ } > continue; > } > ACK -- / Alexander Bokovoy From abokovoy at redhat.com Mon Nov 24 13:44:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 15:44:59 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <546AFB36.4010302@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> <546AFB36.4010302@redhat.com> Message-ID: <20141124134459.GH28400@redhat.com> On Tue, 18 Nov 2014, Jan Cholasta wrote: >Dne 12.11.2014 v 08:58 Petr Spacek napsal(a): >>On 11.11.2014 12:27, Jan Cholasta wrote: >>>Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a): >>>>On Tue, 11 Nov 2014, Jan Cholasta wrote: >>>>>> From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001 >>>>>From: Jan Cholasta >>>>>Date: Mon, 10 Nov 2014 18:10:27 +0000 >>>>>Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/4713 >>>>>--- >>>>>daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>>>>1 file changed, 3 insertions(+) >>>>> >>>>>diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>index c8f6c76..debcd1b 100644 >>>>>--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>@@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context >>>>>context, >>>>> ipactx->kdc_hostname, >>>>>strlen(ipactx->kdc_hostname), >>>>> NULL, NULL, &result) == 0) { >>>>> kerr = ipadb_reinit_mspac(ipactx, true); >>>>>+ if (kerr != 0 && kerr != ENOENT) { >>>>>+ goto done; >>>>>+ } >>>>> } >>>>> } >>>>> >>>>I'm not sure we should drop the sign_authdata request here. If we were >>>>able to re-initialize our view of trusted domains, we simply cannot >>>>re-sign incoming PAC but this is handled in ipadb_verify_pac() and >>>>ipadb_sign_pac() and if the former returns NULL value for PAC, we exit >>>>with a return code of 0 while this change will fail a cross-realm TGT >>>>request unconditionally. >>>> >>> >>>OK, what would be a proper fix? Just ignore the return value of >>>ipadb_reinit_mspac here? >> >>Guys, I did not see the code but all instances of "ignore return code" I have >>seen were wrong, including cases where code comment explicitly said "we ignore >>return code on purpose" :-) >> >>At least log an error message if you can't think of anything better ... >> > >I don't disagree, if that's the proper fix. > >Alexander, or someone else, could you please finish the review of the >patches? Thanks. I've ACKed other patches but I'm not going to accept this patch. Rest is fine. -- / Alexander Bokovoy From tbabej at redhat.com Mon Nov 24 13:50:00 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Nov 2014 14:50:00 +0100 Subject: [Freeipa-devel] [PATCH] 782 webui: use domain name instead of domain SID in idrange adder dialog In-Reply-To: <5458E88D.4030200@redhat.com> References: <5458E88D.4030200@redhat.com> Message-ID: <54733788.5030505@redhat.com> On 11/04/2014 03:54 PM, Petr Vobornik wrote: > It's more user friendly. Almost nobody remembers SIDs. > > https://fedorahosted.org/freeipa/ticket/4661 > > depends on patch 777 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Pushed to: master: f70d859b3958a895f08f87eb753ef55eb00931c7 ipa-4-1: 9aeef07d82c646b363ab7fa734d8e4082fee3fc3 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Nov 24 13:56:40 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Nov 2014 14:56:40 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <20141124134459.GH28400@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> <546AFB36.4010302@redhat.com> <20141124134459.GH28400@redhat.com> Message-ID: <54733918.9080709@redhat.com> Dne 24.11.2014 v 14:44 Alexander Bokovoy napsal(a): > On Tue, 18 Nov 2014, Jan Cholasta wrote: >> Dne 12.11.2014 v 08:58 Petr Spacek napsal(a): >>> On 11.11.2014 12:27, Jan Cholasta wrote: >>>> Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a): >>>>> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>>>>>> From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 >>>>>>> 2001 >>>>>> From: Jan Cholasta >>>>>> Date: Mon, 10 Nov 2014 18:10:27 +0000 >>>>>> Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4713 >>>>>> --- >>>>>> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>>>>> 1 file changed, 3 insertions(+) >>>>>> >>>>>> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>> b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>> index c8f6c76..debcd1b 100644 >>>>>> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>> @@ -2071,6 +2071,9 @@ krb5_error_code >>>>>> ipadb_sign_authdata(krb5_context >>>>>> context, >>>>>> ipactx->kdc_hostname, >>>>>> strlen(ipactx->kdc_hostname), >>>>>> NULL, NULL, &result) == 0) { >>>>>> kerr = ipadb_reinit_mspac(ipactx, true); >>>>>> + if (kerr != 0 && kerr != ENOENT) { >>>>>> + goto done; >>>>>> + } >>>>>> } >>>>>> } >>>>>> >>>>> I'm not sure we should drop the sign_authdata request here. If we were >>>>> able to re-initialize our view of trusted domains, we simply cannot >>>>> re-sign incoming PAC but this is handled in ipadb_verify_pac() and >>>>> ipadb_sign_pac() and if the former returns NULL value for PAC, we exit >>>>> with a return code of 0 while this change will fail a cross-realm TGT >>>>> request unconditionally. >>>>> >>>> >>>> OK, what would be a proper fix? Just ignore the return value of >>>> ipadb_reinit_mspac here? >>> >>> Guys, I did not see the code but all instances of "ignore return >>> code" I have >>> seen were wrong, including cases where code comment explicitly said >>> "we ignore >>> return code on purpose" :-) >>> >>> At least log an error message if you can't think of anything better ... >>> >> >> I don't disagree, if that's the proper fix. >> >> Alexander, or someone else, could you please finish the review of the >> patches? Thanks. > I've ACKed other patches but I'm not going to accept this patch. Rest is > fine. That's fine with me, but I'm still going to need a little hint on how this should in fact be fixed. -- Jan Cholasta From tbabej at redhat.com Mon Nov 24 14:06:26 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Nov 2014 15:06:26 +0100 Subject: [Freeipa-devel] [PATCH] 783 webui: normalize idview tab labels In-Reply-To: <5458E8AB.7000203@redhat.com> References: <5458E8AB.7000203@redhat.com> Message-ID: <54733B62.7070303@redhat.com> On 11/04/2014 03:54 PM, Petr Vobornik wrote: > ID View tab labels are no longer redundant. > > https://fedorahosted.org/freeipa/ticket/4650 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Pushed to: master: b42b1755dcd0a681709525b4d574e12b77bbce13 ipa-4-1: 2fc53c9426ff976d4732cc1d16b1b61447cb4313 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Nov 24 14:07:39 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Nov 2014 15:07:39 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <54733BAB.4050408@redhat.com> Dne 11.11.2014 v 11:13 Jan Cholasta napsal(a): > Dne 10.11.2014 v 19:25 Jan Cholasta napsal(a): >> Hi, >> >> the attached patches provide additional fixes for >> . >> >> I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, >> please check them carefully. >> >> Honza > > Changed the ticket to . > > Updated patches attached. Attaching additional patch for an issue that popped up recently. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-378-Fix-memory-leak-in-GetKeytabControl-asn1-code.patch Type: text/x-patch Size: 1389 bytes Desc: not available URL: From abokovoy at redhat.com Mon Nov 24 14:12:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Nov 2014 16:12:49 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <54733918.9080709@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> <546AFB36.4010302@redhat.com> <20141124134459.GH28400@redhat.com> <54733918.9080709@redhat.com> Message-ID: <20141124141249.GI28400@redhat.com> On Mon, 24 Nov 2014, Jan Cholasta wrote: >>>>>>>https://fedorahosted.org/freeipa/ticket/4713 >>>>>>>--- >>>>>>>daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>>>>>>1 file changed, 3 insertions(+) >>>>>>> >>>>>>>diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>index c8f6c76..debcd1b 100644 >>>>>>>--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>@@ -2071,6 +2071,9 @@ krb5_error_code >>>>>>>ipadb_sign_authdata(krb5_context >>>>>>>context, >>>>>>> ipactx->kdc_hostname, >>>>>>>strlen(ipactx->kdc_hostname), >>>>>>> NULL, NULL, &result) == 0) { >>>>>>> kerr = ipadb_reinit_mspac(ipactx, true); >>>>>>>+ if (kerr != 0 && kerr != ENOENT) { >>>>>>>+ goto done; >>>>>>>+ } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>I'm not sure we should drop the sign_authdata request here. If we were >>>>>>able to re-initialize our view of trusted domains, we simply cannot >>>>>>re-sign incoming PAC but this is handled in ipadb_verify_pac() and >>>>>>ipadb_sign_pac() and if the former returns NULL value for PAC, we exit >>>>>>with a return code of 0 while this change will fail a cross-realm TGT >>>>>>request unconditionally. >>>>>> >>>>> >>>>>OK, what would be a proper fix? Just ignore the return value of >>>>>ipadb_reinit_mspac here? >>>> >>>>Guys, I did not see the code but all instances of "ignore return >>>>code" I have >>>>seen were wrong, including cases where code comment explicitly said >>>>"we ignore >>>>return code on purpose" :-) >>>> >>>>At least log an error message if you can't think of anything better ... >>>> >>> >>>I don't disagree, if that's the proper fix. >>> >>>Alexander, or someone else, could you please finish the review of the >>>patches? Thanks. >>I've ACKed other patches but I'm not going to accept this patch. Rest is >>fine. > >That's fine with me, but I'm still going to need a little hint on how >this should in fact be fixed. Right. My main issue is that the change in this patch actually changes the flow for signing MS-PAC in case we were unable to retrieve our defaults. We need to ignore the return code of ipadb_reinit_mspac() here because we are simply not going to add MS PAC with our signature, not fully denying getting the ticket (that check is in a separate place) because this affects also our realm's principals. Consider a case when ipa-adtrust-install wasn't even run, this is where we'll get non-working MS-PAC defaults and we silently drop the MS-PAC signing. -- / Alexander Bokovoy From jcholast at redhat.com Mon Nov 24 14:24:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Nov 2014 15:24:10 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <20141124141249.GI28400@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> <546AFB36.4010302@redhat.com> <20141124134459.GH28400@redhat.com> <54733918.9080709@redhat.com> <20141124141249.GI28400@redhat.com> Message-ID: <54733F8A.1050502@redhat.com> Dne 24.11.2014 v 15:12 Alexander Bokovoy napsal(a): > On Mon, 24 Nov 2014, Jan Cholasta wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4713 >>>>>>>> --- >>>>>>>> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++ >>>>>>>> 1 file changed, 3 insertions(+) >>>>>>>> >>>>>>>> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>> b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>> index c8f6c76..debcd1b 100644 >>>>>>>> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >>>>>>>> @@ -2071,6 +2071,9 @@ krb5_error_code >>>>>>>> ipadb_sign_authdata(krb5_context >>>>>>>> context, >>>>>>>> ipactx->kdc_hostname, >>>>>>>> strlen(ipactx->kdc_hostname), >>>>>>>> NULL, NULL, &result) == 0) { >>>>>>>> kerr = ipadb_reinit_mspac(ipactx, true); >>>>>>>> + if (kerr != 0 && kerr != ENOENT) { >>>>>>>> + goto done; >>>>>>>> + } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> I'm not sure we should drop the sign_authdata request here. If we >>>>>>> were >>>>>>> able to re-initialize our view of trusted domains, we simply cannot >>>>>>> re-sign incoming PAC but this is handled in ipadb_verify_pac() and >>>>>>> ipadb_sign_pac() and if the former returns NULL value for PAC, we >>>>>>> exit >>>>>>> with a return code of 0 while this change will fail a cross-realm >>>>>>> TGT >>>>>>> request unconditionally. >>>>>>> >>>>>> >>>>>> OK, what would be a proper fix? Just ignore the return value of >>>>>> ipadb_reinit_mspac here? >>>>> >>>>> Guys, I did not see the code but all instances of "ignore return >>>>> code" I have >>>>> seen were wrong, including cases where code comment explicitly said >>>>> "we ignore >>>>> return code on purpose" :-) >>>>> >>>>> At least log an error message if you can't think of anything better >>>>> ... >>>>> >>>> >>>> I don't disagree, if that's the proper fix. >>>> >>>> Alexander, or someone else, could you please finish the review of the >>>> patches? Thanks. >>> I've ACKed other patches but I'm not going to accept this patch. Rest is >>> fine. >> >> That's fine with me, but I'm still going to need a little hint on how >> this should in fact be fixed. > Right. My main issue is that the change in this patch actually changes > the flow for signing MS-PAC in case we were unable to retrieve our > defaults. We need to ignore the return code of ipadb_reinit_mspac() here > because we are simply not going to add MS PAC with our signature, not > fully denying getting the ticket (that check is in a separate place) > because this affects also our realm's principals. Consider a case when > ipa-adtrust-install wasn't even run, this is where we'll get non-working > MS-PAC defaults and we silently drop the MS-PAC signing. OK, fixed, updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-369.2-Fix-unchecked-return-value-in-ipa-kdb.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: From dkupka at redhat.com Mon Nov 24 14:54:07 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 24 Nov 2014 15:54:07 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. Message-ID: <5473468F.4070506@redhat.com> https://fedorahosted.org/freeipa/ticket/4695 IMO this is one of two reasonable ways how to fix this ticket. The other one is to change just the manual page but it seems more consistent to use singular for metavars everywhere. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 11463 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 24 14:59:04 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Nov 2014 15:59:04 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <5473468F.4070506@redhat.com> References: <5473468F.4070506@redhat.com> Message-ID: <547347B8.9080907@redhat.com> On 24/11/14 15:54, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4695 > > IMO this is one of two reasonable ways how to fix this ticket. > The other one is to change just the manual page but it seems more > consistent to use singular for metavars everywhere. > > I like this approach. But IMO we should instead of "You ..." form in help, this message, as we use with forwarders "This option can be used multiple times" Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 24 14:59:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Nov 2014 09:59:30 -0500 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <54732EDC.5060404@redhat.com> References: <546E6AB1.4090504@redhat.com> <546F42F9.50902@redhat.com> <546F55BF.9090708@redhat.com> <54732EDC.5060404@redhat.com> Message-ID: <547347D2.4050302@redhat.com> Jan Cholasta wrote: > Dne 21.11.2014 v 16:09 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Hi, >>> >>> Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a): >>>> Use new capability in python-nss-0.16 to use the NSS protocol range >>>> setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. >>>> >>>> I made this configurable via tls_protocol_range in case somebody wants >>>> to override it. >>>> >>>> There isn't a whole ton of error handling on bad input but there is >>>> enough, I think, to point the user in the the right direction. >>>> >>>> Added a couple more lines of debug output to include the negotiated >>>> protocol and cipher. >>>> >>>> rob >>> >>> 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master) >> >> Attached. >> >>> 2) Could you split the option into two options, say "tls_version_min" >>> and "tls_version_max"? IMO it would be easier to manage the version >>> range that way, when for example you have to lower just the minimal >>> version on a client to make it able to connect to a SSL3-only server. >> >> Sure. I waffled back and forth before deciding on a single value. >> Separate values are probably less error-prone. >> >>> 3) Would it make sense to print a warning when the configured minimal >>> TLS version is not safe and the connection uses a safe TLS version? This >>> is for the case when you have to lower the minimal version on the client >>> because of an old server, then the server gets updated, then you >>> probably no longer want to have unsafe minimal version configured on the >>> client. >> >> I see what you're saying but I think it could end up being just spam >> that user's get used to. That and given that I'd probably want to set it >> up to require tls1.1 as a minimum but we can't do that because dogtag >> only supports through tls1.0 right now AFAICT. That'd be a lot of >> warnings. > > You are probably right about the spam. Nevermind then. > >> >>> Functionally the patch is OK. >> >> rob >> > > Thanks for the patch, ACK. > > Fixed option names in commit message and pushed to: > master: 5c0ad221e815e8c7b95c1d1095ebd6cf18e7e11c > ipa-4-1: 8ef191448f0511b9c1749f47615437d649db0777 > > BTW before we can close the ticket, we are going to need a couple more > fixes: > > 1) Bump required versions of 389-ds-base, pki-core and openldap, once > the necessary fixes are available. Right, to be sure that POODLE is fully addressed. > > 2) Configure mod_nss to also support TLS 1.2. It should be done on both > server install and upgrade. This requires a new version of mod_nss. mod_nss 1.0.10 in F-21 and rawhide should both support TLS 1.2 today. mod_nss is also very tolerant of bad/unknown protocols. It won't blow up on unknown protocols. So if the given mod_nss doesn't support TLSv1.2 it will simply report an error about an unknown protocol and configure the server for 1.0/1.1 if configured as: NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 rob From tbabej at redhat.com Mon Nov 24 15:07:28 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Nov 2014 16:07:28 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <5473229F.6090306@redhat.com> References: <546F5607.7030900@redhat.com> <546F58FC.5010602@redhat.com> <5473229F.6090306@redhat.com> Message-ID: <547349B0.2080109@redhat.com> On 11/24/2014 01:20 PM, David Kupka wrote: > On 11/21/2014 04:23 PM, Tomas Babej wrote: >> >> On 11/21/2014 04:11 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4643 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> - obj.get_dn_if_exists(name) >> + try: >> + obj.get_dn(name) >> + except errors.NotFound: >> + obj.handle_not_found(*keys) >> >> You switched from get_dn_if_exists to get_dn, why? The get_dn method >> never raises the NotFound error, it just constructs the dn regardless of >> the fact whether the actual entry at that dn exists. >> >> You need to use get_dn_if_exists here. Some negative tests for this >> would be welcome :). >> >> Indeed, by testing the patch: >> >> [tbabej at vm-218 ~]$ ipa automember_rebuild --users=doesnotexist >> -------------------------------------------------------- >> Automember rebuild task finished. Processed (0) entries. >> -------------------------------------------------------- >> >> Where the old behaviour was: >> >> [tbabej at vm-218 ~]$ ipa automember_rebuild --users=test >> ipa: ERROR: no such entry >> > Thanks for catching this Friday-afternoon brain error. > Attached patch should work as expected. > ACK, works fine. master: * b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab labels ipa-4-1: * 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab labels -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Mon Nov 24 15:15:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Nov 2014 16:15:46 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <547349B0.2080109@redhat.com> References: <546F5607.7030900@redhat.com> <546F58FC.5010602@redhat.com> <5473229F.6090306@redhat.com> <547349B0.2080109@redhat.com> Message-ID: <54734BA2.3070006@redhat.com> On 11/24/2014 04:07 PM, Tomas Babej wrote:> >> > > ACK, works fine. > > master: > * b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab > labels > ipa-4-1: > * 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab > labels Wrong thread? Is it meant for " [PATCH] 783 webui: normalize idview tab labels"? -- Petr Vobornik From tbabej at redhat.com Mon Nov 24 15:20:47 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Nov 2014 16:20:47 +0100 Subject: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests. In-Reply-To: <54734BA2.3070006@redhat.com> References: <546F5607.7030900@redhat.com> <546F58FC.5010602@redhat.com> <5473229F.6090306@redhat.com> <547349B0.2080109@redhat.com> <54734BA2.3070006@redhat.com> Message-ID: <54734CCF.2000908@redhat.com> On 11/24/2014 04:15 PM, Petr Vobornik wrote: > On 11/24/2014 04:07 PM, Tomas Babej wrote:> > >>> >> >> ACK, works fine. >> >> master: >> * b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab >> labels >> ipa-4-1: >> * 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab >> labels > > > Wrong thread? Is it meant for " [PATCH] 783 webui: normalize idview > tab labels"? Correct thread, wrong message in the clipboard. Thanks for noticing. David's patches were pushed to: master: 56ca47d535156122b2578ff19bc0b1a7642af40c ipa-4-1: 192c499ef893b7118a2f7ff9f4c939a9348d5123 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Mon Nov 24 15:39:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Nov 2014 16:39:46 +0100 Subject: [Freeipa-devel] [PATCH] 0675 copy_schema_to_ca: Fallback to old import location for ipaplatform.services In-Reply-To: <54734982.3010500@redhat.com> References: <54734982.3010500@redhat.com> Message-ID: <54735142.8040403@redhat.com> This fixes a regression from the ipaplatform refactoring. https://fedorahosted.org/freeipa/ticket/4763 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0675-copy_schema_to_ca-Fallback-to-old-import-location-fo.patch Type: text/x-patch Size: 1362 bytes Desc: not available URL: From pspacek at redhat.com Mon Nov 24 16:24:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 24 Nov 2014 17:24:00 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <54733436.8030703@redhat.com> References: <54733436.8030703@redhat.com> Message-ID: <54735BA0.3030209@redhat.com> Hello! Thank you for the patch. It is not ready yet but the overall direction seems good. Please see my comments in-line. On 24.11.2014 14:35, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4721 > Patch attached > > -- > Martin Basti > > > freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch > > > From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Fri, 21 Nov 2014 16:54:09 +0100 > Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration > > Shows warning if forward and parent authoritative zone do not have > proper NS record delegation, which can cause the forward zone will be > ineffective and forwarding will not work. > > The chande in the test was required due python changes order of elemnts > in dict (python doesnt guarantee an order in dict) > > Ticket: https://fedorahosted.org/freeipa/ticket/4721 > --- > ipalib/messages.py | 12 +++ > ipalib/plugins/dns.py | 147 +++++++++++++++++++++++++++++--- > ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- > 3 files changed, 149 insertions(+), 12 deletions(-) > > diff --git a/ipalib/messages.py b/ipalib/messages.py > index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644 > --- a/ipalib/messages.py > +++ b/ipalib/messages.py > @@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): > u"If DNSSEC validation is enabled on IPA server(s), " > u"please disable it.") > > +class ForwardzoneIsNotEffectiveWarning(PublicMessage): > + """ > + **13008** Forwardzone is not effective, forwarding will not work because > + there is authoritative parent zone, without proper NS delegation > + """ > + > + errno = 13008 > + type = "warning" > + format = _(u"forward zone \"%(fwzone)s\" is not effective (missing proper " > + u"NS delegation in authoritative zone \"%(authzone)s\"). " > + u"Forwarding may not work.") I think that the error message could be made mode useful: "Forwarding will not work. Please add NS record to parent zone %(authzone)s" (or something like that). > + > > def iter_messages(variables, base): > """Return a tuple with all subclasses > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): > return zone > > > +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): Generally, this method finds an authoritative zone for given "fwzonename". What about method name _find_auth_zone_ldap(name) ? > + """ > + Check if forward zone is effective. > + > + If parent zone exists as authoritative zone, forward zone will not > + forward queries. It is necessary to delegate authority of forward zone I would clarify it: "forward queries by default." > + to another server (non IPA DNS server). I would personally omit "(non IPA DNS server)" because this mechanism is not related to IPA domain at all. > + Example: > + > + Forward zone: sub.example.com > + Zone: example.com > + > + Forwarding will not work, because server thinks it is authoritative > + and returns NXDOMAIN > + > + Adding record: sub.example.com NS nameserver.out.of.ipa.domain. Again, this is not related to IPA domain at all. I propose this text: "Adding record: sub.example.com NS ns.sub.example.com." > + will delegate authority to another server, and IPA DNS server will > + forward DNS queries. > + > + :param fwzonename: forwardzone > + :return: None if effective, name of authoritative zone otherwise > + """ > + assert isinstance(fwzonename, DNSName) > + > + # get all zones > + zones = api.Command.dnszone_find(pkey_only=True, > + sizelimit=0)['result'] Ooooh, are you serious? :-) I don't like this approach, I would rather chop left-most labels from "name" and so dnszone_find() one by one. What if you have many DNS zones? This could be thrown away if you iterate only over relevant zones. > + zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] > + zonenames.sort(reverse=True, key=len) # sort, we need longest match > + > + # check if is there a zone which can cause the forward zone will > + # be ineffective > + sub_of_auth_zone = None > + for name in zonenames: > + if fwzonename.is_subdomain(name): > + sub_of_auth_zone = name > + break > + > + if sub_of_auth_zone is None: > + return None > + > + # check if forwardzone is delegated in authoritative zone > + # test if exists and get NS record > + try: > + ns_records = api.Command.dnsrecord_show( > + sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord'] > + except (errors.NotFound, KeyError): > + return sub_of_auth_zone Note: This function should process only deepest (existing) sub-domain in LDAP which is active (idnsZoneActive = TRUE). Example: fwzonename = sub.fwd.example.com. Existing LDAP master zone = fwd.example.com. - DISABLED Existing LDAP master zone = example.com. Existing LDAP master zone = com. 1) Check existence & activity of fwd.example.com. -> does not exist, continue. 2) Check existence & activity of example.com. -> exists, search for NS records. 3) [inner loop - searching for NS records] 3a) sub.fwd.example.com. NS -> does not exist, continue inner loop. 3b) fwd.example.com. NS -> does not exist, continue inner loop. 3c) Inner loop ends: no more (relative) candidate names to try. 4) Exit returning "example.com." - deepest authoritative super-domain of sub.fwd.example.com. in LDAP. AFAIK content of the NS record does not matter so this check can be thrown away. (Check this before doing so, please :-)) > + # make sure the target is not IPA DNS server > + # FIXME: what if aliases are used? > + normalized_ns_records = set() > + for record in ns_records: > + if record.endswith('.'): > + normalized_ns_records.add(record) > + else: > + normalized_record = "%s.%s" % (record, sub_of_auth_zone) > + normalized_ns_records.add(normalized_record) > + > + nameservers = [normalize_zone(x) for x in > + api.Object.dnsrecord.get_dns_masters()] > + > + if any(nameserver in normalized_ns_records > + for nameserver in nameservers): > + # NS record is pointing to IPA DNS server > + return sub_of_auth_zone > + > + # authoritative zone contains NS records which delegates forwardzone to > + # different server, forwardzone is effective > + return None > + > + > class DNSZoneBase(LDAPObject): > """ > Base class for DNS Zone > @@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject): > dns_name = entry_name[1].derelativize(dns_domain) > self.wait_for_modified_attrs(entry, dns_name, dns_domain) > > + def warning_if_ns_change_cause_fwzone_ineffective(self, keys, result, > + options): > + """after execute""" > + record_name_absolute = keys[-1] > + if not keys[-1].is_absolute(): > + record_name_absolute = keys[-1].derelativize(keys[-2]) > + > + try: > + api.Command.dnsforwardzone_show(record_name_absolute) > + except errors.NotFound: > + # no forward zone > + return > + > + authoritative_zone = \ > + _find_zone_which_makes_fw_zone_ineffective(record_name_absolute) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + options['version'], result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=record_name_absolute, authzone=authoritative_zone > + ) > + ) > > > @register() > @@ -3358,6 +3454,14 @@ class dnsrecord_add(LDAPCreate): > return > raise exc > > + def execute(self, *keys, **options): > + result = super(dnsrecord_add, self).execute(*keys, **options) > + if 'nsrecord' in options: > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, > + result, > + options) > + return result > + > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > assert isinstance(dn, DN) > for attr in getattr(context, 'dnsrecord_precallback_attrs', []): > @@ -3487,7 +3591,10 @@ class dnsrecord_mod(LDAPUpdate): > > if self.api.env['wait_for_dns']: > self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > - > + if 'nsrecord' in options: > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, > + result, > + options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -3654,19 +3761,23 @@ class dnsrecord_del(LDAPUpdate): > if self.api.env['wait_for_dns']: > entries = {(keys[0], keys[1]): None} > self.obj.wait_for_modified_entries(entries) > - return result > + else: > + result = super(dnsrecord_del, self).execute(*keys, **options) > + result['value'] = pkey_to_value([keys[-1]], options) > > - result = super(dnsrecord_del, self).execute(*keys, **options) > - result['value'] = pkey_to_value([keys[-1]], options) > + if getattr(context, 'del_all', False) and not \ > + self.obj.is_pkey_zone_record(*keys): > + result = self.obj.methods.delentry(*keys, > + version=options['version']) > + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > > - if getattr(context, 'del_all', False) and not \ > - self.obj.is_pkey_zone_record(*keys): > - result = self.obj.methods.delentry(*keys, > - version=options['version']) > - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > + if self.api.env['wait_for_dns']: > + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > > - if self.api.env['wait_for_dns']: > - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > + if 'nsrecord' in options or options.get('del_all', False): > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, > + result, > + options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -4019,6 +4130,20 @@ class dnsforwardzone_add(DNSZoneBase_add): > > return dn > > + def execute(self, *keys, **options): > + result = super(dnsforwardzone_add, self).execute(*keys, **options) > + authoritative_zone = _find_zone_which_makes_fw_zone_ineffective(keys[-1]) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + options['version'], result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=keys[-1], authzone=authoritative_zone > + ) > + ) > + > + return result > + > > @register() > class dnsforwardzone_del(DNSZoneBase_del): > diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py > index fb53853147ecf663cf7015867131445f32364cfb..224a80d98273480f40fd78dea0f27e34ea36492f 100644 > --- a/ipatests/test_xmlrpc/test_dns_plugin.py > +++ b/ipatests/test_xmlrpc/test_dns_plugin.py > @@ -1060,7 +1060,7 @@ class test_dns(Declarative): > 'srv_part_target' : u'foo.bar.', > 'srvrecord': [u"1 100 1234 %s" \ > % zone1_ns]}), > - expected=errors.ValidationError(name='srv_target', > + expected=errors.ValidationError(name='srv_weight', > error=u'Raw value of a DNS record was already set by ' + > u'"srv_rec" option'), > ), > -- 1.8.3.1 The same check should be done also on zone de/activation. -- Petr^2 Spacek From lkrispen at redhat.com Mon Nov 24 16:39:42 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 24 Nov 2014 17:39:42 +0100 Subject: [Freeipa-devel] where should the BindDNGroup be located Message-ID: <54735F4E.6030602@redhat.com> in DS we implemented the feature that in a replica objetct it is possible to define a group of bind dns, instead or in addition to the use of nsds5ReplicaBindDn. This allows to maintain a group of ldap principals ad add new replication agreements without having to modify the replication object. I want to use it in the topology plugin an it will probably be used in the 4.2 replioca deployment. So to start with, if I create this group where should it be located in the shared tree: below "cn=ipa,cn=etc,$SUFFIX" ? inside cn=masters or cn=replicas or in a new container (the replication topology info is in cn=topology, cn=ipa,cn=etc,... ) or in cn=groups,cn=accounts,... ? Thanks for suggestions, Ludwig From simo at redhat.com Mon Nov 24 18:10:40 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Nov 2014 13:10:40 -0500 Subject: [Freeipa-devel] [PATCH] drop archeological feature :) Message-ID: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> Getting through krbinstancepy I discovered we are still doing this thing with the master key that has been unnecessary for a few years now. Stop doing that. I haven't really tested this yet ... but ... what could possibly go wrong ? :-D Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-517-1-Stop-saving-the-master-key-in-a-stash-file.patch Type: text/x-patch Size: 2514 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 24 18:14:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Nov 2014 13:14:06 -0500 Subject: [Freeipa-devel] where should the BindDNGroup be located In-Reply-To: <54735F4E.6030602@redhat.com> References: <54735F4E.6030602@redhat.com> Message-ID: <5473756E.9030608@redhat.com> Ludwig Krispenz wrote: > in DS we implemented the feature that in a replica objetct it is > possible to define a group of bind dns, instead or in addition to the > use of nsds5ReplicaBindDn. This allows to maintain a group of ldap > principals ad add new replication agreements without having to modify > the replication object. > I want to use it in the topology plugin an it will probably be used in > the 4.2 replioca deployment. > > So to start with, if I create this group where should it be located in > the shared tree: below "cn=ipa,cn=etc,$SUFFIX" ? inside cn=masters or > cn=replicas or in a new container (the replication topology info is in > cn=topology, cn=ipa,cn=etc,... ) or in cn=groups,cn=accounts,... ? Can you just use a hostgroup for this? We'd probably want a bit more access control around that particular group though. rob From simo at redhat.com Mon Nov 24 18:57:01 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Nov 2014 13:57:01 -0500 Subject: [Freeipa-devel] where should the BindDNGroup be located In-Reply-To: <5473756E.9030608@redhat.com> References: <54735F4E.6030602@redhat.com> <5473756E.9030608@redhat.com> Message-ID: <20141124135701.7c6ad58a@willson.usersys.redhat.com> On Mon, 24 Nov 2014 13:14:06 -0500 Rob Crittenden wrote: > Ludwig Krispenz wrote: > > in DS we implemented the feature that in a replica objetct it is > > possible to define a group of bind dns, instead or in addition to > > the use of nsds5ReplicaBindDn. This allows to maintain a group of > > ldap principals ad add new replication agreements without having to > > modify the replication object. > > I want to use it in the topology plugin an it will probably be used > > in the 4.2 replioca deployment. > > > > So to start with, if I create this group where should it be located > > in the shared tree: below "cn=ipa,cn=etc,$SUFFIX" ? inside > > cn=masters or cn=replicas or in a new container (the replication > > topology info is in cn=topology, cn=ipa,cn=etc,... ) or in > > cn=groups,cn=accounts,... ? > > Can you just use a hostgroup for this? > > We'd probably want a bit more access control around that particular > group though. Probably not, the group will have the ldap/ service principals as members, not the host/ principals (and we need a separate group for the host/ principals probably). Simo. -- Simo Sorce * Red Hat, Inc * New York From william at firstyear.id.au Mon Nov 24 22:01:33 2014 From: william at firstyear.id.au (William B) Date: Tue, 25 Nov 2014 08:31:33 +1030 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA Message-ID: <20141125083133.330ac915@franky.ipa.blackhats.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have been using FreeIPA for some time now. I have done a lot of testing for the project, and have a desire to see FreeIPA do well. As some background, I'm a system admin for a University, who currently runs an unmanaged instance of 389ds. In the future I would love to move to FreeIPA, but I want to explain some concerns first. I have always noticed that FreeIPA is feature rich, but over time I have noticed that this comes at a cost. Most components don't get as much testing as they deserve, and just installing and running FreeIPA for a few hours, one can quickly find rough edges and issues. Run it for longer, and you quickly find more. As a business we value reliable, and consistent software that doesn't have any "surprises" when we use it. Unforseen issues sour peoples taste for things like FreeIPA, as many people get stuck on their first impressions. With these features also comes a lack of advanced documentation. Too often the basics are well covered, but there are lots of simple tasks that an admin would wish to perform that aren't covered in the documentation. High quality, and advanced documentation is really key to my work, as not everyone has as much time as I might to learn the inside-out of FreeIPA. People want to reference documentation. Again, one only needs to sit down and use FreeIPA for a few days, to try and use it in their environment and you will quickly find that many tasks aren't covered by the documentation. The documentation itself is also hard to find, or out of date (Such as on fedoraproject.org, which is the first google hit for me). FreeIPA also pushes a some policies and ideas by default. Consider the password reset functionality. By default, when the password is reset, the password is also expired. In our environment, where we have a third party tool that does password resets on accounts (Password manager), this breaks our expectation as a user would then have to reset their password again in the FreeIPA environment. Little things like this remove flexibility and inhibit people making the swap. These options shouldn't be hardcoded, they should be defaults that can be tuned. If someone wants to do stupid things with those options, that is their choice, but that flexibility will help FreeIPA gain acceptance into businesses. Finally, back to our rich features. Not all businesses want all the features of FreeIPA. For example, we don't want the Dogtag CA, NTP, DNS or Kerberos components. But the default install, installs all these packages even if we don't use them, and it configures services that we don't necesarily need. Kerberos is especially a risk for us as there are plenty of unforseen issues that can arise when you have an AD kerberos domain on the same network, even if they live in different DNS namespaces. Contractors install systems into unix networks, unix systems end up in windows networks. Over time, as process and better discipline is involved, these little mistakes will be removed, but if we were to deploy FreeIPA tomorrow, I have no doubt the kerberos install would interfere with other parts of the network. I would really like to see the FreeIPA build, split into "freeipa-servers" and "freeipa-servers-core" where the core has only the 389ds, web ui and kerberos components, and perhaps even one day, could even be "kerberos free". This might be taking a step back in some ways, but the simplicity would be attractive to complex environments wanting to step up from unmanaged 389ds, to something like FreeIPA, but without all the complexity and overhead of a full install. Over time the extra modules can be enabled as administrators please in a controlled fashion. - - Yes, these things can be controlled through the use of the server install command line switches, but if I'm installing and using only 389 and krb from FreeIPA, I shouldn't need to install all of dogtag as well. These are just my thoughts on the project, and I think it boils down to a few things: * RFE to split freeipa packages to core and full. * Asking for a review and enhancement of documentation. * Better functional testing of FreeIPA server and tasks to help iron out obvious issues before release. Don't take this as harsh criticism. I think FreeIPA is a great project, and a great system. I would like to see it improve and be used more widely. - -- Sincerely, William Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUc6q9AAoJEO/EFteBqAmaa+gP/1kB4recq6BFI/RkyBTMvdal mUnjJHm5M07xvaYVvO56tjhyQFwja9MrDHO5XWekQFmyKG34/5uOEc5rSUX3Jgvh r09r8Tfc8yUmLGtPcbTgw9mK3KgxYKgYCTkucvQPGZN8Yk/mLlkWk8ttGHrO01O4 ZUZnoG0GxdM6q4NP6Iy/U1hpZTOs2jllir0CGUt6v1gUnGXN6vlpF0SLUcto19XN PLBUQRmuwDmGjlCsvBu4k1o4Zjf0rn52+FXNYCNpY95geFxQ4M6tU0N7iw3g4hW2 u53gklJbQX2u0BdI8KknWnGYg+JzRRh1Gz8wRBHJOZC//SiZndyvekm0SPxkZVPt 6JCyei3Uku6KPQwcFFJT7FVmeG5Q5ZSOgzFa6mN7Tky5qu6NwLNe8Rld0/vGQUp+ 5i0YkPwNo9IV2F+A8KDVQ2BPEjfbjB74c5n0rJojMpS//R192ocoFHVbjQjXK2ho dr8rN6lkhPynxw6KakA/8tvfZHTIrgomOCBY8SLyRScRNJYrgWBhSFzPi1+yS6+R lRq4fQIiGVfZmwpy7TkhWfiM6N6Y/YmRFOTykm4baHSRiNC+CUlUmN7ONQivWwVs 2y1lhAim5VIdBEXXjOIvAa0t7UIaUa/14ajHv29jtfLDGMtJirxU9U/vLSoOOojJ W4rLomyv4mLvlK5nAV2o =7/dF -----END PGP SIGNATURE----- From rmeggins at redhat.com Mon Nov 24 22:10:49 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 24 Nov 2014 15:10:49 -0700 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA In-Reply-To: <20141125083133.330ac915@franky.ipa.blackhats.net.au> References: <20141125083133.330ac915@franky.ipa.blackhats.net.au> Message-ID: <5473ACE9.1070803@redhat.com> On 11/24/2014 03:01 PM, William B wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have been using FreeIPA for some time now. I have done a lot of > testing for the project, and have a desire to see FreeIPA do well. > > As some background, I'm a system admin for a University, who currently > runs an unmanaged instance of 389ds. In the future I would love to move > to FreeIPA, but I want to explain some concerns first. > > I have always noticed that FreeIPA is feature rich, but over time I > have noticed that this comes at a cost. Most components don't get as > much testing as they deserve, and just installing and running FreeIPA > for a few hours, one can quickly find rough edges and issues. Run it > for longer, and you quickly find more. As a business we value reliable, > and consistent software that doesn't have any "surprises" when we use > it. Unforseen issues sour peoples taste for things like FreeIPA, as > many people get stuck on their first impressions. > > With these features also comes a lack of advanced documentation. Too > often the basics are well covered, but there are lots of simple tasks > that an admin would wish to perform that aren't covered in the > documentation. High quality, and advanced documentation is really key > to my work, as not everyone has as much time as I might to learn the > inside-out of FreeIPA. People want to reference documentation. Again, > one only needs to sit down and use FreeIPA for a few days, to try and > use it in their environment and you will quickly find that many tasks > aren't covered by the documentation. The documentation itself is also > hard to find, or out of date (Such as on fedoraproject.org, which is > the first google hit for me). > > FreeIPA also pushes a some policies and ideas by default. Consider the > password reset functionality. By default, when the password is reset, > the password is also expired. In our environment, where we have a third > party tool that does password resets on accounts (Password manager), > this breaks our expectation as a user would then have to reset their > password again in the FreeIPA environment. Little things like this > remove flexibility and inhibit people making the swap. These options > shouldn't be hardcoded, they should be defaults that can be tuned. If > someone wants to do stupid things with those options, that is their > choice, but that flexibility will help FreeIPA gain acceptance into > businesses. > > Finally, back to our rich features. Not all businesses want all the > features of FreeIPA. For example, we don't want the Dogtag CA, NTP, DNS > or Kerberos components. Then why do you want to use FreeIPA? Is it just for 389 LDAP + nice command line interface + nice web based UI? > But the default install, installs all these > packages even if we don't use them, and it configures services that we > don't necesarily need. Kerberos is especially a risk for us as there > are plenty of unforseen issues that can arise when you have an AD > kerberos domain on the same network, even if they live in different DNS > namespaces. Contractors install systems into unix networks, unix > systems end up in windows networks. Over time, as process and better > discipline is involved, these little mistakes will be removed, but if > we were to deploy FreeIPA tomorrow, I have no doubt the kerberos > install would interfere with other parts of the network. I would really > like to see the FreeIPA build, split into "freeipa-servers" and > "freeipa-servers-core" where the core has only the 389ds, web ui and > kerberos components, and perhaps even one day, could even be "kerberos > free". This might be taking a step back in some ways, but the > simplicity would be attractive to complex environments wanting to step > up from unmanaged 389ds, to something like FreeIPA, but without all the > complexity and overhead of a full install. Over time the extra modules > can be enabled as administrators please in a controlled fashion. > - - Yes, these things can be controlled through the use of the server > install command line switches, but if I'm installing and using only 389 > and krb from FreeIPA, I shouldn't need to install all of dogtag as well. > > > These are just my thoughts on the project, and I think it boils down to > a few things: > > * RFE to split freeipa packages to core and full. > * Asking for a review and enhancement of documentation. > * Better functional testing of FreeIPA server and tasks to help iron out > obvious issues before release. > > Don't take this as harsh criticism. I think FreeIPA is a great project, > and a great system. I would like to see it improve and be used more > widely. > > - -- > Sincerely, > > William Brown > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJUc6q9AAoJEO/EFteBqAmaa+gP/1kB4recq6BFI/RkyBTMvdal > mUnjJHm5M07xvaYVvO56tjhyQFwja9MrDHO5XWekQFmyKG34/5uOEc5rSUX3Jgvh > r09r8Tfc8yUmLGtPcbTgw9mK3KgxYKgYCTkucvQPGZN8Yk/mLlkWk8ttGHrO01O4 > ZUZnoG0GxdM6q4NP6Iy/U1hpZTOs2jllir0CGUt6v1gUnGXN6vlpF0SLUcto19XN > PLBUQRmuwDmGjlCsvBu4k1o4Zjf0rn52+FXNYCNpY95geFxQ4M6tU0N7iw3g4hW2 > u53gklJbQX2u0BdI8KknWnGYg+JzRRh1Gz8wRBHJOZC//SiZndyvekm0SPxkZVPt > 6JCyei3Uku6KPQwcFFJT7FVmeG5Q5ZSOgzFa6mN7Tky5qu6NwLNe8Rld0/vGQUp+ > 5i0YkPwNo9IV2F+A8KDVQ2BPEjfbjB74c5n0rJojMpS//R192ocoFHVbjQjXK2ho > dr8rN6lkhPynxw6KakA/8tvfZHTIrgomOCBY8SLyRScRNJYrgWBhSFzPi1+yS6+R > lRq4fQIiGVfZmwpy7TkhWfiM6N6Y/YmRFOTykm4baHSRiNC+CUlUmN7ONQivWwVs > 2y1lhAim5VIdBEXXjOIvAa0t7UIaUa/14ajHv29jtfLDGMtJirxU9U/vLSoOOojJ > W4rLomyv4mLvlK5nAV2o > =7/dF > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From alanwevans at gmail.com Mon Nov 24 22:24:25 2014 From: alanwevans at gmail.com (Alan Evans) Date: Mon, 24 Nov 2014 15:24:25 -0700 Subject: [Freeipa-devel] ds-migrate feature enhancements Message-ID: I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. ds-migrate wasn't going to fill all of my needs so I thought I would use it for most and then make up some LDIF's and massage them to do the last bit of migration. I have instead decided to extend ds-migrate and I think that my features might be of use to others so I would like to contribute them. Before I get too for I wanted to get some input from the community. Here are MY original goals: * Migrate ssh public keys The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey attribute: sshPublicKey * Migrate disabled accounts as disabled We 'disable' usere by setting their shadowExpire to a date in the past and setting their shell to /bin/false I realized that the ssh-public key problem is more generally an attribute mapping problem and dealing with disabled users could be more generalized too. Here are instead the new features I would provide. * Attribute mapping Feature should check the new syntax exists and is the same as the old syntax (perhaps further check for compatible syntax) --user-attribute-map=oldAttribute=newAttribute --group-attribute-map=foo=bar Should I drop user/group and just make it --attribute-map and apply it to both? Should certain attributes be mapped by default, i.e. sshPublicKey=ipaSSHPubKey (this means we also need to ignore the objectClass ldapPublicKey by default) Maybe make a separate switch --with-ssh-keys that automatically adds a map and an ignore? * Handling disabled users 1. How to identify disabled users? a. shadowExpire < now() --use-disable-shadow-expire b. loginShell is one of configurable shells --use-disable-login-shell --disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these two would be the defaults) c. nsAccountLocked (though that would be straight copied by the migrator anyway d. From Open DJ the attribute ds-pwp-account-disabled can be used to identify disabled users (are there others?) 2. What do do with disabled users (in my case migrate and disable) a. Migrate them and don't touch nsAccountLocked b. Migrate them and set nsAccountLocked = true --disable-users c. Do not migrate them --skip-disabled-users d. Which is the default? Migrate and disable? If so which are the default methods for identifying them? All methods? So is there anything I'm missing? Any suggestions on the switches? I'm not entirely sure I like them the way they are. I have code to cover about 60% of the above already. The user-attr-map feature is working and the --disabled-users and disabled-shells options are working. Regards, -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at firstyear.id.au Mon Nov 24 23:22:29 2014 From: william at firstyear.id.au (William B) Date: Tue, 25 Nov 2014 09:52:29 +1030 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA In-Reply-To: <5473ACE9.1070803@redhat.com> References: <20141125083133.330ac915@franky.ipa.blackhats.net.au> <5473ACE9.1070803@redhat.com> Message-ID: <20141125095229.322b4fcd@franky.ipa.blackhats.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 24 Nov 2014 15:10:49 -0700 Rich Megginson wrote: > > > > Finally, back to our rich features. Not all businesses want all the > > features of FreeIPA. For example, we don't want the Dogtag CA, NTP, > > DNS or Kerberos components. > > Then why do you want to use FreeIPA? Is it just for 389 LDAP + nice > command line interface + nice web based UI? > Yes, that's exactly what. When you think about FreeIPA, at it's core it's not about dogtag ca, or ntp etc. It's about more effectively managed identity and policy. At my work, I have to observe the horrors of a directory instance that has evolved by people who didn't have the discipline to put all objects in the correct places, or use the correct objectClasses, who have hacked ACI's etc. Having a nice webui, the commandline tools enforces consistency in actions that admins take. It's not about the features as much as using the technology to enforce discipline and have vendor supported methodolgies. - -- Sincerely, William Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUc721AAoJEO/EFteBqAmayZsQAJqy+J7gWlAFasDIruJDaxaP 1/aG4N8crngFVbzqFjPYQ0j6ZmtrWOeIbTZxXlCk4jwcCEW/yjF8l6fCDRKEt3v2 iCjejsb3id4sWbl9V9Ldkq8d17NzJ74Noun41bqNeT/Q4ktmEQRWAbgC6ZpZ8dm+ aJFbEb9/NgCXtzymNAfEH6cjCDh0QoBqwmSz/0FF7vdqYX5J0isx6ut6VdI/DZGb BUHtHYyghUNmB1cV7kp630Dv/Qo90yxth3o9EJ92yUSe/iRKV1KsYcimVqlRx6dA WXo9Q8R1b6Ofod7wv+wW5os5FNCk12nrJbaNl2H/t4kQut3S9evyy5y7jAFHW3R3 TbEhC8f4WRHV6clFF6ovchHLHJ57heGGaNprHcqrnbb/CaH8Ec+zvmkZzqWmrkNv 71ZqlkbS0CRK7NNBVjrZ8bUg1QzpfonU2zOniN/mFy9NMpRfNDmSvYxQ4dyi7W7y ZjAUAODyZE8fo1it53RFjNTW45JlBos7LTeJKq4cWANrMbcSxi760eU9WmSIpeDq mn5zQAkMpwDahwgqjYJL88eb94xJy1wnV79QR9RcGgtGxqrlSo/Dxr4zS2uLZDHZ dHWYZj0D4Fk45hRqbiOXeRYE0+98CtBV2K0LO4Nm2ii5Dxd+dATa3cSEAkYrfCBG lWwfKh0aURl69MGrK0s3 =w8jd -----END PGP SIGNATURE----- From ftweedal at redhat.com Tue Nov 25 00:13:59 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 25 Nov 2014 10:13:59 +1000 Subject: [Freeipa-devel] Meaning of "Needs UI design" field in Trac? In-Reply-To: <5472EB16.4060200@redhat.com> References: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> <5472EB16.4060200@redhat.com> Message-ID: <20141125001359.GT8412@dhcp-40-8.bne.redhat.com> On Mon, Nov 24, 2014 at 09:23:50AM +0100, Martin Kosek wrote: > On 11/24/2014 08:39 AM, Fraser Tweedale wrote: > > Hi all, > > > > The precise meaning and usage of the "Needs UI design" field in Trac > > is not clear to me. It has five values: > > > > - > > - Not needed > > - Review > > - Consult > > - Design > > > > What is the purpose of this field and the meanings of the different > > values? And a more general question: is there a resource anywhere > > that explains the various fields in the FreeIPA Trac? > > Hi Fraser, > > The addition Trac ticket metadata are usually added quite organically, as they > are needed. I am not aware of a page that would describe them. If the field is > not clear just from the description, it means it is possibly badly designed :-) > > Needs UI design in particular was used to select tickets that needs, well, UI > review from UX specialist. > > But given it is not used on a frequent basis > (https://fedorahosted.org/freeipa/query?uxd=!&uxd=!Not+needed&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component) > I would personally just remove it and use keyword for this one time usage (like > "ux-required") to make tickets smaller. > > HTH, > Martin Thanks Martin, that does help. I'll not remove the field just now but I will make a page on the wiki about this. There we can codify semantics of fields and common tags, and indicate fields that are candidates for removal. Cheers, Fraser From simo at redhat.com Tue Nov 25 03:09:01 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Nov 2014 22:09:01 -0500 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA In-Reply-To: <20141125083133.330ac915@franky.ipa.blackhats.net.au> References: <20141125083133.330ac915@franky.ipa.blackhats.net.au> Message-ID: <20141124220901.478971f7@willson.usersys.redhat.com> On Tue, 25 Nov 2014 08:31:33 +1030 William B wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have been using FreeIPA for some time now. I have done a lot of > testing for the project, and have a desire to see FreeIPA do well. > > As some background, I'm a system admin for a University, who currently > runs an unmanaged instance of 389ds. In the future I would love to > move to FreeIPA, but I want to explain some concerns first. > > I have always noticed that FreeIPA is feature rich, but over time I > have noticed that this comes at a cost. Most components don't get as > much testing as they deserve, and just installing and running FreeIPA > for a few hours, one can quickly find rough edges and issues. Run it > for longer, and you quickly find more. As a business we value > reliable, and consistent software that doesn't have any "surprises" > when we use it. Unforseen issues sour peoples taste for things like > FreeIPA, as many people get stuck on their first impressions. > > With these features also comes a lack of advanced documentation. Too > often the basics are well covered, but there are lots of simple tasks > that an admin would wish to perform that aren't covered in the > documentation. High quality, and advanced documentation is really key > to my work, as not everyone has as much time as I might to learn the > inside-out of FreeIPA. People want to reference documentation. Again, > one only needs to sit down and use FreeIPA for a few days, to try and > use it in their environment and you will quickly find that many tasks > aren't covered by the documentation. The documentation itself is also > hard to find, or out of date (Such as on fedoraproject.org, which is > the first google hit for me). > > FreeIPA also pushes a some policies and ideas by default. Consider the > password reset functionality. By default, when the password is reset, > the password is also expired. In our environment, where we have a > third party tool that does password resets on accounts (Password > manager), this breaks our expectation as a user would then have to > reset their password again in the FreeIPA environment. Little things > like this remove flexibility and inhibit people making the swap. > These options shouldn't be hardcoded, they should be defaults that > can be tuned. If someone wants to do stupid things with those > options, that is their choice, but that flexibility will help FreeIPA > gain acceptance into businesses. > > Finally, back to our rich features. Not all businesses want all the > features of FreeIPA. For example, we don't want the Dogtag CA, NTP, > DNS or Kerberos components. But the default install, installs all > these packages even if we don't use them, and it configures services > that we don't necesarily need. Kerberos is especially a risk for us > as there are plenty of unforseen issues that can arise when you have > an AD kerberos domain on the same network, even if they live in > different DNS namespaces. Contractors install systems into unix > networks, unix systems end up in windows networks. Over time, as > process and better discipline is involved, these little mistakes will > be removed, but if we were to deploy FreeIPA tomorrow, I have no > doubt the kerberos install would interfere with other parts of the > network. I would really like to see the FreeIPA build, split into > "freeipa-servers" and "freeipa-servers-core" where the core has only > the 389ds, web ui and kerberos components, and perhaps even one day, > could even be "kerberos free". This might be taking a step back in > some ways, but the simplicity would be attractive to complex > environments wanting to step up from unmanaged 389ds, to something > like FreeIPA, but without all the complexity and overhead of a full > install. Over time the extra modules can be enabled as administrators > please in a controlled fashion. > - - Yes, these things can be controlled through the use of the server > install command line switches, but if I'm installing and using only > 389 and krb from FreeIPA, I shouldn't need to install all of dogtag > as well. > > > These are just my thoughts on the project, and I think it boils down > to a few things: > > * RFE to split freeipa packages to core and full. > * Asking for a review and enhancement of documentation. > * Better functional testing of FreeIPA server and tasks to help iron > out obvious issues before release. > > Don't take this as harsh criticism. I think FreeIPA is a great > project, and a great system. I would like to see it improve and be > used more widely. Hi William, good news is, Dogtag, DNS and NTP are all optional components, you can install a FreeIPa server withouth the CA and without DNS. NTP is installed by default, but it is very easy to diasable it if you want. Kerberos is a core feature and cannot be disabled, but I thing you figured that out already. We have some plans to split the rpm packaging so that DNS and CA components can be split into separate subpackages, however we are not there yet, as some restructuring of the installer and framework will need to happen to be able to completely omit some of the pieces. We are well aware of the shortcomings of the documentation, unfortunately our upstream documentation effort died due to not enough participation, so in the future the most up to date docs will be RHEL docs. We'll add pointers to them in freeipa.org pages once we are happy enough with them. On the testing side we are adding a lot of tests upstream that should help improving test coverage and feature regressions, any help there is welcome. We always welcome feedback and help with the project, whether it is code, or additional HOWTOs documentation or even just specific bugs and RFEs that point out specific issues or areas where we can do better. Of course our resources are limited so we'll prioritize what is most requested, sometimes at the expenses of features we'd really like to see but have no way to fund development for in the short term. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue Nov 25 08:06:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:06:37 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <54733F8A.1050502@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141111104025.GC19156@redhat.com> <5461F299.1080801@redhat.com> <54631328.7030204@redhat.com> <546AFB36.4010302@redhat.com> <20141124134459.GH28400@redhat.com> <54733918.9080709@redhat.com> <20141124141249.GI28400@redhat.com> <54733F8A.1050502@redhat.com> Message-ID: <20141125080637.GM28400@redhat.com> On Mon, 24 Nov 2014, Jan Cholasta wrote: >From bf1132192a9a0ac3ee41f24c56de6e911af51b78 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 18:10:27 +0000 >Subject: [PATCH 4/8] Fix unchecked return value in ipa-kdb > >https://fedorahosted.org/freeipa/ticket/4713 >--- > daemons/ipa-kdb/ipa_kdb_mspac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index c8f6c76..a450007 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -2070,7 +2070,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > 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); >+ (void)ipadb_reinit_mspac(ipactx, true); > } > } ACK -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 25 08:09:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:09:34 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <54733BAB.4050408@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <54733BAB.4050408@redhat.com> Message-ID: <20141125080934.GN28400@redhat.com> On Mon, 24 Nov 2014, Jan Cholasta wrote: >From fef20b5966b4a49cc8c230437cf8f06899b51840 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 24 Nov 2014 13:57:10 +0000 >Subject: [PATCH] Fix memory leak in GetKeytabControl asn1 code > >https://fedorahosted.org/freeipa/ticket/4713 >--- > asn1/ipa_asn1.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > >diff --git a/asn1/ipa_asn1.c b/asn1/ipa_asn1.c >index 50851a8..9efca96 100644 >--- a/asn1/ipa_asn1.c >+++ b/asn1/ipa_asn1.c >@@ -77,12 +77,12 @@ bool ipaasn1_enc_getktreply(int kvno, struct keys_container *keys, > { > GetKeytabControl_t gkctrl = { 0 }; > bool ret = false; >+ KrbKey_t *KK; > > gkctrl.present = GetKeytabControl_PR_reply; > gkctrl.choice.reply.newkvno = kvno; > > for (int i = 0; i < keys->nkeys; i++) { >- KrbKey_t *KK; > KK = calloc(1, sizeof(KrbKey_t)); > if (!KK) goto done; > KK->key.type = keys->ksdata[i].key.enctype; >@@ -109,9 +109,18 @@ bool ipaasn1_enc_getktreply(int kvno, struct keys_container *keys, > } > > ret = encode_GetKeytabControl(&gkctrl, buf, len); >+ KK = NULL; > > done: > ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_GetKeytabControl, &gkctrl); >+ if (KK) { >+ free(KK->key.value.buf); >+ if (KK->salt) { >+ free(KK->salt->value.buf); >+ free(KK->salt); >+ } >+ free(KK); >+ } > return ret; > } > ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 25 08:13:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:13:58 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <20141125081358.GO28400@redhat.com> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>From c2a03a9e062df5691431babeb55119dbda6b2c67 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 17:20:18 +0000 >Subject: [PATCH 1/7] Remove redefinition of LOG from ipa-otp-lasttoken > >https://fedorahosted.org/freeipa/ticket/4713 >--- > daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c | 3 --- > 1 file changed, 3 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >index d20fca1..15b404d 100644 >--- a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >@@ -47,9 +47,6 @@ > #include "util.h" > > #define PLUGIN_NAME "ipa-otp-lasttoken" >-#define LOG(sev, ...) \ >- slapi_log_error(SLAPI_LOG_ ## sev, PLUGIN_NAME, \ >- "%s: %s\n", __func__, __VA_ARGS__), -1 > > static void *plugin_id; > static const Slapi_PluginDesc preop_desc = { ACK, this definition, while it differs from what is in util.h, is not used anywhere in ipa_otp_lasttoken.c -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 25 08:18:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:18:40 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <20141125081840.GP28400@redhat.com> On Tue, 11 Nov 2014, Jan Cholasta wrote: >>From 10b309f53852665050465df8aa44290dfe232291 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Nov 2014 17:33:23 +0000 >Subject: [PATCH 2/7] Unload P11_Helper object's library when it is finalized > in ipap11helper > >https://fedorahosted.org/freeipa/ticket/4713 >--- > ipapython/ipap11helper/library.c | 5 +++++ > ipapython/ipap11helper/p11helper.c | 9 +++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > >diff --git a/ipapython/ipap11helper/library.c b/ipapython/ipap11helper/library.c >index 51e24eb..619604d 100644 >--- a/ipapython/ipap11helper/library.c >+++ b/ipapython/ipap11helper/library.c >@@ -70,6 +70,11 @@ CK_C_GetFunctionList loadLibrary(char* module, void** moduleHandle) > > // Retrieve the entry point for C_GetFunctionList > pGetFunctionList = (CK_C_GetFunctionList) dlsym(pDynLib, "C_GetFunctionList"); >+ if (pGetFunctionList == NULL) >+ { >+ dlclose(pDynLib); >+ return NULL; >+ } > > // Store the handle so we can dlclose it later > *moduleHandle = pDynLib; >diff --git a/ipapython/ipap11helper/p11helper.c b/ipapython/ipap11helper/p11helper.c >index 038c26c..558185e 100644 >--- a/ipapython/ipap11helper/p11helper.c >+++ b/ipapython/ipap11helper/p11helper.c >@@ -66,6 +66,7 @@ PyObject_HEAD > CK_SLOT_ID slot; > CK_FUNCTION_LIST_PTR p11; > CK_SESSION_HANDLE session; >+void *module_handle; > } P11_Helper; > > typedef enum { >@@ -478,6 +479,7 @@ P11_Helper_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { > self->slot = 0; > self->session = 0; > self->p11 = NULL; >+ self->module_handle = NULL; > } > > return (PyObject *) self; >@@ -496,12 +498,12 @@ static int P11_Helper_init(P11_Helper *self, PyObject *args, PyObject *kwds) { > CK_C_GetFunctionList pGetFunctionList = loadLibrary(library_path, > &module_handle); > if (!pGetFunctionList) { >- if (module_handle != NULL) >- unloadLibrary(module_handle); > PyErr_SetString(ipap11helperError, "Could not load the library."); > return -1; > } > >+ self->module_handle = module_handle; >+ > /* > * Load the function list > */ >@@ -567,9 +569,12 @@ P11_Helper_finalize(P11_Helper* self) { > */ > self->p11->C_Finalize(NULL); > >+ unloadLibrary(self->module_handle); >+ > self->p11 = NULL; > self->session = 0; > self->slot = 0; >+ self->module_handle = NULL; > > return Py_None; > } ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Nov 25 08:19:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:19:18 +0200 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <5461E13E.2080605@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> Message-ID: <20141125081918.GQ28400@redhat.com> On Tue, 11 Nov 2014, Jan Cholasta wrote: > Dne 10.11.2014 v 19:25 Jan Cholasta napsal(a): >> Hi, >> >> the attached patches provide additional fixes for >> . >> >> I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, >> please check them carefully. >> >> Honza > > Changed the ticket to . > > Updated patches attached. I think I've ACKed all individual patches. -- / Alexander Bokovoy From mkosek at redhat.com Tue Nov 25 08:22:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 09:22:31 +0100 Subject: [Freeipa-devel] [PATCH] 0675 copy_schema_to_ca: Fallback to old import location for ipaplatform.services In-Reply-To: <54735142.8040403@redhat.com> References: <54734982.3010500@redhat.com> <54735142.8040403@redhat.com> Message-ID: <54743C47.8010308@redhat.com> On 11/24/2014 04:39 PM, Petr Viktorin wrote: > This fixes a regression from the ipaplatform refactoring. > > https://fedorahosted.org/freeipa/ticket/4763 Tomas Babej acked this one via different communication channel :-) To avoid waiting for fixing mail and get this in upcoming 4.1.2, I just pushed it. Pushed to: master: e57b7b5e87f6510cce5a56e3f050d93b0fefe760 ipa-4-1: f287378534c9b3607b08f71b0c3aa17d2e4008dd Martin From jcholast at redhat.com Tue Nov 25 08:23:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Nov 2014 09:23:54 +0100 Subject: [Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes In-Reply-To: <20141125081918.GQ28400@redhat.com> References: <546102FF.9080307@redhat.com> <5461E13E.2080605@redhat.com> <20141125081918.GQ28400@redhat.com> Message-ID: <54743C9A.4000704@redhat.com> Dne 25.11.2014 v 09:19 Alexander Bokovoy napsal(a): > On Tue, 11 Nov 2014, Jan Cholasta wrote: >> Dne 10.11.2014 v 19:25 Jan Cholasta napsal(a): >>> Hi, >>> >>> the attached patches provide additional fixes for >>> . >>> >>> I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, >>> please check them carefully. >>> >>> Honza >> >> Changed the ticket to . >> >> Updated patches attached. > I think I've ACKed all individual patches. > Thanks for the review. Pushed to: master: d55936756d9593bb1c713dc4c1edd251a112c619 ipa-4-1: 94bc7a9431c3e44c4e0dcf84fbb0f0613ec86600 -- Jan Cholasta From mkosek at redhat.com Tue Nov 25 08:28:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 09:28:58 +0100 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <546DD9E4.3070807@redhat.com> References: <546DD9E4.3070807@redhat.com> Message-ID: <54743DCA.6010305@redhat.com> On 11/20/2014 01:09 PM, Martin Kosek wrote: > Hello, > > We seem to have enough content to release 4.1.2 that will be required to fix > some of the Fedora 21 blockers: > > https://bugzilla.redhat.com/show_bug.cgi?id=1165856 > https://bugzilla.redhat.com/show_bug.cgi?id=1165261 > > and Freeze exception: > https://bugzilla.redhat.com/show_bug.cgi?id=1165674 > > Current plan is to release stabilization release 4.1.2 with what we have as it > contains the important installation and upgrade fixes. > > The only problem there is that some patches require components that are not in > Fedora stable repos, more specifically commits: > > 7aa855a3 -> requiring new certmonger > 4e119311 -> requiring new pki-core > > We can release 4.1.2 with them, but they would need to be removed from Fedora > 21 downstream release and added back in normal 0day Fedora 21 update. > Alternative way would be to just include selected patches for existing Fedora > 21 build. > > Any comments, what else are missing in 4.1.2? I only know about > https://fedorahosted.org/freeipa/ticket/4718 > https://fedorahosted.org/freeipa/ticket/4728 > which is ACKed at the moment, AFAIK. We will need to release 4.1.2 today to make sure that the 4.1.2 release can be picked up in CentOS FreeIPA container. Petr1, I assume you will do the build now :-) We just need to make sure that any pending acked patches are pushed. We also need to make sure that our new dependencies (like the POODLE ones) that were built for Fedora are also in our CentOS repo so that FreeIPA 4.1.2 is still well installlable there. Thanks, Martin From jcholast at redhat.com Tue Nov 25 08:35:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Nov 2014 09:35:33 +0100 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <547347D2.4050302@redhat.com> References: <546E6AB1.4090504@redhat.com> <546F42F9.50902@redhat.com> <546F55BF.9090708@redhat.com> <54732EDC.5060404@redhat.com> <547347D2.4050302@redhat.com> Message-ID: <54743F55.4040903@redhat.com> Dne 24.11.2014 v 15:59 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 21.11.2014 v 16:09 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a): >>>>> Use new capability in python-nss-0.16 to use the NSS protocol range >>>>> setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections. >>>>> >>>>> I made this configurable via tls_protocol_range in case somebody wants >>>>> to override it. >>>>> >>>>> There isn't a whole ton of error handling on bad input but there is >>>>> enough, I think, to point the user in the the right direction. >>>>> >>>>> Added a couple more lines of debug output to include the negotiated >>>>> protocol and cipher. >>>>> >>>>> rob >>>> >>>> 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master) >>> >>> Attached. >>> >>>> 2) Could you split the option into two options, say "tls_version_min" >>>> and "tls_version_max"? IMO it would be easier to manage the version >>>> range that way, when for example you have to lower just the minimal >>>> version on a client to make it able to connect to a SSL3-only server. >>> >>> Sure. I waffled back and forth before deciding on a single value. >>> Separate values are probably less error-prone. >>> >>>> 3) Would it make sense to print a warning when the configured minimal >>>> TLS version is not safe and the connection uses a safe TLS version? This >>>> is for the case when you have to lower the minimal version on the client >>>> because of an old server, then the server gets updated, then you >>>> probably no longer want to have unsafe minimal version configured on the >>>> client. >>> >>> I see what you're saying but I think it could end up being just spam >>> that user's get used to. That and given that I'd probably want to set it >>> up to require tls1.1 as a minimum but we can't do that because dogtag >>> only supports through tls1.0 right now AFAICT. That'd be a lot of >>> warnings. >> >> You are probably right about the spam. Nevermind then. >> >>> >>>> Functionally the patch is OK. >>> >>> rob >>> >> >> Thanks for the patch, ACK. >> >> Fixed option names in commit message and pushed to: >> master: 5c0ad221e815e8c7b95c1d1095ebd6cf18e7e11c >> ipa-4-1: 8ef191448f0511b9c1749f47615437d649db0777 >> >> BTW before we can close the ticket, we are going to need a couple more >> fixes: >> >> 1) Bump required versions of 389-ds-base, pki-core and openldap, once >> the necessary fixes are available. > > Right, to be sure that POODLE is fully addressed. I will post a patch once we have all of them. > >> >> 2) Configure mod_nss to also support TLS 1.2. It should be done on both >> server install and upgrade. This requires a new version of mod_nss. > > mod_nss 1.0.10 in F-21 and rawhide should both support TLS 1.2 today. > > mod_nss is also very tolerant of bad/unknown protocols. It won't blow up > on unknown protocols. > > So if the given mod_nss doesn't support TLSv1.2 it will simply report an > error about an unknown protocol and configure the server for 1.0/1.1 if > configured as: > > NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 The attached patch 379 fixes this. > > rob > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-379-Add-TLS-1.2-to-the-protocol-list-in-mod_nss-config.patch Type: text/x-patch Size: 2777 bytes Desc: not available URL: From abokovoy at redhat.com Tue Nov 25 08:36:43 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Nov 2014 10:36:43 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <54743DCA.6010305@redhat.com> References: <546DD9E4.3070807@redhat.com> <54743DCA.6010305@redhat.com> Message-ID: <20141125083643.GR28400@redhat.com> On Tue, 25 Nov 2014, Martin Kosek wrote: >On 11/20/2014 01:09 PM, Martin Kosek wrote: >> Hello, >> >> We seem to have enough content to release 4.1.2 that will be required to fix >> some of the Fedora 21 blockers: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >> https://bugzilla.redhat.com/show_bug.cgi?id=1165261 >> >> and Freeze exception: >> https://bugzilla.redhat.com/show_bug.cgi?id=1165674 >> >> Current plan is to release stabilization release 4.1.2 with what we have as it >> contains the important installation and upgrade fixes. >> >> The only problem there is that some patches require components that are not in >> Fedora stable repos, more specifically commits: >> >> 7aa855a3 -> requiring new certmonger >> 4e119311 -> requiring new pki-core >> >> We can release 4.1.2 with them, but they would need to be removed from Fedora >> 21 downstream release and added back in normal 0day Fedora 21 update. >> Alternative way would be to just include selected patches for existing Fedora >> 21 build. >> >> Any comments, what else are missing in 4.1.2? I only know about >> https://fedorahosted.org/freeipa/ticket/4718 >> https://fedorahosted.org/freeipa/ticket/4728 >> which is ACKed at the moment, AFAIK. > >We will need to release 4.1.2 today to make sure that the 4.1.2 release can be >picked up in CentOS FreeIPA container. > >Petr1, I assume you will do the build now :-) We just need to make sure that >any pending acked patches are pushed. We also need to make sure that our new >dependencies (like the POODLE ones) that were built for Fedora are also in our >CentOS repo so that FreeIPA 4.1.2 is still well installlable there. My patch 0170 is needed for trusts to ease debugging in a typical case of firewall/replication issues. -- / Alexander Bokovoy From dkupka at redhat.com Tue Nov 25 08:51:12 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Nov 2014 09:51:12 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <547347B8.9080907@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> Message-ID: <54744300.4050106@redhat.com> On 11/24/2014 03:59 PM, Martin Basti wrote: > On 24/11/14 15:54, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4695 >> >> IMO this is one of two reasonable ways how to fix this ticket. >> The other one is to change just the manual page but it seems more >> consistent to use singular for metavars everywhere. >> >> > I like this approach. But IMO we should instead of "You ..." form in > help, this message, as we use with forwarders > > "This option can be used multiple times" > > Martin^2 > Our manual pages are not exactly unified in that but let's stay with the majority. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 11463 bytes Desc: not available URL: From dkupka at redhat.com Tue Nov 25 08:57:29 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Nov 2014 09:57:29 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <54744300.4050106@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> Message-ID: <54744479.6000904@redhat.com> On 11/25/2014 09:51 AM, David Kupka wrote: > On 11/24/2014 03:59 PM, Martin Basti wrote: >> On 24/11/14 15:54, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4695 >>> >>> IMO this is one of two reasonable ways how to fix this ticket. >>> The other one is to change just the manual page but it seems more >>> consistent to use singular for metavars everywhere. >>> >>> >> I like this approach. But IMO we should instead of "You ..." form in >> help, this message, as we use with forwarders >> >> "This option can be used multiple times" >> >> Martin^2 >> > Our manual pages are not exactly unified in that but let's stay with the > majority. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Wrong patch, sorry. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-2-master-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 11492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-2-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 11491 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 25 09:00:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Nov 2014 10:00:04 +0100 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA In-Reply-To: <20141124220901.478971f7@willson.usersys.redhat.com> References: <20141125083133.330ac915@franky.ipa.blackhats.net.au> <20141124220901.478971f7@willson.usersys.redhat.com> Message-ID: <54744514.8030308@redhat.com> On 25.11.2014 04:09, Simo Sorce wrote: > On Tue, 25 Nov 2014 08:31:33 +1030 > William B wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> I have been using FreeIPA for some time now. I have done a lot of >> testing for the project, and have a desire to see FreeIPA do well. >> >> As some background, I'm a system admin for a University, who currently >> runs an unmanaged instance of 389ds. In the future I would love to >> move to FreeIPA, but I want to explain some concerns first. >> >> I have always noticed that FreeIPA is feature rich, but over time I >> have noticed that this comes at a cost. Most components don't get as >> much testing as they deserve, and just installing and running FreeIPA >> for a few hours, one can quickly find rough edges and issues. Run it >> for longer, and you quickly find more. As a business we value >> reliable, and consistent software that doesn't have any "surprises" >> when we use it. Unforseen issues sour peoples taste for things like >> FreeIPA, as many people get stuck on their first impressions. >> >> With these features also comes a lack of advanced documentation. Too >> often the basics are well covered, but there are lots of simple tasks >> that an admin would wish to perform that aren't covered in the >> documentation. High quality, and advanced documentation is really key >> to my work, as not everyone has as much time as I might to learn the >> inside-out of FreeIPA. People want to reference documentation. Again, >> one only needs to sit down and use FreeIPA for a few days, to try and >> use it in their environment and you will quickly find that many tasks >> aren't covered by the documentation. The documentation itself is also >> hard to find, or out of date (Such as on fedoraproject.org, which is >> the first google hit for me). >> >> FreeIPA also pushes a some policies and ideas by default. Consider the >> password reset functionality. By default, when the password is reset, >> the password is also expired. In our environment, where we have a >> third party tool that does password resets on accounts (Password >> manager), this breaks our expectation as a user would then have to >> reset their password again in the FreeIPA environment. Little things >> like this remove flexibility and inhibit people making the swap. >> These options shouldn't be hardcoded, they should be defaults that >> can be tuned. If someone wants to do stupid things with those >> options, that is their choice, but that flexibility will help FreeIPA >> gain acceptance into businesses. >> >> Finally, back to our rich features. Not all businesses want all the >> features of FreeIPA. For example, we don't want the Dogtag CA, NTP, >> DNS or Kerberos components. But the default install, installs all >> these packages even if we don't use them, and it configures services >> that we don't necesarily need. Kerberos is especially a risk for us >> as there are plenty of unforseen issues that can arise when you have >> an AD kerberos domain on the same network, even if they live in >> different DNS namespaces. Contractors install systems into unix >> networks, unix systems end up in windows networks. Over time, as >> process and better discipline is involved, these little mistakes will >> be removed, but if we were to deploy FreeIPA tomorrow, I have no >> doubt the kerberos install would interfere with other parts of the >> network. I would really like to see the FreeIPA build, split into >> "freeipa-servers" and "freeipa-servers-core" where the core has only >> the 389ds, web ui and kerberos components, and perhaps even one day, >> could even be "kerberos free". This might be taking a step back in >> some ways, but the simplicity would be attractive to complex >> environments wanting to step up from unmanaged 389ds, to something >> like FreeIPA, but without all the complexity and overhead of a full >> install. Over time the extra modules can be enabled as administrators >> please in a controlled fashion. >> - - Yes, these things can be controlled through the use of the server >> install command line switches, but if I'm installing and using only >> 389 and krb from FreeIPA, I shouldn't need to install all of dogtag >> as well. >> >> >> These are just my thoughts on the project, and I think it boils down >> to a few things: >> >> * RFE to split freeipa packages to core and full. >> * Asking for a review and enhancement of documentation. >> * Better functional testing of FreeIPA server and tasks to help iron >> out obvious issues before release. >> >> Don't take this as harsh criticism. I think FreeIPA is a great >> project, and a great system. I would like to see it improve and be >> used more widely. > > Hi William, good news is, Dogtag, DNS and NTP are all optional > components, you can install a FreeIPa server withouth the CA and > without DNS. NTP is installed by default, but it is very easy to > diasable it if you want. > > Kerberos is a core feature and cannot be disabled, but I thing you > figured that out already. > > We have some plans to split the rpm packaging so that DNS and CA > components can be split into separate subpackages, however we are not > there yet, as some restructuring of the installer and framework will > need to happen to be able to completely omit some of the pieces. > > We are well aware of the shortcomings of the documentation, > unfortunately our upstream documentation effort died due to not enough > participation, so in the future the most up to date docs will be RHEL > docs. We'll add pointers to them in freeipa.org pages once we are happy > enough with them. > > On the testing side we are adding a lot of tests upstream that should > help improving test coverage and feature regressions, any help there is > welcome. > > We always welcome feedback and help with the project, whether it is > code, or additional HOWTOs documentation or even just specific bugs and > RFEs that point out specific issues or areas where we can do better. Of > course our resources are limited so we'll prioritize what is most > requested, sometimes at the expenses of features we'd really like to > see but have no way to fund development for in the short term. William, please open tickets for deficiencies you have found, preferably one ticket for one specific deficiency: https://fedorahosted.org/freeipa/newticket Splinting FreeIPA to separate packages is already tracked in https://fedorahosted.org/freeipa/ticket/4058 Also, you can help us with documentation yourself - feel free to edit pages http://www.freeipa.org/page/HowTos and http://www.freeipa.org/page/Documentation You will need an Fedora account - you can get one for free: https://admin.fedoraproject.org/accounts/user/new Have a nice day! -- Petr^2 Spacek From william at firstyear.id.au Tue Nov 25 09:42:45 2014 From: william at firstyear.id.au (William B) Date: Tue, 25 Nov 2014 20:12:45 +1030 Subject: [Freeipa-devel] RFE - Number of thoughts on FreeIPA In-Reply-To: <54744514.8030308@redhat.com> References: <20141125083133.330ac915@franky.ipa.blackhats.net.au> <20141124220901.478971f7@willson.usersys.redhat.com> <54744514.8030308@redhat.com> Message-ID: <20141125201245.6e2cd534@franky.ipa.blackhats.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you both for your responses. I have done some rearranging to allow my responses to make sense. > > > > Hi William, good news is, Dogtag, DNS and NTP are all optional > > components, you can install a FreeIPa server withouth the CA and > > without DNS. NTP is installed by default, but it is very easy to > > diasable it if you want. > > > > We have some plans to split the rpm packaging so that DNS and CA > > components can be split into separate subpackages, however we are > > not there yet, as some restructuring of the installer and framework > > will need to happen to be able to completely omit some of the > > pieces. > > > Splinting FreeIPA to separate packages is already tracked in > https://fedorahosted.org/freeipa/ticket/4058 > > Well this is good to know. It would be great to see this as a smaller core in my opinion means more focused testing on that area, and less can potentially go wrong. > > > > Kerberos is a core feature and cannot be disabled, but I thing you > > figured that out already. Yes, I did. That is why I suggested that perhaps a kerberos free mode could be something to help in the middle ground for groups who don't want to go "all out" just yet. > > We are well aware of the shortcomings of the documentation, > > unfortunately our upstream documentation effort died due to not > > enough participation, so in the future the most up to date docs > > will be RHEL docs. We'll add pointers to them in freeipa.org pages > > once we are happy enough with them. > Also, you can help us with documentation yourself - feel free to edit > pages http://www.freeipa.org/page/HowTos > and > http://www.freeipa.org/page/Documentation > > You will need an Fedora account - you can get one for free: > https://admin.fedoraproject.org/accounts/user/new Thanks. I'll have a look at both, and try to contribute. I was referring to the handbook also, but it sounds like those will be in-housed to Redhat soon, so I'll submit issues to that group in the future also. > > > > On the testing side we are adding a lot of tests upstream that > > should help improving test coverage and feature regressions, any > > help there is welcome. > > William, please open tickets for deficiencies you have found, > preferably one ticket for one specific deficiency: > https://fedorahosted.org/freeipa/newticket > I always try to open defects when they arise, but I was trying to say that sometimes as an administrator I feel that when a version of FreeIPA is released, it doesn't always seem to be as polished as it should be for something that is a key component to a network. When you say you are testing more, are you saying unit testing, or functional testing? > > > > We always welcome feedback and help with the project, whether it is > > code, or additional HOWTOs documentation or even just specific bugs > > and RFEs that point out specific issues or areas where we can do > > better. Of course our resources are limited so we'll prioritize > > what is most requested, sometimes at the expenses of features we'd > > really like to see but have no way to fund development for in the > > short term. I think the risk of adding more features is always that you add more complexitiy etc. Maybe as a suggestion, FreeIPA's codebase is not very modular. Maybe it should be split up to a "plugin system" similar to the 389ds plugin system. You have a core wrapper but most functionality comes from plugins. This would lower the barrier to entry for coding, it would allow split packaging to be easier, and make testing easier. - -- Sincerely, William Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUdE8VAAoJEO/EFteBqAmabo4QAJGug9sjk1sGtsKfbbIu2z8G BC9blQkFNKINEfTvZc3QcUjU+j5oLrIhVQt6vL1RCmAXf1tUANl8qn+rHcWT7O2v 1VGlteZAT+YvB8BynNlk2b8cbGOkMpcJ2CvW1Km6eIc7MIzVj/UTCH5GvJdp+fq1 fqqJZWb2QT2v88pZcbyYE9f3LkCK6I2Me3DQ+AMhu3qLBpL8niB3lW/GcTMM1+7i ccyXkIB/tn1h3ki/utpkXvzP2YtzkDILCw2ZgUZvLQDYc5LJHM+4P2Wrvzm3dzK2 6ycY1FM+JHB5xOLRO6wmg1auPNRQ6zUFCkl2u9HpouHpYvc8AZYsl39LuyP4CZzr 9StaZM/tuItJ790fCtVShXFV230/dUgmU7NyCN9I06HDuPdsEvuyNmz7G5YDbTnq mncVUJkoCgA0ADXt4M7tqxNajyuE+zpMpzLmm/j/Gf1gTNSrpDyZQoaUHau2EDlm H01YFSNclAqH1oqrJl3i0QX8BbOOz15jfR7ed+uDlkj7MYfL4XRkBaiZ3lmhiAxg V1cXA8aOmq3bW1z9JG0IuZerh6YjKWBziNr5JbRHwO//Bc1GrXFqT/XpxljS1Mh4 gPFOqQu0wi2h0jPDw7J8/FTIueYSrVCQKxgY//bFOwA1l8wriSrv5v3mISFMqAMj C9m4X+sdivz0mIGSx0kR =IVCe -----END PGP SIGNATURE----- From pspacek at redhat.com Tue Nov 25 09:43:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Nov 2014 10:43:11 +0100 Subject: [Freeipa-devel] Gaps in upstream tests In-Reply-To: <545CCC22.9040501@redhat.com> References: <545CCC22.9040501@redhat.com> Message-ID: <54744F2F.9070904@redhat.com> On 7.11.2014 14:41, Martin Kosek wrote: > FreeIPA team will soon grow with a new member focusing on upstream QE tests. I > would like to collect ideas what are the biggest gaps in the current upstream > test suite from your POV. > > Existing requests are tracked here: > https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Tests&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=milestone&group=milestone&order=priority > > > First idea that I head proposed are Upgrade tests. These are often done > manually. I think that upgrade test from currently supported FreeIPA/Fedora > version would go a long way (like 3.3.5 on F20 upgraded built RPMs and running > unit tests). > > Second, it would be nice to try testing FreeIPA server in a container. Not > only it would verify our container efforts, but it may also allow easy > multi-master tests on one Jenkins VM or local host instead of expensive VM > orchestration. > > Any other areas worth focusing on (besides of course testing newly developed > features)? At least simple automated MitM attack against TLS. First thing which comes to mind is CLI<->server interaction and also certmonger<->server interaction. TLS is hard to get right and if I recall it correctly we already had a problem with certificate validation... -- Petr^2 Spacek From mkosek at redhat.com Tue Nov 25 09:56:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 10:56:28 +0100 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <20141125083643.GR28400@redhat.com> References: <546DD9E4.3070807@redhat.com> <54743DCA.6010305@redhat.com> <20141125083643.GR28400@redhat.com> Message-ID: <5474524C.1090101@redhat.com> On 11/25/2014 09:36 AM, Alexander Bokovoy wrote: > On Tue, 25 Nov 2014, Martin Kosek wrote: >> On 11/20/2014 01:09 PM, Martin Kosek wrote: >>> Hello, >>> >>> We seem to have enough content to release 4.1.2 that will be required to fix >>> some of the Fedora 21 blockers: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165261 >>> >>> and Freeze exception: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1165674 >>> >>> Current plan is to release stabilization release 4.1.2 with what we have as it >>> contains the important installation and upgrade fixes. >>> >>> The only problem there is that some patches require components that are not in >>> Fedora stable repos, more specifically commits: >>> >>> 7aa855a3 -> requiring new certmonger >>> 4e119311 -> requiring new pki-core >>> >>> We can release 4.1.2 with them, but they would need to be removed from Fedora >>> 21 downstream release and added back in normal 0day Fedora 21 update. >>> Alternative way would be to just include selected patches for existing Fedora >>> 21 build. >>> >>> Any comments, what else are missing in 4.1.2? I only know about >>> https://fedorahosted.org/freeipa/ticket/4718 >>> https://fedorahosted.org/freeipa/ticket/4728 >>> which is ACKed at the moment, AFAIK. >> >> We will need to release 4.1.2 today to make sure that the 4.1.2 release can be >> picked up in CentOS FreeIPA container. >> >> Petr1, I assume you will do the build now :-) We just need to make sure that >> any pending acked patches are pushed. We also need to make sure that our new >> dependencies (like the POODLE ones) that were built for Fedora are also in our >> CentOS repo so that FreeIPA 4.1.2 is still well installlable there. > My patch 0170 is needed for trusts to ease debugging in a typical case > of firewall/replication issues. I see patch 0170 as a useful patch, but not as blocking for 4.1.2 which we need for the CentOS containers. IMO it can wait for 4.1.3. Martin From tbabej at redhat.com Tue Nov 25 11:24:42 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Nov 2014 12:24:42 +0100 Subject: [Freeipa-devel] [PATCH] 0170 AD Trust: improve trust validation In-Reply-To: <20141124132319.GD28400@redhat.com> References: <20141124132319.GD28400@redhat.com> Message-ID: <547466FA.5000202@redhat.com> On 11/24/2014 02:23 PM, Alexander Bokovoy wrote: > Hi, > > Trust validation requires AD DC to contact IPA server to verify that > trust account actually works. It can fail due to DNS or firewall issue > or if AD DC was able to resolve IPA master(s) via SRV records, it still > may contact a replica that has no trust data replicated yet. > > In case AD DC still returns 'access denied', wait 5 seconds and try > validation again. Repeat validation until we hit a limit of 10 > attempts, at which point raise exception telling what's happening. > > https://fedorahosted.org/freeipa/ticket/4764 > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. In the broken setup, we now correctly output: [tbabej at vm-093 labtool]$ echo $AD_PASSWORD | ipa trust-add --type=ad $AD_DOMAIN --admin Administrator --password ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue Pushed to: master: ed3dddab870563b398400b05af3d945e8fc2ec9d ipa-4-1: 538e023107ed307142ca7302ff34106c53afa932 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Nov 25 11:47:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 12:47:40 +0100 Subject: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter In-Reply-To: <54743F55.4040903@redhat.com> References: <546E6AB1.4090504@redhat.com> <546F42F9.50902@redhat.com> <546F55BF.9090708@redhat.com> <54732EDC.5060404@redhat.com> <547347D2.4050302@redhat.com> <54743F55.4040903@redhat.com> Message-ID: <54746C5C.9060100@redhat.com> On 11/25/2014 09:35 AM, Jan Cholasta wrote: > Dne 24.11.2014 v 15:59 Rob Crittenden napsal(a): ... >>> 2) Configure mod_nss to also support TLS 1.2. It should be done on both >>> server install and upgrade. This requires a new version of mod_nss. >> >> mod_nss 1.0.10 in F-21 and rawhide should both support TLS 1.2 today. >> >> mod_nss is also very tolerant of bad/unknown protocols. It won't blow up >> on unknown protocols. >> >> So if the given mod_nss doesn't support TLSv1.2 it will simply report an >> error about an unknown protocol and configure the server for 1.0/1.1 if >> configured as: >> >> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 > > The attached patch 379 fixes this. Works for me, ACK! Pushed to: master: bef1d18878118aea379659bb10d78c1e955b0b63 ipa-4-1: dc443cc4503822cb35c3693e5e525425573140f2 Martin From mkosek at redhat.com Tue Nov 25 11:48:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 12:48:17 +0100 Subject: [Freeipa-devel] Releasing FreeIPA 4.1.2 In-Reply-To: <5474524C.1090101@redhat.com> References: <546DD9E4.3070807@redhat.com> <54743DCA.6010305@redhat.com> <20141125083643.GR28400@redhat.com> <5474524C.1090101@redhat.com> Message-ID: <54746C81.8050908@redhat.com> On 11/25/2014 10:56 AM, Martin Kosek wrote: > On 11/25/2014 09:36 AM, Alexander Bokovoy wrote: >> On Tue, 25 Nov 2014, Martin Kosek wrote: >>> On 11/20/2014 01:09 PM, Martin Kosek wrote: >>>> Hello, >>>> >>>> We seem to have enough content to release 4.1.2 that will be required to fix >>>> some of the Fedora 21 blockers: >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1165856 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1165261 >>>> >>>> and Freeze exception: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1165674 >>>> >>>> Current plan is to release stabilization release 4.1.2 with what we have as it >>>> contains the important installation and upgrade fixes. >>>> >>>> The only problem there is that some patches require components that are not in >>>> Fedora stable repos, more specifically commits: >>>> >>>> 7aa855a3 -> requiring new certmonger >>>> 4e119311 -> requiring new pki-core >>>> >>>> We can release 4.1.2 with them, but they would need to be removed from Fedora >>>> 21 downstream release and added back in normal 0day Fedora 21 update. >>>> Alternative way would be to just include selected patches for existing Fedora >>>> 21 build. >>>> >>>> Any comments, what else are missing in 4.1.2? I only know about >>>> https://fedorahosted.org/freeipa/ticket/4718 >>>> https://fedorahosted.org/freeipa/ticket/4728 >>>> which is ACKed at the moment, AFAIK. >>> >>> We will need to release 4.1.2 today to make sure that the 4.1.2 release can be >>> picked up in CentOS FreeIPA container. >>> >>> Petr1, I assume you will do the build now :-) We just need to make sure that >>> any pending acked patches are pushed. We also need to make sure that our new >>> dependencies (like the POODLE ones) that were built for Fedora are also in our >>> CentOS repo so that FreeIPA 4.1.2 is still well installlable there. >> My patch 0170 is needed for trusts to ease debugging in a typical case >> of firewall/replication issues. > > I see patch 0170 as a useful patch, but not as blocking for 4.1.2 which we need > for the CentOS containers. IMO it can wait for 4.1.3. > > Martin Ok, you won - the patch was reviewed fast enough so it ends up in 4.1.2 :-) We can go ahead with 4.1.2 tagging then. Martin From dkupka at redhat.com Tue Nov 25 12:16:21 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Nov 2014 13:16:21 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <54744479.6000904@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> Message-ID: <54747315.7050103@redhat.com> On 11/25/2014 09:57 AM, David Kupka wrote: > On 11/25/2014 09:51 AM, David Kupka wrote: >> On 11/24/2014 03:59 PM, Martin Basti wrote: >>> On 24/11/14 15:54, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4695 >>>> >>>> IMO this is one of two reasonable ways how to fix this ticket. >>>> The other one is to change just the manual page but it seems more >>>> consistent to use singular for metavars everywhere. >>>> >>>> >>> I like this approach. But IMO we should instead of "You ..." form in >>> help, this message, as we use with forwarders >>> >>> "This option can be used multiple times" >>> >>> Martin^2 >>> >> Our manual pages are not exactly unified in that but let's stay with the >> majority. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Wrong patch, sorry. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Extending help messages too. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-3-master-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12564 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-3-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12563 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 25 13:07:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 14:07:34 +0100 Subject: [Freeipa-devel] [PATCH 0172] Fix zonemgr option encoding detection Message-ID: <54747F16.6000608@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4766 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0172-Fix-zonemgr-option-encoding-detection.patch Type: text/x-patch Size: 1179 bytes Desc: not available URL: From tbabej at redhat.com Tue Nov 25 13:08:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Nov 2014 14:08:19 +0100 Subject: [Freeipa-devel] [PATCH] 787 webui: add radius fields to user page In-Reply-To: <5464B21C.2060509@redhat.com> References: <5464B21C.2060509@redhat.com> Message-ID: <54747F43.7010008@redhat.com> On 11/13/2014 02:29 PM, Petr Vobornik wrote: > add --radius=ID --radius-username=radiusUserName to Web UI > > https://fedorahosted.org/freeipa/ticket/4686 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Pushed to: master: 4d1ce9e422c139cff2ec1de798a34f13c9b6fb95 ipa-4-1: 9e18d59d79ba719176929e27499ef2933567b325 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Nov 25 13:16:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Nov 2014 14:16:37 +0100 Subject: [Freeipa-devel] [PATCH 0172] Fix zonemgr option encoding detection In-Reply-To: <54747F16.6000608@redhat.com> References: <54747F16.6000608@redhat.com> Message-ID: <54748135.1090206@redhat.com> Hi, Dne 25.11.2014 v 14:07 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4766 > Patch attached. > Thanks, ACK. Hopefully it's correct this time. Pushed to: master: c13862104ab64cda81c86c51b849c8d01c3c9187 ipa-4-1: e457a3e615b695cfd98e7d54594e5a3663562b06 Honza -- Jan Cholasta From jcholast at redhat.com Tue Nov 25 13:16:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Nov 2014 14:16:44 +0100 Subject: [Freeipa-devel] [PATCH 0172] Fix zonemgr option encoding detection In-Reply-To: <54747F16.6000608@redhat.com> References: <54747F16.6000608@redhat.com> Message-ID: <5474813C.3030902@redhat.com> Hi, Dne 25.11.2014 v 14:07 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4766 > Patch attached. > Thanks, ACK. Hopefully it's correct this time. Pushed to: master: c13862104ab64cda81c86c51b849c8d01c3c9187 ipa-4-1: e457a3e615b695cfd98e7d54594e5a3663562b06 Honza -- Jan Cholasta From tbabej at redhat.com Tue Nov 25 13:26:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Nov 2014 14:26:40 +0100 Subject: [Freeipa-devel] [PATCH] drop archeological feature :) In-Reply-To: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> References: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> Message-ID: <54748390.3020209@redhat.com> On 11/24/2014 07:10 PM, Simo Sorce wrote: > Getting through krbinstancepy I discovered we are still doing this > thing with the master key that has been unnecessary for a few years now. > > Stop doing that. > > I haven't really tested this yet ... but ... what could possibly go > wrong ? :-D > > Simo. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel https://fedorahosted.org/freeipa/ticket/4767 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Nov 25 13:58:42 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Nov 2014 08:58:42 -0500 Subject: [Freeipa-devel] [PATCH] drop archeological feature :) In-Reply-To: <54748390.3020209@redhat.com> References: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> <54748390.3020209@redhat.com> Message-ID: <20141125085842.656f8dcb@willson.usersys.redhat.com> On Tue, 25 Nov 2014 14:26:40 +0100 Tomas Babej wrote: > > On 11/24/2014 07:10 PM, Simo Sorce wrote: > > Getting through krbinstancepy I discovered we are still doing this > > thing with the master key that has been unnecessary for a few years > > now. > > > > Stop doing that. > > > > I haven't really tested this yet ... but ... what could possibly go > > wrong ? :-D > > > > Simo. > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > https://fedorahosted.org/freeipa/ticket/4767 > Oh I did not think of opening a ticket, thanks Tomas! Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Nov 25 14:23:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 15:23:19 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <54747315.7050103@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> Message-ID: <547490D7.2000606@redhat.com> On 25/11/14 13:16, David Kupka wrote: > On 11/25/2014 09:57 AM, David Kupka wrote: >> On 11/25/2014 09:51 AM, David Kupka wrote: >>> On 11/24/2014 03:59 PM, Martin Basti wrote: >>>> On 24/11/14 15:54, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4695 >>>>> >>>>> IMO this is one of two reasonable ways how to fix this ticket. >>>>> The other one is to change just the manual page but it seems more >>>>> consistent to use singular for metavars everywhere. >>>>> >>>>> >>>> I like this approach. But IMO we should instead of "You ..." form in >>>> help, this message, as we use with forwarders >>>> >>>> "This option can be used multiple times" >>>> >>>> Martin^2 >>>> >>> Our manual pages are not exactly unified in that but let's stay with >>> the >>> majority. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Wrong patch, sorry. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Extending help messages too. > NACK, you edited wrong option --no-reverse Do not create reverse DNS zone. This option can be used multiple times -- Martin Basti From dkupka at redhat.com Tue Nov 25 14:44:00 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Nov 2014 15:44:00 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <547490D7.2000606@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> <547490D7.2000606@redhat.com> Message-ID: <547495B0.7000102@redhat.com> On 11/25/2014 03:23 PM, Martin Basti wrote: > On 25/11/14 13:16, David Kupka wrote: >> On 11/25/2014 09:57 AM, David Kupka wrote: >>> On 11/25/2014 09:51 AM, David Kupka wrote: >>>> On 11/24/2014 03:59 PM, Martin Basti wrote: >>>>> On 24/11/14 15:54, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4695 >>>>>> >>>>>> IMO this is one of two reasonable ways how to fix this ticket. >>>>>> The other one is to change just the manual page but it seems more >>>>>> consistent to use singular for metavars everywhere. >>>>>> >>>>>> >>>>> I like this approach. But IMO we should instead of "You ..." form in >>>>> help, this message, as we use with forwarders >>>>> >>>>> "This option can be used multiple times" >>>>> >>>>> Martin^2 >>>>> >>>> Our manual pages are not exactly unified in that but let's stay with >>>> the >>>> majority. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Wrong patch, sorry. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Extending help messages too. >> > NACK, you edited wrong option > > --no-reverse Do not create reverse DNS zone. This option can be > used multiple times > > Bad line, thanks for noticing, fixed patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-4-master-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-4-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12544 bytes Desc: not available URL: From mkosek at redhat.com Tue Nov 25 15:29:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 16:29:33 +0100 Subject: [Freeipa-devel] FereIPA 4.1.2 build for CentOS Message-ID: <5474A05D.6080700@redhat.com> Hello, I checked the dependencies of FreeIPA 4.1.2 on top of 4.1.1, it missed certmonger and python-nss build. certmonger build went fine, but python-nss failed: http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/epel-7-x86_64/python-nss-0.16.0-0.fc20/build.log John, what would be your recommendation for building python-nss (supporting the new TLS min/max) for the CentOS Copr? I would like to avoid building whole NSS package suite. In the meantime, I think FreeIPA spec should have a "%if 0{%rhel}" statement which adds a patch reverting the patch adding the python-nss requirement so that we allow people testing 4.1.2 on CentOS. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Tue Nov 25 15:47:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Nov 2014 16:47:43 +0100 Subject: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location In-Reply-To: <1415860778.9222.0.camel@redhat.com> References: <1415375478.8166.1.camel@redhat.com> <546065BC.1010607@redhat.com> <20141110073123.GE4107@redhat.com> <54607288.7040009@redhat.com> <1415860778.9222.0.camel@redhat.com> Message-ID: <5474A49F.1010200@redhat.com> On 11/13/2014 07:39 AM, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 09:08 +0100, Martin Kosek wrote: >> On 11/10/2014 08:31 AM, Alexander Bokovoy wrote: >>> On Mon, 10 Nov 2014, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4693 >>>> >>>> Is it good enough to just say "No YubiKey found"? Would it make sense to log >>>> the original message, for the sake of debugging why the yubikey was not found? >>> This is logged on the client side so it only would be visible if you >>> would run 'ipa' tool with -v. Perhaps useful but my practice with >>> yubikeys says that most of issues are basically permission-related: >>> you've inserted the key and udev rules didn't change access to allow >>> getting to it via libusb. In this case our debugging will hardly be >>> helpful beyond 'yes, it is not accessible' which is already conveyed by >>> the original message. >> >> Ok. Though IMO, passing the USBError string to the error would still be a good >> thing to do - unless we have a strong reason to hide it. Error stating "Access >> denied (insufficient permissions)" would steer the person closer to the root >> cause that just "No YubiKey found". > > It took a bit to figure out exactly how to handle the errors, but the > attached patch passes the error codes through. > Yup, this is exactly what I wanted to see, ACK! Pushed to: master: b3a6701e73f6ccd4dff1dab47554381f42d40bb4 ipa-4-1: a7a7e967580c8ef4fa4341aa8b8877128e7d822a Martin From tbordaz at redhat.com Tue Nov 25 16:58:25 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 25 Nov 2014 17:58:25 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <546B9D66.5010704@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> Message-ID: <5474B531.2090003@redhat.com> On 11/18/2014 08:26 PM, Petr Vobornik wrote: > On 13.11.2014 08:53, Martin Kosek wrote: >> On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: >>> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: >>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>> This patch gives the administrator variables to control >>>>>>>>>>>>>> the size of >>>>>>>>>>>>>> the authentication and synchronization windows for OTP >>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>>>> >>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I >>>>>>>>>>>>>> don't know >>>>>>>>>>>>>> how to >>>>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear >>>>>>>>>>>>>> correctly. >>>>>>>>>>>>>> However, >>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not >>>>>>>>>>>>>> show up >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>>>> >>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this >>>>>>>>>>>>>> patch >>>>>>>>>>>>>> works >>>>>>>>>>>>>> just fine. >>>>>>>>>>>>> >>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>>>> attribute >>>>>>>>>>>>> names. >>>>>>>>>>>> >>>>>>>>>>>> Thanks Nathaniel! >>>>>>>>>>>> >>>>>>>>>>>>> The above known issue still remains. >>>>>>>>>>>> >>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY >>>>>>>>>>>> list >>>>>>>>>>>> extension >>>>>>>>>>>> should work just fine, AFAIK. >>>>>>>>>>> >>>>>>>>>>> You added a blank line to the LDIF file. This is an entry >>>>>>>>>>> separator, so >>>>>>>>>>> the objectClasses after the blank line don't belong to >>>>>>>>>>> cn=schema, so >>>>>>>>>>> they aren't considered in the update. >>>>>>>>>>> Without the blank line it works fine. >>>>>>>>>> >>>>>>>>>> Thanks for the catch! >>>>>>>>>> >>>>>>>>>> Here is a version without the blank line. >>>>>>>>> >>>>>>>>> I forgot to remove the old steps defines. This patch performs >>>>>>>>> this >>>>>>>>> cleanup. >>>>>>>> >>>>>>>> I am now wondering, is the global config object really the nest >>>>>>>> place to >>>>>>>> add these OTP specific settings? >>>>>>>> >>>>>>>> I would prefer not to overload the object and instead: >>>>>>>> - create new ipaOTPConfig objectclass >>>>>>>> - add it to cn=otp,$SUFFIX >>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an >>>>>>>> example >>>>>>>> of dnsconfig-* and trustconfig-* commands >>>>>>>> >>>>>>>> IMO, this would allow more flexibility for the OTP settings and >>>>>>>> would >>>>>>>> also scale better for the future updates. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I will comment the patch as if ^^ would not exist because it >>>>>>> will still be >>>>>>> needed in the new plugin. >>>>>>> >>>>>>> Because of ^^ I did not test, just read. >>>>>>> >>>>>>> 1. Got: >>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra >>>>>>> comma is not >>>>>>> recommended in array initializers >>>>>>> >>>>>>> Please run: >>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>>>> in install/ui directory >>>>>>> >>>>>>> The goal is no have no warnings and errors. >>>>>>> >>>>>>> 2. new attrs should be added to 'System: Read Global >>>>>>> Configuration' managed >>>>>>> permission >>>>>> >>>>>> +1. Though if we go with OTP config, it should be called >>>>>> >>>>>> System: Read OTP Configuration >>>>>> >>>>>> Martin >>>>> >>>>> Attached is a new set of patches that replaces this single patch. >>>>> This >>>>> now fixes multiple issues. >>>>> >>>>> I now create two new entries: >>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>>>> >>>>> There are two corresponding CLI commands: >>>>> * totpconfig-(show|mod) >>>>> * hotpconfig-(show|mod) >>>>> >>>>> There is no UI support for this yet (pointers welcome). >>>>> >>>>> This is designed so that eventually tokens can grow a per-token >>>>> override, but I have not yet implemented this feature (it should >>>>> be easy >>>>> in the future). >>>>> >>>>> Additionally, I had to do some shared refactoring to address >>>>> issues in >>>>> ipa-otp-lasttoken, which is why all of these are now merged into a >>>>> single patch set. >>>>> >>>>> Nathaniel > > I'm little confused with a state of reviews. Thierry were some of the > patches ACKed in different threads or are they under review (I'm not > reviewing DS plugin parts)? I am sorry for the long delay... I am having difficulties to apply the patches. I am on master branch. For example I see those errors: git apply -v /tmp/0001-Preliminary-refactoring-of-libotp-files.patch Checking patch daemons/ipa-slapi-plugins/ipa-otp-lasttoken/Makefile.am... Checking patch daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c... error: while searching for: # include #endif #include #include #include "util.h" #define PLUGIN_NAME "ipa-otp-lasttoken" #define LOG(sev, ...) \ slapi_log_error(SLAPI_LOG_ ## sev, PLUGIN_NAME, \ "%s: %s\n", __func__, __VA_ARGS__), -1 static void *plugin_id; static const Slapi_PluginDesc preop_desc = { error: patch failed: daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c:41 error: daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c: patch does not apply Checking patch daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am... error: while searching for: AM_CPPFLAGS = \ -I. \ -I$(srcdir) \ -I$(srcdir)/../libotp \ -I$(PLUGIN_COMMON_DIR) \ -I$(KRB5_UTIL_DIR) \ -I$(COMMON_BER_DIR) \ error: patch failed: daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am:10 error: daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am: patch does not apply Checking patch daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h... Checking patch daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c... Checking patch daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c... Checking patch daemons/ipa-slapi-plugins/libotp/Makefile.am... Checking patch daemons/ipa-slapi-plugins/libotp/librfc.c => daemons/ipa-slapi-plugins/libotp/hotp.c... Checking patch daemons/ipa-slapi-plugins/libotp/librfc.h => daemons/ipa-slapi-plugins/libotp/hotp.h... Checking patch daemons/ipa-slapi-plugins/libotp/libotp.c => daemons/ipa-slapi-plugins/libotp/otp_token.c... Checking patch daemons/ipa-slapi-plugins/libotp/libotp.h => daemons/ipa-slapi-plugins/libotp/otp_token.h... Checking patch daemons/ipa-slapi-plugins/libotp/t_librfc.c => daemons/ipa-slapi-plugins/libotp/t_hotp.c... Anyone would help me seeing what I am missing here :-[ > > >>>>> >>>> >>>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but >>>> if we want >>>> to make TOTP/HOTP token config as separate entries (to enable >>>> future per-token >>>> overrides), your approach should make sense. Rather adding Rob to >>>> CC for sanity. >>> >>> That would work too. I'm open to that. >>> >>>> I am just not sure we should create them as separate plugins, I >>>> think the new >>>> commands should be rather added to otp plugin directly so that they >>>> show in >>>> "ipa help otptoken" instead of adding 2 new topics just for OTP >>>> config. >>> >>> I can play with that. > > Do you plan to change it? I like the idea of a single point of help > for OTP but I'm also unsure about the length of the commands. Current > solution is also more consistent with a rest of the framework. Would > it be something like: > > otptoken-totpconfig-(show|mod) > otptoken-hotpconfig-(show|mod) > > Maybe it would be better to introduce more help topics for otp. This > concept is used for HBAC already: > > $ ipa help hbac > hbacsvcgroup HBAC Service Groups > hbacsvc HBAC Services > hbacrule Host-based access control > > $ ipa help hbacrule > Host-based access control > ... a lot of text > > So we could introduce otp umbrella topic: > > $ ipa help otp > opttoken OTP tokens' > totpconfig TOTP configuration options > hotpconfig HOTP configuration options > > >>> >>> Nathaniel >> >> No worries ATM, you can wait for proper review. I was just looking at >> the new >> API to make sure we are on the same page - we seem to mostly are. >> >> Martin >> > > Commenting just patch 0004: > > 1. Requires rebase because of API change. > > 2. git diff HEAD~4 -U0 | pep8 --diff > I would ignore E124 and fix E302 (5x) > > I did not test actual functionality yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 25 17:11:25 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Nov 2014 18:11:25 +0100 Subject: [Freeipa-devel] [PATCH 0309] Fix crash caused by interaction between forward and master zones Message-ID: <5474B83D.4020201@redhat.com> Hello, Fix crash caused by interaction between forward and master zones. LDAP modifications made to idnsName=sub, idnsName=example.com, cn=dns object were incorrectly processed using update_zone() in cases where forward zone sub.example.com. existed in LDAP as object idnsName=sub.example.com, cn=dns. https://fedorahosted.org/bind-dyndb-ldap/ticket/145 Tomas and Martin^2, please review it ASAP. Thank you! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0309-Fix-crash-caused-by-interaction-between-forward-and-.patch Type: text/x-patch Size: 4355 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 25 17:27:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Nov 2014 18:27:42 +0100 Subject: [Freeipa-devel] [PATCH 0310] Fix misleading error message about forward zones on reconnect Message-ID: <5474BC0E.5030003@redhat.com> Hello, Fix misleading error message about forward zones on reconnect. Previously the plugin could log 'already exist' error after successful reconnection to LDAP for each active forward zone. Now it prints message: forward zone 'fw.example.com': loaded -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0310-Fix-misleading-error-message-about-forward-zones-on-.patch Type: text/x-patch Size: 1454 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 25 18:07:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 19:07:49 +0100 Subject: [Freeipa-devel] [PATCH 0309] Fix crash caused by interaction between forward and master zones In-Reply-To: <5474B83D.4020201@redhat.com> References: <5474B83D.4020201@redhat.com> Message-ID: <5474C575.5020009@redhat.com> On 25/11/14 18:11, Petr Spacek wrote: > Hello, > > Fix crash caused by interaction between forward and master zones. > > LDAP modifications made to idnsName=sub, idnsName=example.com, cn=dns object > were incorrectly processed using update_zone() in cases where forward zone > sub.example.com. existed in LDAP as object idnsName=sub.example.com, cn=dns. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/145 > > > Tomas and Martin^2, please review it ASAP. Thank you! > Works for me, IPA tests passed, can you Tomas check the code before push? -- Martin Basti From mbasti at redhat.com Tue Nov 25 18:25:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 19:25:15 +0100 Subject: [Freeipa-devel] [PATCH 0310] Fix misleading error message about forward zones on reconnect In-Reply-To: <5474BC0E.5030003@redhat.com> References: <5474BC0E.5030003@redhat.com> Message-ID: <5474C98B.4070405@redhat.com> On 25/11/14 18:27, Petr Spacek wrote: > Hello, > > Fix misleading error message about forward zones on reconnect. > > Previously the plugin could log 'already exist' error after > successful reconnection to LDAP for each active forward zone. > > Now it prints message: > forward zone 'fw.example.com': loaded > > Log looks better now, ACK if Tomas has no objections. -- Martin Basti From mbasti at redhat.com Tue Nov 25 18:48:59 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 19:48:59 +0100 Subject: [Freeipa-devel] [PATCH 0308] Improve detection of BIND 9 isc__errno2result header file In-Reply-To: <5463788B.3060107@redhat.com> References: <5463788B.3060107@redhat.com> Message-ID: <5474CF1B.7080501@redhat.com> On 12/11/14 16:11, Petr Spacek wrote: > Hello, > > Improve detection of BIND 9 isc__errno2result header file. > > This header file is not in standard distribution so normal isc-config.sh > detection is not enough. > > With this patch, ./configure should work even without explicit CFLAGS and it > should also detect that bind-devel or bind-lite-devel packages are missing. > > Works for me -- Martin Basti From mbasti at redhat.com Tue Nov 25 18:53:00 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Nov 2014 19:53:00 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <54637E1E.8090009@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> Message-ID: <5474D00C.3020001@redhat.com> On 12/11/14 16:34, Petr Spacek wrote: > On 25.2.2014 15:05, Lukas Slebodnik wrote: >> On (25/02/14 09:54), Petr Spacek wrote: >>> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>>> On (24/02/14 16:48), Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Drop unnecessary #define _BSD_SOURCE. >>>>> >>>>> -- >>>>> Petr^2 Spacek >>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>>> From: Petr Spacek >>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>>> >>>>> Signed-off-by: Petr Spacek >>>>> --- >>>>> src/krb5_helper.c | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>>> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>>> --- a/src/krb5_helper.c >>>>> +++ b/src/krb5_helper.c >>>>> @@ -15,8 +15,6 @@ >>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>>> */ >>>>> >>>>> -#define _BSD_SOURCE >>>>> - >>>>> #include >>>>> #include >>>>> #include >>>>> -- >>>>> 1.8.5.3 >>>>> >>>> Simo is an author (according to git blame) >>>> He defined this macro due to function setenv >>>> >>> >from man setenv: >>>> NAME >>>> setenv - change or add an environment variable >>>> >>>> SYNOPSIS >>>> #include >>>> >>>> int setenv(const char *name, const char *value, int overwrite); >>>> >>>> int unsetenv(const char *name); >>>> >>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>>> >>>> setenv(), unsetenv(): >>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>>> ---------------------------------------------------------------------------- >>>> >>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>>> header file . I tested only on fedora 20. It can be used >>>> on the other distributions. >>>> >>>> I would rather let this macro as is. >>> Wow, I didn't expect that somebody will spend time on this :-) >>> >>> See build logs from Fedora 21 >>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log >> You should have noticed this in the 1st mail. Because it is difference between >> removing unnecessary macro and depprecated usage of macro. >> >> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE >> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >> >>> Patches with 'the right' solution are welcome. I'm not going to spend >>> more time on this. > Attached patch should fix the warning in the 'proper' way, I hope. Without > this patch the warning constantly pops up on Fedora 21. > Works for me, I haven't had warning there. -- Martin Basti From ftweedal at redhat.com Wed Nov 26 06:40:39 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 26 Nov 2014 16:40:39 +1000 Subject: [Freeipa-devel] Meaning of "Needs UI design" field in Trac? In-Reply-To: <20141125001359.GT8412@dhcp-40-8.bne.redhat.com> References: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> <5472EB16.4060200@redhat.com> <20141125001359.GT8412@dhcp-40-8.bne.redhat.com> Message-ID: <20141126064039.GI8412@dhcp-40-8.bne.redhat.com> On Tue, Nov 25, 2014 at 10:13:59AM +1000, Fraser Tweedale wrote: > On Mon, Nov 24, 2014 at 09:23:50AM +0100, Martin Kosek wrote: > > On 11/24/2014 08:39 AM, Fraser Tweedale wrote: > > > Hi all, > > > > > > The precise meaning and usage of the "Needs UI design" field in Trac > > > is not clear to me. It has five values: > > > > > > - > > > - Not needed > > > - Review > > > - Consult > > > - Design > > > > > > What is the purpose of this field and the meanings of the different > > > values? And a more general question: is there a resource anywhere > > > that explains the various fields in the FreeIPA Trac? > > > > Hi Fraser, > > > > The addition Trac ticket metadata are usually added quite organically, as they > > are needed. I am not aware of a page that would describe them. If the field is > > not clear just from the description, it means it is possibly badly designed :-) > > > > Needs UI design in particular was used to select tickets that needs, well, UI > > review from UX specialist. > > > > But given it is not used on a frequent basis > > (https://fedorahosted.org/freeipa/query?uxd=!&uxd=!Not+needed&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component) > > I would personally just remove it and use keyword for this one time usage (like > > "ux-required") to make tickets smaller. > > > > HTH, > > Martin > > Thanks Martin, that does help. > > I'll not remove the field just now but I will make a page on the > wiki about this. There we can codify semantics of fields and common > tags, and indicate fields that are candidates for removal. I made a page on the Trac wiki for documenting these things: https://fedorahosted.org/freeipa/wiki/TicketFields. It is also linked on the front page of the Trac. From mkosek at redhat.com Wed Nov 26 07:54:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Nov 2014 08:54:56 +0100 Subject: [Freeipa-devel] Meaning of "Needs UI design" field in Trac? In-Reply-To: <20141126064039.GI8412@dhcp-40-8.bne.redhat.com> References: <20141124073936.GR8412@dhcp-40-8.bne.redhat.com> <5472EB16.4060200@redhat.com> <20141125001359.GT8412@dhcp-40-8.bne.redhat.com> <20141126064039.GI8412@dhcp-40-8.bne.redhat.com> Message-ID: <54758750.6090303@redhat.com> On 11/26/2014 07:40 AM, Fraser Tweedale wrote: > On Tue, Nov 25, 2014 at 10:13:59AM +1000, Fraser Tweedale wrote: >> On Mon, Nov 24, 2014 at 09:23:50AM +0100, Martin Kosek wrote: >>> On 11/24/2014 08:39 AM, Fraser Tweedale wrote: >>>> Hi all, >>>> >>>> The precise meaning and usage of the "Needs UI design" field in Trac >>>> is not clear to me. It has five values: >>>> >>>> - >>>> - Not needed >>>> - Review >>>> - Consult >>>> - Design >>>> >>>> What is the purpose of this field and the meanings of the different >>>> values? And a more general question: is there a resource anywhere >>>> that explains the various fields in the FreeIPA Trac? >>> >>> Hi Fraser, >>> >>> The addition Trac ticket metadata are usually added quite organically, as they >>> are needed. I am not aware of a page that would describe them. If the field is >>> not clear just from the description, it means it is possibly badly designed :-) >>> >>> Needs UI design in particular was used to select tickets that needs, well, UI >>> review from UX specialist. >>> >>> But given it is not used on a frequent basis >>> (https://fedorahosted.org/freeipa/query?uxd=!&uxd=!Not+needed&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component) >>> I would personally just remove it and use keyword for this one time usage (like >>> "ux-required") to make tickets smaller. >>> >>> HTH, >>> Martin >> >> Thanks Martin, that does help. >> >> I'll not remove the field just now but I will make a page on the >> wiki about this. There we can codify semantics of fields and common >> tags, and indicate fields that are candidates for removal. > > I made a page on the Trac wiki for documenting these things: > https://fedorahosted.org/freeipa/wiki/TicketFields. It is also > linked on the front page of the Trac. > Thanks Fraser, I documented the rest of the custom/unusual ticket fields we use (except Temp mark which should be removed soon) and also linked the page from the FreeIPA Trac front page. HTH. Martin From mkosek at redhat.com Wed Nov 26 10:52:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Nov 2014 11:52:05 +0100 Subject: [Freeipa-devel] ds-migrate feature enhancements In-Reply-To: References: Message-ID: <5475B0D5.10308@redhat.com> On 11/24/2014 11:24 PM, Alan Evans wrote: > I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. > ds-migrate wasn't going to fill all of my needs so I thought I would use it > for most and then make up some LDIF's and massage them to do the last bit > of migration. > > I have instead decided to extend ds-migrate and I think that my features > might be of use to others so I would like to contribute them. Great idea! :-) IMO, enhancing FreeIPA migration capability and making it more even more pleasant experience for user users is a good goal. > Before I get > too for I wanted to get some input from the community. > > Here are MY original goals: > * Migrate ssh public keys > The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey > attribute: sshPublicKey > * Migrate disabled accounts as disabled > We 'disable' usere by setting their shadowExpire to a date in the past > and setting their shell to /bin/false > > I realized that the ssh-public key problem is more generally an attribute > mapping problem and dealing with disabled users could be more generalized > too. > > Here are instead the new features I would provide. > > * Attribute mapping > Feature should check the new syntax exists and is the same as the old > syntax (perhaps further check for compatible syntax) > --user-attribute-map=oldAttribute=newAttribute > --group-attribute-map=foo=bar > Should I drop user/group and just make it --attribute-map and apply it to > both? > Should certain attributes be mapped by default, i.e. > sshPublicKey=ipaSSHPubKey (this means we also need to ignore the > objectClass ldapPublicKey by default) Maybe make a separate switch > --with-ssh-keys that automatically adds a map and an ignore? If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by default and maybe add a switch to skip these advanced migrations. Just make sure the expected format matches (ipa requires all 3 pieces of the public key, not just the blob) I think it would be very useful to combine user attribute mapping with the ideas from https://fedorahosted.org/freeipa/ticket/3709 i.e. filling attribute with values from original entry or a default. This may lead to following syntax: --user-attribute-default "sn=notdefined" --user-attribute-default "description=User with cn $cn" which would only use the pattern if attribute is not defined in original entry and --user-attribute-map "sn=$cn" which would fill overwrite the attribute even if it was defined in the original entry. > > * Handling disabled users > 1. How to identify disabled users? > a. shadowExpire < now() > --use-disable-shadow-expire How would you like to disable users then? With nsAccountLock attribute? Wouldn't it be better to instead map shadowExpire to krbPrincipalExpiration attribute which should have sematically the same meaning? > b. loginShell is one of configurable shells > --use-disable-login-shell > --disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these Is this really a general mechanism? I think Kerberos principal expiration is the way to go: # ipa user-mod fbar --principal-expiration 20140101000000Z # ssh fbar@`hostname` fbar at vm-067.idm.lab.bos.redhat.com's password: Permission denied, please try again. # tail /var/log/krb5kdc.log ... Nov 26 04:56:51 vm-067.idm.lab.bos.redhat.com krb5kdc[19615](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.16.78.67: CLIENT EXPIRED: fbar at IDM.LAB.BOS.REDHAT.COM for krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Client's entry in database has expired It is respected by Kerberos authentication and SSSD logins, at minimum. > two would be the defaults) > c. nsAccountLocked (though that would be straight copied by the > migrator anyway +1 for copying. > d. From Open DJ the attribute ds-pwp-account-disabled can be used to > identify disabled users > (are there others?) > 2. What do do with disabled users (in my case migrate and disable) > a. Migrate them and don't touch nsAccountLocked > b. Migrate them and set nsAccountLocked = true > --disable-users > c. Do not migrate them > --skip-disabled-users > d. Which is the default? Migrate and disable? If so which are the > default methods for identifying them? All methods? I may be missing something, but to me following would make sense: - properly migrate and fill krbPrincipalExpiration and nsACcountLock attributes - optionally implement --skip-disabled-users. Though it may be challenging to implement the "is_user_disabled" function right so that it works on all sort of DS schemes. > So is there anything I'm missing? Any suggestions on the switches? I'm not > entirely sure I like them the way they are. > > I have code to cover about 60% of the above already. The user-attr-map > feature is working and the --disabled-users and disabled-shells options are > working. > > Regards, > -Alan HTH, Martin From mbasti at redhat.com Wed Nov 26 11:23:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Nov 2014 12:23:19 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <547495B0.7000102@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> <547490D7.2000606@redhat.com> <547495B0.7000102@redhat.com> Message-ID: <5475B827.3000507@redhat.com> On 25/11/14 15:44, David Kupka wrote: > On 11/25/2014 03:23 PM, Martin Basti wrote: >> On 25/11/14 13:16, David Kupka wrote: >>> On 11/25/2014 09:57 AM, David Kupka wrote: >>>> On 11/25/2014 09:51 AM, David Kupka wrote: >>>>> On 11/24/2014 03:59 PM, Martin Basti wrote: >>>>>> On 24/11/14 15:54, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4695 >>>>>>> >>>>>>> IMO this is one of two reasonable ways how to fix this ticket. >>>>>>> The other one is to change just the manual page but it seems more >>>>>>> consistent to use singular for metavars everywhere. >>>>>>> >>>>>>> >>>>>> I like this approach. But IMO we should instead of "You ..." form in >>>>>> help, this message, as we use with forwarders >>>>>> >>>>>> "This option can be used multiple times" >>>>>> >>>>>> Martin^2 >>>>>> >>>>> Our manual pages are not exactly unified in that but let's stay with >>>>> the >>>>> majority. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Wrong patch, sorry. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Extending help messages too. >>> >> NACK, you edited wrong option >> >> --no-reverse Do not create reverse DNS zone. This option can be >> used multiple times >> >> > Bad line, thanks for noticing, fixed patches attached. > ./make-lint ************* Module ipaserver.install.ipa_replica_prepare ipaserver/install/ipa_replica_prepare.py:59: [E0001(syntax-error), ] invalid syntax) ************* Module ipa-replica-prepare install/tools/ipa-replica-prepare:21: [E0611(no-name-in-module), ] No name 'ipa_replica_prepare' in module 'ipaserver.install') -- Martin Basti From thozza at redhat.com Wed Nov 26 11:33:16 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 12:33:16 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <54636F1F.6090701@redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> <54636F1F.6090701@redhat.com> Message-ID: <5475BA7C.5040808@redhat.com> On 11/12/2014 03:30 PM, Petr Spacek wrote: > On 24.7.2014 11:00, Petr Spacek wrote: > > On 27.2.2014 15:19, Lukas Slebodnik wrote: > >> ehlo, > >> > >> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying > >> to export special CFLAGS for bind9 header files. It can be automatically > >> detected in configure script using utility isc-config. > >> > >> Attached patch should improve this and CFLAGS needn't be exported. > > > > Kind NACK. It would be valuable to test if isc/errno2result.h header is > > present and throw appropriate error. > > > > Current check with isc-config.sh only will pass if you have bind-devel package > > installed but you are missing bind-lite-devel package. > > > > > > I have a question: How > > +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 > > works? > > > > Will it take user-defined CFLAGS into account? I would like to place > > user-defined flags at the end of the list so you can easily override settings > > given by autotools. > > > > Thank you for clarification :-) > > > > > > I will be really happy to commit complete fix. Thank you for cleaning this > > autotools mess! > > This version actually works. Previous version did not take CFLAGS from > isc-config.sh into account during libdns version check so it actually did not > work at all :-) > > Please review it (and send me a modified patch if you see a problem). > > Thank you for your time! > ACK. No need to export CPPFLAGS any more! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From dkupka at redhat.com Wed Nov 26 11:37:18 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 26 Nov 2014 12:37:18 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <5475B827.3000507@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> <547490D7.2000606@redhat.com> <547495B0.7000102@redhat.com> <5475B827.3000507@redhat.com> Message-ID: <5475BB6E.70207@redhat.com> On 11/26/2014 12:23 PM, Martin Basti wrote: > On 25/11/14 15:44, David Kupka wrote: >> On 11/25/2014 03:23 PM, Martin Basti wrote: >>> On 25/11/14 13:16, David Kupka wrote: >>>> On 11/25/2014 09:57 AM, David Kupka wrote: >>>>> On 11/25/2014 09:51 AM, David Kupka wrote: >>>>>> On 11/24/2014 03:59 PM, Martin Basti wrote: >>>>>>> On 24/11/14 15:54, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4695 >>>>>>>> >>>>>>>> IMO this is one of two reasonable ways how to fix this ticket. >>>>>>>> The other one is to change just the manual page but it seems more >>>>>>>> consistent to use singular for metavars everywhere. >>>>>>>> >>>>>>>> >>>>>>> I like this approach. But IMO we should instead of "You ..." form in >>>>>>> help, this message, as we use with forwarders >>>>>>> >>>>>>> "This option can be used multiple times" >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> Our manual pages are not exactly unified in that but let's stay with >>>>>> the >>>>>> majority. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> Wrong patch, sorry. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Extending help messages too. >>>> >>> NACK, you edited wrong option >>> >>> --no-reverse Do not create reverse DNS zone. This option can be >>> used multiple times >>> >>> >> Bad line, thanks for noticing, fixed patches attached. >> > ./make-lint > ************* Module ipaserver.install.ipa_replica_prepare > ipaserver/install/ipa_replica_prepare.py:59: [E0001(syntax-error), ] > invalid syntax) > ************* Module ipa-replica-prepare > install/tools/ipa-replica-prepare:21: [E0611(no-name-in-module), ] No > name 'ipa_replica_prepare' in module 'ipaserver.install') > > Fixed. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-5-master-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0033-5-Use-singular-in-help-metavars-update-man-pages.patch Type: text/x-patch Size: 12545 bytes Desc: not available URL: From thozza at redhat.com Wed Nov 26 12:04:18 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 13:04:18 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <5474D00C.3020001@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> <5474D00C.3020001@redhat.com> Message-ID: <5475C1C2.6050406@redhat.com> On 11/25/2014 07:53 PM, Martin Basti wrote: > On 12/11/14 16:34, Petr Spacek wrote: > > On 25.2.2014 15:05, Lukas Slebodnik wrote: > >> On (25/02/14 09:54), Petr Spacek wrote: > >>> On 24.2.2014 18:56, Lukas Slebodnik wrote: > >>>> On (24/02/14 16:48), Petr Spacek wrote: > >>>>> Hello, > >>>>> > >>>>> Drop unnecessary #define _BSD_SOURCE. > >>>>> > >>>>> -- > >>>>> Petr^2 Spacek > >>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 > >>>>> From: Petr Spacek > >>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 > >>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. > >>>>> > >>>>> Signed-off-by: Petr Spacek > >>>>> --- > >>>>> src/krb5_helper.c | 2 -- > >>>>> 1 file changed, 2 deletions(-) > >>>>> > >>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c > >>>>> index > >>>>> d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 > >>>>> 100644 > >>>>> --- a/src/krb5_helper.c > >>>>> +++ b/src/krb5_helper.c > >>>>> @@ -15,8 +15,6 @@ > >>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > >>>>> */ > >>>>> > >>>>> -#define _BSD_SOURCE > >>>>> - > >>>>> #include > >>>>> #include > >>>>> #include > >>>>> -- > >>>>> 1.8.5.3 > >>>>> > >>>> Simo is an author (according to git blame) > >>>> He defined this macro due to function setenv > >>>> > >>> >from man setenv: > >>>> NAME > >>>> setenv - change or add an environment variable > >>>> > >>>> SYNOPSIS > >>>> #include > >>>> > >>>> int setenv(const char *name, const char *value, int overwrite); > >>>> > >>>> int unsetenv(const char *name); > >>>> > >>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > >>>> > >>>> setenv(), unsetenv(): > >>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 > >>>> ---------------------------------------------------------------------------- > >>>> > >>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included > >>>> header file . I tested only on fedora 20. It can be used > >>>> on the other distributions. > >>>> > >>>> I would rather let this macro as is. > >>> Wow, I didn't expect that somebody will spend time on this :-) > >>> > >>> See build logs from Fedora 21 > >>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log > >> You should have noticed this in the 1st mail. Because it is difference between > >> removing unnecessary macro and depprecated usage of macro. > >> > >> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE > >> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] > >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" > >> > >>> Patches with 'the right' solution are welcome. I'm not going to spend > >>> more time on this. > > Attached patch should fix the warning in the 'proper' way, I hope. Without > > this patch the warning constantly pops up on Fedora 21. > > > Works for me, I haven't had warning there. > ACK. Works for me, too. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From mbasti at redhat.com Wed Nov 26 12:04:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Nov 2014 13:04:51 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <5475BB6E.70207@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> <547490D7.2000606@redhat.com> <547495B0.7000102@redhat.com> <5475B827.3000507@redhat.com> <5475BB6E.70207@redhat.com> Message-ID: <5475C1E3.9090505@redhat.com> On 26/11/14 12:37, David Kupka wrote: > On 11/26/2014 12:23 PM, Martin Basti wrote: >> On 25/11/14 15:44, David Kupka wrote: >>> On 11/25/2014 03:23 PM, Martin Basti wrote: >>>> On 25/11/14 13:16, David Kupka wrote: >>>>> On 11/25/2014 09:57 AM, David Kupka wrote: >>>>>> On 11/25/2014 09:51 AM, David Kupka wrote: >>>>>>> On 11/24/2014 03:59 PM, Martin Basti wrote: >>>>>>>> On 24/11/14 15:54, David Kupka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4695 >>>>>>>>> >>>>>>>>> IMO this is one of two reasonable ways how to fix this ticket. >>>>>>>>> The other one is to change just the manual page but it seems more >>>>>>>>> consistent to use singular for metavars everywhere. >>>>>>>>> >>>>>>>>> >>>>>>>> I like this approach. But IMO we should instead of "You ..." >>>>>>>> form in >>>>>>>> help, this message, as we use with forwarders >>>>>>>> >>>>>>>> "This option can be used multiple times" >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>> Our manual pages are not exactly unified in that but let's stay >>>>>>> with >>>>>>> the >>>>>>> majority. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> Wrong patch, sorry. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> Extending help messages too. >>>>> >>>> NACK, you edited wrong option >>>> >>>> --no-reverse Do not create reverse DNS zone. This option >>>> can be >>>> used multiple times >>>> >>>> >>> Bad line, thanks for noticing, fixed patches attached. >>> >> ./make-lint >> ************* Module ipaserver.install.ipa_replica_prepare >> ipaserver/install/ipa_replica_prepare.py:59: [E0001(syntax-error), ] >> invalid syntax) >> ************* Module ipa-replica-prepare >> install/tools/ipa-replica-prepare:21: [E0611(no-name-in-module), ] No >> name 'ipa_replica_prepare' in module 'ipaserver.install') >> >> > Fixed. > Thanks! ACK -- Martin Basti From thozza at redhat.com Wed Nov 26 12:07:39 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 13:07:39 +0100 Subject: [Freeipa-devel] [PATCH 0306] Improve info messages about number of defined/loaded zones In-Reply-To: <545CBC32.7030205@redhat.com> References: <545CBC32.7030205@redhat.com> Message-ID: <5475C28B.9020808@redhat.com> On 11/07/2014 01:33 PM, Petr Spacek wrote: > Hello, > > Improve info messages about number of defined/loaded zones. > ACK. The new message looks good. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pviktori at redhat.com Wed Nov 26 12:10:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Nov 2014 13:10:20 +0100 Subject: [Freeipa-devel] [PATCH 0287] Re-initialize NSS database after otptoken plugin tests In-Reply-To: <546F1844.9000503@redhat.com> References: <546F1844.9000503@redhat.com> Message-ID: <5475C32C.9030509@redhat.com> On 11/21/2014 11:47 AM, Tomas Babej wrote: > Hi, > > OTP token tests do not properly reinitialize the NSS db, thus > making subsequent xmlrpc tests fail on SSL cert validation. > > Make sure NSS db is re-initalized in the teardown method. > > https://fedorahosted.org/freeipa/ticket/4748 > > Note for reviewers: Requires Petr^3's pytest patchset, which I am > pushing right now. > Thank you! ACK, pushed to master: 792ff0c0c40ddd1583c6789c8f34382c050d3e92 -- Petr? From pviktori at redhat.com Wed Nov 26 12:14:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Nov 2014 13:14:53 +0100 Subject: [Freeipa-devel] [PATCH] 0676 Ignore ipap11helper/setup.py in doctests Message-ID: <5475C43D.30403@redhat.com> A fix in test configuration. Pushed as one-liner to master: 4e99663379b333e2dd851f06a786c705c3e07e4b I've opened https://fedorahosted.org/freeipa/ticket/4769 to fix this a better way; either in upstream pytest (if they deem projects with multiple setup.py files as important enough), or in our own plugin. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0676-Ignore-ipap11helper-setup.py-in-doctests.patch Type: text/x-patch Size: 1047 bytes Desc: not available URL: From thozza at redhat.com Wed Nov 26 12:33:33 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 13:33:33 +0100 Subject: [Freeipa-devel] [PATCH 0309] Fix crash caused by interaction between forward and master zones In-Reply-To: <5474C575.5020009@redhat.com> References: <5474B83D.4020201@redhat.com> <5474C575.5020009@redhat.com> Message-ID: <5475C89D.2000808@redhat.com> On 11/25/2014 07:07 PM, Martin Basti wrote: > On 25/11/14 18:11, Petr Spacek wrote: > > Hello, > > > > Fix crash caused by interaction between forward and master zones. > > > > LDAP modifications made to idnsName=sub, idnsName=example.com, cn=dns object > > were incorrectly processed using update_zone() in cases where forward zone > > sub.example.com. existed in LDAP as object idnsName=sub.example.com, cn=dns. > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/145 > > > > > > Tomas and Martin^2, please review it ASAP. Thank you! > > > Works for me, IPA tests passed, can you Tomas check the code before push? > ACK. The patch looks good. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Wed Nov 26 12:39:21 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 13:39:21 +0100 Subject: [Freeipa-devel] [PATCH 0308] Improve detection of BIND 9 isc__errno2result header file In-Reply-To: <5474CF1B.7080501@redhat.com> References: <5463788B.3060107@redhat.com> <5474CF1B.7080501@redhat.com> Message-ID: <5475C9F9.5080900@redhat.com> On 11/25/2014 07:48 PM, Martin Basti wrote: > On 12/11/14 16:11, Petr Spacek wrote: > > Hello, > > > > Improve detection of BIND 9 isc__errno2result header file. > > > > This header file is not in standard distribution so normal isc-config.sh > > detection is not enough. > > > > With this patch, ./configure should work even without explicit CFLAGS and it > > should also detect that bind-devel or bind-lite-devel packages are missing. > > > > > Works for me > ACK. Works for me, too. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From mbasti at redhat.com Wed Nov 26 12:46:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Nov 2014 13:46:43 +0100 Subject: [Freeipa-devel] [PATCH 0307] Send DNS NOTIFY message after any modification to the zone In-Reply-To: <545CD869.5010402@redhat.com> References: <545CD869.5010402@redhat.com> Message-ID: <5475CBB3.7030505@redhat.com> On 07/11/14 15:34, Petr Spacek wrote: > Hello, > > Send DNS NOTIFY message after any modification to the zone. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/144 > Works for me. But don't push it before Tomas check the code please. Martin^2 -- Martin Basti From thozza at redhat.com Wed Nov 26 13:13:29 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 26 Nov 2014 14:13:29 +0100 Subject: [Freeipa-devel] [PATCH 0310] Fix misleading error message about forward zones on reconnect In-Reply-To: <5474C98B.4070405@redhat.com> References: <5474BC0E.5030003@redhat.com> <5474C98B.4070405@redhat.com> Message-ID: <5475D1F9.6090902@redhat.com> On 11/25/2014 07:25 PM, Martin Basti wrote: > On 25/11/14 18:27, Petr Spacek wrote: > > Hello, > > > > Fix misleading error message about forward zones on reconnect. > > > > Previously the plugin could log 'already exist' error after > > successful reconnection to LDAP for each active forward zone. > > > > Now it prints message: > > forward zone 'fw.example.com': loaded > > > > > Log looks better now, ACK if Tomas has no objections. > ACK. Looks good. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pvoborni at redhat.com Wed Nov 26 13:15:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Nov 2014 14:15:44 +0100 Subject: [Freeipa-devel] Release notes of FreeIPA 4.1.2 Message-ID: <5475D280.7010408@redhat.com> Hi all, FreeIPA 4.1.2 release was created yesterday. The only missing step is sending an announce mail. Here's release notes draft: - http://www.freeipa.org/page/Releases/4.1.2 Feel free to amend. I'll wait 2 hours and then send it. -- Petr Vobornik From mbasti at redhat.com Wed Nov 26 13:17:51 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Nov 2014 14:17:51 +0100 Subject: [Freeipa-devel] [PATCH 0037] ipa-managed-entries prompts for password with -p option and incorrect passowrd In-Reply-To: References: Message-ID: <5475D2FF.7010604@redhat.com> On 24/11/14 04:43, Gabe Alford wrote: > Hello, > > I have a fix for https://fedorahosted.org/freeipa/ticket/4089 > > thanks, > > Gabe Thank you! ACK -- Martin Basti From pvoborni at redhat.com Wed Nov 26 13:34:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Nov 2014 14:34:10 +0100 Subject: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages. In-Reply-To: <5475C1E3.9090505@redhat.com> References: <5473468F.4070506@redhat.com> <547347B8.9080907@redhat.com> <54744300.4050106@redhat.com> <54744479.6000904@redhat.com> <54747315.7050103@redhat.com> <547490D7.2000606@redhat.com> <547495B0.7000102@redhat.com> <5475B827.3000507@redhat.com> <5475BB6E.70207@redhat.com> <5475C1E3.9090505@redhat.com> Message-ID: <5475D6D2.1090307@redhat.com> On 11/26/2014 01:04 PM, Martin Basti wrote: > On 26/11/14 12:37, David Kupka wrote: >>> >> Fixed. >> > Thanks! > > ACK > Pushed to ipa-4-1: 2f8c4e7b165609706a4af9f680579c0e47edaeca Pushed to master: 3a6d714bb229f8dd68ae219d94283f05cf57a6d7 -- Petr Vobornik From pvoborni at redhat.com Wed Nov 26 13:42:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Nov 2014 14:42:14 +0100 Subject: [Freeipa-devel] [PATCH 0037] ipa-managed-entries prompts for password with -p option and incorrect passowrd In-Reply-To: <5475D2FF.7010604@redhat.com> References: <5475D2FF.7010604@redhat.com> Message-ID: <5475D8B6.5030109@redhat.com> On 11/26/2014 02:17 PM, Martin Basti wrote: > On 24/11/14 04:43, Gabe Alford wrote: >> Hello, >> >> I have a fix for https://fedorahosted.org/freeipa/ticket/4089 >> >> thanks, >> >> Gabe > > Thank you! > > ACK > Pushed to master: 45dbd12d8886ca2025bcab5b10ec5e004af3d9ab -- Petr Vobornik From lslebodn at redhat.com Wed Nov 26 14:57:16 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 26 Nov 2014 15:57:16 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <54636F1F.6090701@redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> <54636F1F.6090701@redhat.com> Message-ID: <20141126145715.GB22838@mail.corp.redhat.com> On (12/11/14 15:30), Petr Spacek wrote: >On 24.7.2014 11:00, Petr Spacek wrote: >> On 27.2.2014 15:19, Lukas Slebodnik wrote: >>> ehlo, >>> >>> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying >>> to export special CFLAGS for bind9 header files. It can be automatically >>> detected in configure script using utility isc-config. >>> >>> Attached patch should improve this and CFLAGS needn't be exported. >> >> Kind NACK. It would be valuable to test if isc/errno2result.h header is >> present and throw appropriate error. >> >> Current check with isc-config.sh only will pass if you have bind-devel package >> installed but you are missing bind-lite-devel package. >> >> >> I have a question: How >> +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 >> works? >> >> Will it take user-defined CFLAGS into account? I would like to place >> user-defined flags at the end of the list so you can easily override settings >> given by autotools. >> >> Thank you for clarification :-) >> >> >> I will be really happy to commit complete fix. Thank you for cleaning this >> autotools mess! > >This version actually works. Previous version did not take CFLAGS from >isc-config.sh into account during libdns version check so it actually did not >work at all :-) > >Please review it (and send me a modified patch if you see a problem). > >Thank you for your time! > >-- >Petr^2 Spacek >From 4b17099abe2169ddb86b24e53cd2769b76f3ea2d Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Tue, 25 Feb 2014 10:46:50 +0100 >Subject: [PATCH] Improve detection of BIND 9 header files and necessary > CFLAGS. > >BIND 9 header files can be stored in non-default path (/usr/include/bind9). >The isc-config.sh utility can provide necessary CFLAGS. >--- > configure.ac | 43 ++++++++++++++++++++++++++++++++++--------- > contrib/bind-dyndb-ldap.spec | 1 - > 2 files changed, 34 insertions(+), 10 deletions(-) > >diff --git a/configure.ac b/configure.ac >index d471038ada54c07dcfc211c8a2572850e3b28205..c985908c760c974f7c02b6fa3d183e839bbeb9ad 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -15,14 +15,6 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) > AC_PROG_CC > AC_PROG_LIBTOOL > >-# Checks for libraries. >-AC_CHECK_LIB([dns], [dns_name_init], [], >- AC_MSG_ERROR([Install BIND9 development files])) >-AC_CHECK_LIB([ldap], [ldap_initialize], [], >- AC_MSG_ERROR([Install OpenLDAP development files])) >-AC_CHECK_LIB([krb5], [krb5_cc_initialize], [], >- AC_MSG_ERROR([Install Kerberos 5 development files])) >- > # Checks for header files. > AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) > >@@ -47,6 +39,39 @@ AC_TRY_COMPILE([ > [CFLAGS="$SAVED_CFLAGS" > AC_MSG_RESULT([no])]) > >+# Get CFLAGS from isc-config.sh >+AC_ARG_VAR([BIND9_CFLAGS], >+ [C compiler flags for bind9, overriding isc-config.sh]) >+AC_SUBST(BIND9_CFLAGS) >+ >+dnl do not override enviroment variables BIND9_CFLAGS >+if test -z "$BIND9_CFLAGS"; then ^^^^^^^^^^^^^^^^^^^^^^^^^ What is a purpose of this condition. IIRC "AC_SUBST(BIND9_CFLAGS)" should allow you to override BIND9_CFLAGS from command line. If it does not wok I need to fix it. LS From pviktori at redhat.com Wed Nov 26 15:18:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Nov 2014 16:18:09 +0100 Subject: [Freeipa-devel] [PATCH] 0677 test_integration: Use python-pytest-multihost Message-ID: <5475EF31.3060606@redhat.com> Hello, I have split FreeIPA's multi-host testing infrastructure into a separate project. It is temoprarily available at: https://github.com/encukou/pytest-multihost and I will move it to fedorahosted as soon as it's approved: https://fedorahosted.org/fedora-infrastructure/ticket/4605 RPMs for Fedora 20..rawhide and EPEL 7 are available in COPR: https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/ This patch contains the necessary changes to FreeIPA. The tests themselves are almost unchanged. FreeIPA specific parts (most importantly, logging and environ-based configuration) are also left in. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0677-test_integration-Use-python-pytest-multihost.patch Type: text/x-patch Size: 74564 bytes Desc: not available URL: From lslebodn at redhat.com Wed Nov 26 15:47:13 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 26 Nov 2014 16:47:13 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <54637E1E.8090009@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> Message-ID: <20141126154713.GC22838@mail.corp.redhat.com> On (12/11/14 16:34), Petr Spacek wrote: >On 25.2.2014 15:05, Lukas Slebodnik wrote: >> On (25/02/14 09:54), Petr Spacek wrote: >>> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>>> On (24/02/14 16:48), Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Drop unnecessary #define _BSD_SOURCE. >>>>> >>>>> -- >>>>> Petr^2 Spacek >>>> >>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>>> From: Petr Spacek >>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>>> >>>>> Signed-off-by: Petr Spacek >>>>> --- >>>>> src/krb5_helper.c | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>>> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>>> --- a/src/krb5_helper.c >>>>> +++ b/src/krb5_helper.c >>>>> @@ -15,8 +15,6 @@ >>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>>> */ >>>>> >>>>> -#define _BSD_SOURCE >>>>> - >>>>> #include >>>>> #include >>>>> #include >>>>> -- >>>>> 1.8.5.3 >>>>> >>>> >>>> Simo is an author (according to git blame) >>>> He defined this macro due to function setenv >>>> >>> >from man setenv: >>>> NAME >>>> setenv - change or add an environment variable >>>> >>>> SYNOPSIS >>>> #include >>>> >>>> int setenv(const char *name, const char *value, int overwrite); >>>> >>>> int unsetenv(const char *name); >>>> >>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>>> >>>> setenv(), unsetenv(): >>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>>> ---------------------------------------------------------------------------- >>>> >>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>>> header file . I tested only on fedora 20. It can be used >>>> on the other distributions. >>>> >>>> I would rather let this macro as is. >>> >>> Wow, I didn't expect that somebody will spend time on this :-) >>> >>> See build logs from Fedora 21 >>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log >> >> You should have noticed this in the 1st mail. Because it is difference between >> removing unnecessary macro and depprecated usage of macro. >> >> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE >> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >> >>> Patches with 'the right' solution are welcome. I'm not going to spend >>> more time on this. > >Attached patch should fix the warning in the 'proper' way, I hope. Without >this patch the warning constantly pops up on Fedora 21. > >-- >Petr^2 Spacek >From 873334fb1ede302b3a6cbf52ac8bc7e98a4659f9 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Wed, 12 Nov 2014 16:30:56 +0100 >Subject: [PATCH] Replace deprecated macro #define _BSD_SOURCE with > _POSIX_C_SOURCE. > >See >https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes >--- > src/krb5_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/src/krb5_helper.c b/src/krb5_helper.c >index 169d384cddb5ab9fc9cce1f5ec773836a4c383bb..85c8df9f15af839786ded50d41313763f6463579 100644 >--- a/src/krb5_helper.c >+++ b/src/krb5_helper.c >@@ -15,7 +15,7 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > >-#define _BSD_SOURCE >+#define _POSIX_C_SOURCE 200112L /* setenv */ I'm not sure wheather it is good idea to define special value. It should be autodetected. One way could be to test available extensions in configure time AC_USE_SYSTEM_EXTENSIONS. or use _BSD_SOURCE conditioanally. diff --git a/configure.ac b/configure.ac index 9e33116..95a1440 100644 --- a/configure.ac +++ b/configure.ac @@ -30,7 +30,7 @@ AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) AC_TYPE_SIZE_T # Checks for library functions. -AC_CHECK_FUNCS([memset strcasecmp strncasecmp]) +AC_CHECK_FUNCS([memset strcasecmp strncasecmp setenv]) # Check if build chain supports symbol visibility AC_MSG_CHECKING([for -fvisibility=hidden compiler flag]) diff --git a/src/krb5_helper.c b/src/krb5_helper.c index d178720..8ce11b8 100644 --- a/src/krb5_helper.c +++ b/src/krb5_helper.c @@ -15,7 +15,10 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include "config.h" +#ifndef HAVE_SETENV #define _BSD_SOURCE +#endif /* HAVE_SETENV */ #include #include LS From pspacek at redhat.com Wed Nov 26 15:51:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 16:51:22 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <20141126154713.GC22838@mail.corp.redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> <20141126154713.GC22838@mail.corp.redhat.com> Message-ID: <5475F6FA.2060000@redhat.com> On 26.11.2014 16:47, Lukas Slebodnik wrote: > On (12/11/14 16:34), Petr Spacek wrote: >> On 25.2.2014 15:05, Lukas Slebodnik wrote: >>> On (25/02/14 09:54), Petr Spacek wrote: >>>> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>>>> On (24/02/14 16:48), Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> Drop unnecessary #define _BSD_SOURCE. >>>>>> >>>>>> -- >>>>>> Petr^2 Spacek >>>>> >>>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>>>> From: Petr Spacek >>>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>>>> >>>>>> Signed-off-by: Petr Spacek >>>>>> --- >>>>>> src/krb5_helper.c | 2 -- >>>>>> 1 file changed, 2 deletions(-) >>>>>> >>>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>>>> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>>>> --- a/src/krb5_helper.c >>>>>> +++ b/src/krb5_helper.c >>>>>> @@ -15,8 +15,6 @@ >>>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>>>> */ >>>>>> >>>>>> -#define _BSD_SOURCE >>>>>> - >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> -- >>>>>> 1.8.5.3 >>>>>> >>>>> >>>>> Simo is an author (according to git blame) >>>>> He defined this macro due to function setenv >>>>> >>>> >from man setenv: >>>>> NAME >>>>> setenv - change or add an environment variable >>>>> >>>>> SYNOPSIS >>>>> #include >>>>> >>>>> int setenv(const char *name, const char *value, int overwrite); >>>>> >>>>> int unsetenv(const char *name); >>>>> >>>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>>>> >>>>> setenv(), unsetenv(): >>>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>>>> header file . I tested only on fedora 20. It can be used >>>>> on the other distributions. >>>>> >>>>> I would rather let this macro as is. >>>> >>>> Wow, I didn't expect that somebody will spend time on this :-) >>>> >>>> See build logs from Fedora 21 >>>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log >>> >>> You should have noticed this in the 1st mail. Because it is difference between >>> removing unnecessary macro and depprecated usage of macro. >>> >>> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE >>> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] >>> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >>> >>>> Patches with 'the right' solution are welcome. I'm not going to spend >>>> more time on this. >> >> Attached patch should fix the warning in the 'proper' way, I hope. Without >> this patch the warning constantly pops up on Fedora 21. >> >> -- >> Petr^2 Spacek > >>From 873334fb1ede302b3a6cbf52ac8bc7e98a4659f9 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Wed, 12 Nov 2014 16:30:56 +0100 >> Subject: [PATCH] Replace deprecated macro #define _BSD_SOURCE with >> _POSIX_C_SOURCE. >> >> See >> https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes >> --- >> src/krb5_helper.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >> index 169d384cddb5ab9fc9cce1f5ec773836a4c383bb..85c8df9f15af839786ded50d41313763f6463579 100644 >> --- a/src/krb5_helper.c >> +++ b/src/krb5_helper.c >> @@ -15,7 +15,7 @@ >> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >> */ >> >> -#define _BSD_SOURCE >> +#define _POSIX_C_SOURCE 200112L /* setenv */ > I'm not sure wheather it is good idea to define special value. > It should be autodetected. > > One way could be to test available extensions in configure time > AC_USE_SYSTEM_EXTENSIONS. > > or use _BSD_SOURCE conditioanally. > > diff --git a/configure.ac b/configure.ac > index 9e33116..95a1440 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -30,7 +30,7 @@ AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) > AC_TYPE_SIZE_T > > # Checks for library functions. > -AC_CHECK_FUNCS([memset strcasecmp strncasecmp]) > +AC_CHECK_FUNCS([memset strcasecmp strncasecmp setenv]) > > # Check if build chain supports symbol visibility > AC_MSG_CHECKING([for -fvisibility=hidden compiler flag]) > diff --git a/src/krb5_helper.c b/src/krb5_helper.c > index d178720..8ce11b8 100644 > --- a/src/krb5_helper.c > +++ b/src/krb5_helper.c > @@ -15,7 +15,10 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > > +#include "config.h" > +#ifndef HAVE_SETENV > #define _BSD_SOURCE > +#endif /* HAVE_SETENV */ > > #include > #include Hello, thank you for your patch but I'm going to stick to standard POSIX way. NACK -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 15:52:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 16:52:49 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <20141126145715.GB22838@mail.corp.redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> <54636F1F.6090701@redhat.com> <20141126145715.GB22838@mail.corp.redhat.com> Message-ID: <5475F751.5070407@redhat.com> On 26.11.2014 15:57, Lukas Slebodnik wrote: > On (12/11/14 15:30), Petr Spacek wrote: >> On 24.7.2014 11:00, Petr Spacek wrote: >>> On 27.2.2014 15:19, Lukas Slebodnik wrote: >>>> ehlo, >>>> >>>> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying >>>> to export special CFLAGS for bind9 header files. It can be automatically >>>> detected in configure script using utility isc-config. >>>> >>>> Attached patch should improve this and CFLAGS needn't be exported. >>> >>> Kind NACK. It would be valuable to test if isc/errno2result.h header is >>> present and throw appropriate error. >>> >>> Current check with isc-config.sh only will pass if you have bind-devel package >>> installed but you are missing bind-lite-devel package. >>> >>> >>> I have a question: How >>> +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 >>> works? >>> >>> Will it take user-defined CFLAGS into account? I would like to place >>> user-defined flags at the end of the list so you can easily override settings >>> given by autotools. >>> >>> Thank you for clarification :-) >>> >>> >>> I will be really happy to commit complete fix. Thank you for cleaning this >>> autotools mess! >> >> This version actually works. Previous version did not take CFLAGS from >> isc-config.sh into account during libdns version check so it actually did not >> work at all :-) >> >> Please review it (and send me a modified patch if you see a problem). >> >> Thank you for your time! >> >> -- >> Petr^2 Spacek > >>From 4b17099abe2169ddb86b24e53cd2769b76f3ea2d Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Tue, 25 Feb 2014 10:46:50 +0100 >> Subject: [PATCH] Improve detection of BIND 9 header files and necessary >> CFLAGS. >> >> BIND 9 header files can be stored in non-default path (/usr/include/bind9). >> The isc-config.sh utility can provide necessary CFLAGS. >> --- >> configure.ac | 43 ++++++++++++++++++++++++++++++++++--------- >> contrib/bind-dyndb-ldap.spec | 1 - >> 2 files changed, 34 insertions(+), 10 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index d471038ada54c07dcfc211c8a2572850e3b28205..c985908c760c974f7c02b6fa3d183e839bbeb9ad 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -15,14 +15,6 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >> AC_PROG_CC >> AC_PROG_LIBTOOL >> >> -# Checks for libraries. >> -AC_CHECK_LIB([dns], [dns_name_init], [], >> - AC_MSG_ERROR([Install BIND9 development files])) >> -AC_CHECK_LIB([ldap], [ldap_initialize], [], >> - AC_MSG_ERROR([Install OpenLDAP development files])) >> -AC_CHECK_LIB([krb5], [krb5_cc_initialize], [], >> - AC_MSG_ERROR([Install Kerberos 5 development files])) >> - >> # Checks for header files. >> AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) >> >> @@ -47,6 +39,39 @@ AC_TRY_COMPILE([ >> [CFLAGS="$SAVED_CFLAGS" >> AC_MSG_RESULT([no])]) >> >> +# Get CFLAGS from isc-config.sh >> +AC_ARG_VAR([BIND9_CFLAGS], >> + [C compiler flags for bind9, overriding isc-config.sh]) >> +AC_SUBST(BIND9_CFLAGS) >> + >> +dnl do not override enviroment variables BIND9_CFLAGS >> +if test -z "$BIND9_CFLAGS"; then > ^^^^^^^^^^^^^^^^^^^^^^^^^ > What is a purpose of this condition. > IIRC "AC_SUBST(BIND9_CFLAGS)" should allow you to override BIND9_CFLAGS > from command line. Don's ask me, it was in your original version of the patch :-) -- Petr^2 Spacek From lslebodn at redhat.com Wed Nov 26 16:12:01 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 26 Nov 2014 17:12:01 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <5475F6FA.2060000@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> <20141126154713.GC22838@mail.corp.redhat.com> <5475F6FA.2060000@redhat.com> Message-ID: <20141126161201.GD22838@mail.corp.redhat.com> On (26/11/14 16:51), Petr Spacek wrote: >On 26.11.2014 16:47, Lukas Slebodnik wrote: >> On (12/11/14 16:34), Petr Spacek wrote: >>> On 25.2.2014 15:05, Lukas Slebodnik wrote: >>>> On (25/02/14 09:54), Petr Spacek wrote: >>>>> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>>>>> On (24/02/14 16:48), Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Drop unnecessary #define _BSD_SOURCE. >>>>>>> >>>>>>> -- >>>>>>> Petr^2 Spacek >>>>>> >>>>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>>>>> From: Petr Spacek >>>>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>>>>> >>>>>>> Signed-off-by: Petr Spacek >>>>>>> --- >>>>>>> src/krb5_helper.c | 2 -- >>>>>>> 1 file changed, 2 deletions(-) >>>>>>> >>>>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>>>>> index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 >>>>>>> --- a/src/krb5_helper.c >>>>>>> +++ b/src/krb5_helper.c >>>>>>> @@ -15,8 +15,6 @@ >>>>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>>>>> */ >>>>>>> >>>>>>> -#define _BSD_SOURCE >>>>>>> - >>>>>>> #include >>>>>>> #include >>>>>>> #include >>>>>>> -- >>>>>>> 1.8.5.3 >>>>>>> >>>>>> >>>>>> Simo is an author (according to git blame) >>>>>> He defined this macro due to function setenv >>>>>> >>>>> >from man setenv: >>>>>> NAME >>>>>> setenv - change or add an environment variable >>>>>> >>>>>> SYNOPSIS >>>>>> #include >>>>>> >>>>>> int setenv(const char *name, const char *value, int overwrite); >>>>>> >>>>>> int unsetenv(const char *name); >>>>>> >>>>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>>>>> >>>>>> setenv(), unsetenv(): >>>>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>>>>> header file . I tested only on fedora 20. It can be used >>>>>> on the other distributions. >>>>>> >>>>>> I would rather let this macro as is. >>>>> >>>>> Wow, I didn't expect that somebody will spend time on this :-) >>>>> >>>>> See build logs from Fedora 21 >>>>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log >>>> >>>> You should have noticed this in the 1st mail. Because it is difference between >>>> removing unnecessary macro and depprecated usage of macro. >>>> >>>> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE >>>> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] >>>> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >>>> >>>>> Patches with 'the right' solution are welcome. I'm not going to spend >>>>> more time on this. >>> >>> Attached patch should fix the warning in the 'proper' way, I hope. Without >>> this patch the warning constantly pops up on Fedora 21. >>> >>> -- >>> Petr^2 Spacek >> >>>From 873334fb1ede302b3a6cbf52ac8bc7e98a4659f9 Mon Sep 17 00:00:00 2001 >>> From: Petr Spacek >>> Date: Wed, 12 Nov 2014 16:30:56 +0100 >>> Subject: [PATCH] Replace deprecated macro #define _BSD_SOURCE with >>> _POSIX_C_SOURCE. >>> >>> See >>> https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes >>> --- >>> src/krb5_helper.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>> index 169d384cddb5ab9fc9cce1f5ec773836a4c383bb..85c8df9f15af839786ded50d41313763f6463579 100644 >>> --- a/src/krb5_helper.c >>> +++ b/src/krb5_helper.c >>> @@ -15,7 +15,7 @@ >>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>> */ >>> >>> -#define _BSD_SOURCE >>> +#define _POSIX_C_SOURCE 200112L /* setenv */ >> I'm not sure wheather it is good idea to define special value. >> It should be autodetected. >> >> One way could be to test available extensions in configure time >> AC_USE_SYSTEM_EXTENSIONS. >> >> or use _BSD_SOURCE conditioanally. >> >> diff --git a/configure.ac b/configure.ac >> index 9e33116..95a1440 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -30,7 +30,7 @@ AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) >> AC_TYPE_SIZE_T >> >> # Checks for library functions. >> -AC_CHECK_FUNCS([memset strcasecmp strncasecmp]) >> +AC_CHECK_FUNCS([memset strcasecmp strncasecmp setenv]) >> >> # Check if build chain supports symbol visibility >> AC_MSG_CHECKING([for -fvisibility=hidden compiler flag]) >> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >> index d178720..8ce11b8 100644 >> --- a/src/krb5_helper.c >> +++ b/src/krb5_helper.c >> @@ -15,7 +15,10 @@ >> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >> */ >> >> +#include "config.h" >> +#ifndef HAVE_SETENV >> #define _BSD_SOURCE >> +#endif /* HAVE_SETENV */ >> >> #include >> #include > >Hello, > >thank you for your patch but I'm going to stick to standard POSIX way. > NACK You don't know which version of posix is defined on machine. Hardcoded value is as bad. LS From lslebodn at redhat.com Wed Nov 26 16:13:36 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 26 Nov 2014 17:13:36 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <5475F751.5070407@redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> <54636F1F.6090701@redhat.com> <20141126145715.GB22838@mail.corp.redhat.com> <5475F751.5070407@redhat.com> Message-ID: <20141126161335.GE22838@mail.corp.redhat.com> On (26/11/14 16:52), Petr Spacek wrote: >On 26.11.2014 15:57, Lukas Slebodnik wrote: >> On (12/11/14 15:30), Petr Spacek wrote: >>> On 24.7.2014 11:00, Petr Spacek wrote: >>>> On 27.2.2014 15:19, Lukas Slebodnik wrote: >>>>> ehlo, >>>>> >>>>> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying >>>>> to export special CFLAGS for bind9 header files. It can be automatically >>>>> detected in configure script using utility isc-config. >>>>> >>>>> Attached patch should improve this and CFLAGS needn't be exported. >>>> >>>> Kind NACK. It would be valuable to test if isc/errno2result.h header is >>>> present and throw appropriate error. >>>> >>>> Current check with isc-config.sh only will pass if you have bind-devel package >>>> installed but you are missing bind-lite-devel package. >>>> >>>> >>>> I have a question: How >>>> +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 >>>> works? >>>> >>>> Will it take user-defined CFLAGS into account? I would like to place >>>> user-defined flags at the end of the list so you can easily override settings >>>> given by autotools. >>>> >>>> Thank you for clarification :-) >>>> >>>> >>>> I will be really happy to commit complete fix. Thank you for cleaning this >>>> autotools mess! >>> >>> This version actually works. Previous version did not take CFLAGS from >>> isc-config.sh into account during libdns version check so it actually did not >>> work at all :-) >>> >>> Please review it (and send me a modified patch if you see a problem). >>> >>> Thank you for your time! >>> >>> -- >>> Petr^2 Spacek >> >>>From 4b17099abe2169ddb86b24e53cd2769b76f3ea2d Mon Sep 17 00:00:00 2001 >>> From: Lukas Slebodnik >>> Date: Tue, 25 Feb 2014 10:46:50 +0100 >>> Subject: [PATCH] Improve detection of BIND 9 header files and necessary >>> CFLAGS. >>> >>> BIND 9 header files can be stored in non-default path (/usr/include/bind9). >>> The isc-config.sh utility can provide necessary CFLAGS. >>> --- >>> configure.ac | 43 ++++++++++++++++++++++++++++++++++--------- >>> contrib/bind-dyndb-ldap.spec | 1 - >>> 2 files changed, 34 insertions(+), 10 deletions(-) >>> >>> diff --git a/configure.ac b/configure.ac >>> index d471038ada54c07dcfc211c8a2572850e3b28205..c985908c760c974f7c02b6fa3d183e839bbeb9ad 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -15,14 +15,6 @@ m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) >>> AC_PROG_CC >>> AC_PROG_LIBTOOL >>> >>> -# Checks for libraries. >>> -AC_CHECK_LIB([dns], [dns_name_init], [], >>> - AC_MSG_ERROR([Install BIND9 development files])) >>> -AC_CHECK_LIB([ldap], [ldap_initialize], [], >>> - AC_MSG_ERROR([Install OpenLDAP development files])) >>> -AC_CHECK_LIB([krb5], [krb5_cc_initialize], [], >>> - AC_MSG_ERROR([Install Kerberos 5 development files])) >>> - >>> # Checks for header files. >>> AC_CHECK_HEADERS([stddef.h stdlib.h string.h strings.h]) >>> >>> @@ -47,6 +39,39 @@ AC_TRY_COMPILE([ >>> [CFLAGS="$SAVED_CFLAGS" >>> AC_MSG_RESULT([no])]) >>> >>> +# Get CFLAGS from isc-config.sh >>> +AC_ARG_VAR([BIND9_CFLAGS], >>> + [C compiler flags for bind9, overriding isc-config.sh]) >>> +AC_SUBST(BIND9_CFLAGS) >>> + >>> +dnl do not override enviroment variables BIND9_CFLAGS >>> +if test -z "$BIND9_CFLAGS"; then >> ^^^^^^^^^^^^^^^^^^^^^^^^^ >> What is a purpose of this condition. >> IIRC "AC_SUBST(BIND9_CFLAGS)" should allow you to override BIND9_CFLAGS >> from command line. > >Don's ask me, it was in your original version of the patch :-) > It wasn't in my version. LS From pspacek at redhat.com Wed Nov 26 16:45:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:45:13 +0100 Subject: [Freeipa-devel] [PATCH 0309] Fix crash caused by interaction between forward and master zones In-Reply-To: <5475C89D.2000808@redhat.com> References: <5474B83D.4020201@redhat.com> <5474C575.5020009@redhat.com> <5475C89D.2000808@redhat.com> Message-ID: <54760399.4010609@redhat.com> On 26.11.2014 13:33, Tomas Hozza wrote: > On 11/25/2014 07:07 PM, Martin Basti wrote: >> > On 25/11/14 18:11, Petr Spacek wrote: >>> > > Hello, >>> > > >>> > > Fix crash caused by interaction between forward and master zones. >>> > > >>> > > LDAP modifications made to idnsName=sub, idnsName=example.com, cn=dns object >>> > > were incorrectly processed using update_zone() in cases where forward zone >>> > > sub.example.com. existed in LDAP as object idnsName=sub.example.com, cn=dns. >>> > > >>> > > https://fedorahosted.org/bind-dyndb-ldap/ticket/145 >>> > > >>> > > >>> > > Tomas and Martin^2, please review it ASAP. Thank you! >>> > > >> > Works for me, IPA tests passed, can you Tomas check the code before push? >> > > ACK. Pushed to master: 584f9ceeef131145feb32a741a8f5dbc04b9a2cd -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 16:45:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:45:16 +0100 Subject: [Freeipa-devel] [PATCH 0310] Fix misleading error message about forward zones on reconnect In-Reply-To: <5475D1F9.6090902@redhat.com> References: <5474BC0E.5030003@redhat.com> <5474C98B.4070405@redhat.com> <5475D1F9.6090902@redhat.com> Message-ID: <5476039C.9020902@redhat.com> On 26.11.2014 14:13, Tomas Hozza wrote: > On 11/25/2014 07:25 PM, Martin Basti wrote: >> > On 25/11/14 18:27, Petr Spacek wrote: >>> > > Hello, >>> > > >>> > > Fix misleading error message about forward zones on reconnect. >>> > > >>> > > Previously the plugin could log 'already exist' error after >>> > > successful reconnection to LDAP for each active forward zone. >>> > > >>> > > Now it prints message: >>> > > forward zone 'fw.example.com': loaded >>> > > >>> > > >> > Log looks better now, ACK if Tomas has no objections. >> > > ACK. Pushed to master: a0ef923d7074a2aff2089f6affcda94843fd9455 -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 16:45:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:45:17 +0100 Subject: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE In-Reply-To: <5475C1C2.6050406@redhat.com> References: <530B69E0.7000705@redhat.com> <20140224175636.GD7116@mail.corp.redhat.com> <530C5A30.2070401@redhat.com> <20140225140540.GA6432@mail.corp.redhat.com> <54637E1E.8090009@redhat.com> <5474D00C.3020001@redhat.com> <5475C1C2.6050406@redhat.com> Message-ID: <5476039D.6040706@redhat.com> On 26.11.2014 13:04, Tomas Hozza wrote: > On 11/25/2014 07:53 PM, Martin Basti wrote: >> > On 12/11/14 16:34, Petr Spacek wrote: >>> > > On 25.2.2014 15:05, Lukas Slebodnik wrote: >>>> > >> On (25/02/14 09:54), Petr Spacek wrote: >>>>> > >>> On 24.2.2014 18:56, Lukas Slebodnik wrote: >>>>>> > >>>> On (24/02/14 16:48), Petr Spacek wrote: >>>>>>> > >>>>> Hello, >>>>>>> > >>>>> >>>>>>> > >>>>> Drop unnecessary #define _BSD_SOURCE. >>>>>>> > >>>>> >>>>>>> > >>>>> -- >>>>>>> > >>>>> Petr^2 Spacek >>>>>> > >>>> >From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 >>>>>>> > >>>>> From: Petr Spacek >>>>>>> > >>>>> Date: Mon, 24 Feb 2014 16:48:09 +0100 >>>>>>> > >>>>> Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. >>>>>>> > >>>>> >>>>>>> > >>>>> Signed-off-by: Petr Spacek >>>>>>> > >>>>> --- >>>>>>> > >>>>> src/krb5_helper.c | 2 -- >>>>>>> > >>>>> 1 file changed, 2 deletions(-) >>>>>>> > >>>>> >>>>>>> > >>>>> diff --git a/src/krb5_helper.c b/src/krb5_helper.c >>>>>>> > >>>>> index >>>>>>> > >>>>> d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 >>>>>>> > >>>>> 100644 >>>>>>> > >>>>> --- a/src/krb5_helper.c >>>>>>> > >>>>> +++ b/src/krb5_helper.c >>>>>>> > >>>>> @@ -15,8 +15,6 @@ >>>>>>> > >>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >>>>>>> > >>>>> */ >>>>>>> > >>>>> >>>>>>> > >>>>> -#define _BSD_SOURCE >>>>>>> > >>>>> - >>>>>>> > >>>>> #include >>>>>>> > >>>>> #include >>>>>>> > >>>>> #include >>>>>>> > >>>>> -- >>>>>>> > >>>>> 1.8.5.3 >>>>>>> > >>>>> >>>>>> > >>>> Simo is an author (according to git blame) >>>>>> > >>>> He defined this macro due to function setenv >>>>>> > >>>> >>>>> > >>> >from man setenv: >>>>>> > >>>> NAME >>>>>> > >>>> setenv - change or add an environment variable >>>>>> > >>>> >>>>>> > >>>> SYNOPSIS >>>>>> > >>>> #include >>>>>> > >>>> >>>>>> > >>>> int setenv(const char *name, const char *value, int overwrite); >>>>>> > >>>> >>>>>> > >>>> int unsetenv(const char *name); >>>>>> > >>>> >>>>>> > >>>> Feature Test Macro Requirements for glibc (see feature_test_macros(7)): >>>>>> > >>>> >>>>>> > >>>> setenv(), unsetenv(): >>>>>> > >>>> _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600 >>>>>> > >>>> ---------------------------------------------------------------------------- >>>>>> > >>>> >>>>>> > >>>> Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included >>>>>> > >>>> header file . I tested only on fedora 20. It can be used >>>>>> > >>>> on the other distributions. >>>>>> > >>>> >>>>>> > >>>> I would rather let this macro as is. >>>>> > >>> Wow, I didn't expect that somebody will spend time on this :-) >>>>> > >>> >>>>> > >>> See build logs from Fedora 21 >>>>> > >>> http://koji.fedoraproject.org/koji/getfile?taskID=6565007&name=build.log >>>> > >> You should have noticed this in the 1st mail. Because it is difference between >>>> > >> removing unnecessary macro and depprecated usage of macro. >>>> > >> >>>> > >> /usr/include/features.h:145:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE >>>> > >> are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] >>>> > >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" >>>> > >> >>>>> > >>> Patches with 'the right' solution are welcome. I'm not going to spend >>>>> > >>> more time on this. >>> > > Attached patch should fix the warning in the 'proper' way, I hope. Without >>> > > this patch the warning constantly pops up on Fedora 21. >>> > > >> > Works for me, I haven't had warning there. >> > > ACK. Pushed to master: 8ad9965136ab15f14cdb356a81a141575b2a84aa -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 16:45:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:45:19 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <5475BA7C.5040808@redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> <53D0CB27.7090203@redhat.com> <54636F1F.6090701@redhat.com> <5475BA7C.5040808@redhat.com> Message-ID: <5476039F.7090704@redhat.com> On 26.11.2014 12:33, Tomas Hozza wrote: > On 11/12/2014 03:30 PM, Petr Spacek wrote: >> > On 24.7.2014 11:00, Petr Spacek wrote: >>> > > On 27.2.2014 15:19, Lukas Slebodnik wrote: >>>> > >> ehlo, >>>> > >> >>>> > >> I did some reviews of bind-dyndb-ldap last week and it was little bit annoying >>>> > >> to export special CFLAGS for bind9 header files. It can be automatically >>>> > >> detected in configure script using utility isc-config. >>>> > >> >>>> > >> Attached patch should improve this and CFLAGS needn't be exported. >>> > > >>> > > Kind NACK. It would be valuable to test if isc/errno2result.h header is >>> > > present and throw appropriate error. >>> > > >>> > > Current check with isc-config.sh only will pass if you have bind-devel package >>> > > installed but you are missing bind-lite-devel package. >>> > > >>> > > >>> > > I have a question: How >>> > > +ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99 >>> > > works? >>> > > >>> > > Will it take user-defined CFLAGS into account? I would like to place >>> > > user-defined flags at the end of the list so you can easily override settings >>> > > given by autotools. >>> > > >>> > > Thank you for clarification :-) >>> > > >>> > > >>> > > I will be really happy to commit complete fix. Thank you for cleaning this >>> > > autotools mess! >> > >> > This version actually works. Previous version did not take CFLAGS from >> > isc-config.sh into account during libdns version check so it actually did not >> > work at all :-) >> > >> > Please review it (and send me a modified patch if you see a problem). >> > >> > Thank you for your time! >> > > ACK. Pushed to master: 2af6e66e251a0d142b8fa05d7ad5a95fb9946e3e -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 16:45:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:45:21 +0100 Subject: [Freeipa-devel] [PATCH 0306] Improve info messages about number of defined/loaded zones In-Reply-To: <5475C28B.9020808@redhat.com> References: <545CBC32.7030205@redhat.com> <5475C28B.9020808@redhat.com> Message-ID: <547603A1.4040501@redhat.com> On 26.11.2014 13:07, Tomas Hozza wrote: > On 11/07/2014 01:33 PM, Petr Spacek wrote: >> > Hello, >> > >> > Improve info messages about number of defined/loaded zones. >> > > ACK. > > The new message looks good. Pushed to master: eb600df6af932292e0a15817710cfc674f5c952b -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 26 16:47:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Nov 2014 17:47:16 +0100 Subject: [Freeipa-devel] [PATCH 0308] Improve detection of BIND 9 isc__errno2result header file In-Reply-To: <5475C9F9.5080900@redhat.com> References: <5463788B.3060107@redhat.com> <5474CF1B.7080501@redhat.com> <5475C9F9.5080900@redhat.com> Message-ID: <54760414.9070405@redhat.com> On 26.11.2014 13:39, Tomas Hozza wrote: > On 11/25/2014 07:48 PM, Martin Basti wrote: >> > On 12/11/14 16:11, Petr Spacek wrote: >>> > > Hello, >>> > > >>> > > Improve detection of BIND 9 isc__errno2result header file. >>> > > >>> > > This header file is not in standard distribution so normal isc-config.sh >>> > > detection is not enough. >>> > > >>> > > With this patch, ./configure should work even without explicit CFLAGS and it >>> > > should also detect that bind-devel or bind-lite-devel packages are missing. >>> > > >>> > > >> > Works for me >> > > ACK. Pushed to master: 3e364c72f79e3cec69fc4c3263cd0bccbc467bf5 -- Petr^2 Spacek From redhatrises at gmail.com Wed Nov 26 23:50:07 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 26 Nov 2014 16:50:07 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: Message-ID: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4700 > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0036-2-Add-missing-python-files-to-Makefiles.patch Type: text/x-patch Size: 2564 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 27 10:00:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Nov 2014 11:00:19 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: Message-ID: <5476F633.30808@redhat.com> On 27/11/14 00:50, Gabe Alford wrote: > Hello, > > Wondering if I could get a review. Updated patch attached. > > Thanks, > Gabe > > On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4700 > > Thanks, > > Gabe > > > Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The "app_PYTHON" statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Nov 27 11:56:21 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 27 Nov 2014 12:56:21 +0100 Subject: [Freeipa-devel] [PATCH 0287] Re-initialize NSS database after otptoken plugin tests In-Reply-To: <5475C32C.9030509@redhat.com> References: <546F1844.9000503@redhat.com> <5475C32C.9030509@redhat.com> Message-ID: <54771165.2020300@redhat.com> On 11/26/2014 01:10 PM, Petr Viktorin wrote: > On 11/21/2014 11:47 AM, Tomas Babej wrote: >> Hi, >> >> OTP token tests do not properly reinitialize the NSS db, thus >> making subsequent xmlrpc tests fail on SSL cert validation. >> >> Make sure NSS db is re-initalized in the teardown method. >> >> https://fedorahosted.org/freeipa/ticket/4748 >> >> Note for reviewers: Requires Petr^3's pytest patchset, which I am >> pushing right now. >> > > Thank you! > ACK, pushed to master: 792ff0c0c40ddd1583c6789c8f34382c050d3e92 > > Also sending rebased version for 4-1 branch. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0287-4-1-Re-initialize-NSS-database-after-otptoken-plugin-tes.patch Type: text/x-patch Size: 3041 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 27 13:20:53 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Nov 2014 14:20:53 +0100 Subject: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds Message-ID: <54772535.40202@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4771 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0173-Throw-zonemgr-error-message-before-installation-proc.patch Type: text/x-patch Size: 5401 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 27 13:24:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Nov 2014 14:24:49 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade Message-ID: <54772621.5050003@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4676 Replaces current workaround. Should go to 4.1.3. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0168-Using-wget-to-get-status-of-CA.patch Type: text/x-patch Size: 4344 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 27 14:50:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Nov 2014 15:50:56 +0100 Subject: [Freeipa-devel] [PATCH] 790 webui: fix service unprovisioning Message-ID: <54773A50.1000405@redhat.com> Missed part of field refactoring caused that service could not be unprovisioned. https://fedorahosted.org/freeipa/ticket/4770 For regression tests I've opened ticket: https://fedorahosted.org/freeipa/ticket/4772 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0790-webui-fix-service-unprovisioning.patch Type: text/x-patch Size: 1035 bytes Desc: not available URL: From thozza at redhat.com Thu Nov 27 14:56:38 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 27 Nov 2014 15:56:38 +0100 Subject: [Freeipa-devel] [PATCH 0307] Send DNS NOTIFY message after any modification to the zone In-Reply-To: <5475CBB3.7030505@redhat.com> References: <545CD869.5010402@redhat.com> <5475CBB3.7030505@redhat.com> Message-ID: <54773BA6.9070908@redhat.com> On 11/26/2014 01:46 PM, Martin Basti wrote: > On 07/11/14 15:34, Petr Spacek wrote: > > Hello, > > > > Send DNS NOTIFY message after any modification to the zone. > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/144 > > > Works for me. But don't push it before Tomas check the code please. > Martin^2 > ACK. Works for me... Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Thu Nov 27 15:12:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Nov 2014 16:12:02 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <5476F633.30808@redhat.com> References: <5476F633.30808@redhat.com> Message-ID: <54773F42.7030405@redhat.com> On 27.11.2014 11:00, Martin Basti wrote: > On 27/11/14 00:50, Gabe Alford wrote: >> Hello, >> >> Wondering if I could get a review. Updated patch attached. >> >> Thanks, >> Gabe >> >> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > > wrote: >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4700 >> >> Thanks, >> >> Gabe >> >> >> > Hello, > > sorry for late response. > > We push this ticket to backlog, as it would be part of build system refactoring. > The "app_PYTHON" statement is not used anymore in IPA, the better solution is > remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek From mkosek at redhat.com Thu Nov 27 15:26:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Nov 2014 16:26:02 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <54773F42.7030405@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> Message-ID: <5477428A.9010309@redhat.com> On 11/27/2014 04:12 PM, Petr Spacek wrote: > On 27.11.2014 11:00, Martin Basti wrote: >> On 27/11/14 00:50, Gabe Alford wrote: >>> Hello, >>> >>> Wondering if I could get a review. Updated patch attached. >>> >>> Thanks, >>> Gabe >>> >>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >> > wrote: >>> >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> >> Hello, >> >> sorry for late response. >> >> We push this ticket to backlog, as it would be part of build system refactoring. >> The "app_PYTHON" statement is not used anymore in IPA, the better solution is >> remove it, instead of keeping dead code up-to-date. > > Just to clarify: > It can be pushed if it works, there is no need to postpone accepting patch if > the patch seems okay and doesn't break anything. > > Martin, please keep in mind that contributions are welcome at any time. > > Milestones in Trac reflect our view of priorities but it doesn't prevent us > from accepting correct patches from contributions at any time, no matter which > priority is stated in Trac (or even if there is no ticket for it ...). This is not a problem of prioritization and the Trac tickets do not indeed prevent accepting contributions to current FreeIPA branches (well, of course, big refactoring would not fit stabilization release etc.). However, AFAIU, in this case Gabe tried to make an unused autotool option up to date, which as Martin correctly stated "the better solution is remove it, instead of keeping dead code up-to-date". So in this light, the patch does not break anything, but is not the best move forward either as it would promote redundant work in maintaining unused autotools variable. Martin From redhatrises at gmail.com Thu Nov 27 15:27:40 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 27 Nov 2014 09:27:40 -0600 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <54773F42.7030405@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> Message-ID: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek wrote: > On 27.11.2014 11:00, Martin Basti wrote: > > On 27/11/14 00:50, Gabe Alford wrote: > >> Hello, > >> > >> Wondering if I could get a review. Updated patch attached. > >> > >> Thanks, > >> Gabe > >> > >> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >> >> wrote: > >> > >> Hello, > >> > >> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >> > >> Thanks, > >> > >> Gabe > >> > >> > >> > > Hello, > > > > sorry for late response. > > > > We push this ticket to backlog, as it would be part of build system > refactoring. > > The "app_PYTHON" statement is not used anymore in IPA, the better > solution is > > remove it, instead of keeping dead code up-to-date. > > Just to clarify: > It can be pushed if it works, there is no need to postpone accepting patch > if > the patch seems okay and doesn't break anything. > > Martin, please keep in mind that contributions are welcome at any time. > > Milestones in Trac reflect our view of priorities but it doesn't prevent us > from accepting correct patches from contributions at any time, no matter > which > priority is stated in Trac (or even if there is no ticket for it ...). > > -- > Petr^2 Spacek > > _______________________________________________ > 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 mkosek at redhat.com Thu Nov 27 15:40:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Nov 2014 16:40:53 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> Message-ID: <54774605.2090603@redhat.com> Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: > Thanks guys. Sounds like it would be better to submit a patch that removes > app_PYTHON if it is considered dead code. > > Gabe > > On Thursday, November 27, 2014, Petr Spacek wrote: > >> On 27.11.2014 11:00, Martin Basti wrote: >>> On 27/11/14 00:50, Gabe Alford wrote: >>>> Hello, >>>> >>>> Wondering if I could get a review. Updated patch attached. >>>> >>>> Thanks, >>>> Gabe >>>> >>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >>>> >> wrote: >>>> >>>> Hello, >>>> >>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>>> >>>> >>> Hello, >>> >>> sorry for late response. >>> >>> We push this ticket to backlog, as it would be part of build system >> refactoring. >>> The "app_PYTHON" statement is not used anymore in IPA, the better >> solution is >>> remove it, instead of keeping dead code up-to-date. >> >> Just to clarify: >> It can be pushed if it works, there is no need to postpone accepting patch >> if >> the patch seems okay and doesn't break anything. >> >> Martin, please keep in mind that contributions are welcome at any time. >> >> Milestones in Trac reflect our view of priorities but it doesn't prevent us >> from accepting correct patches from contributions at any time, no matter >> which >> priority is stated in Trac (or even if there is no ticket for it ...). >> >> -- >> Petr^2 Spacek >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pvoborni at redhat.com Thu Nov 27 16:11:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Nov 2014 17:11:33 +0100 Subject: [Freeipa-devel] [PATCH] 791 fix indentation in ipa-restore page Message-ID: <54774D35.3050907@redhat.com> -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0791-fix-indentation-in-ipa-restore-page.patch Type: text/x-patch Size: 1437 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 27 16:25:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Nov 2014 17:25:34 +0100 Subject: [Freeipa-devel] [PATCH 0307] Send DNS NOTIFY message after any modification to the zone In-Reply-To: <54773BA6.9070908@redhat.com> References: <545CD869.5010402@redhat.com> <5475CBB3.7030505@redhat.com> <54773BA6.9070908@redhat.com> Message-ID: <5477507E.5000004@redhat.com> On 27.11.2014 15:56, Tomas Hozza wrote: > On 11/26/2014 01:46 PM, Martin Basti wrote: >> > On 07/11/14 15:34, Petr Spacek wrote: >>> > > Hello, >>> > > >>> > > Send DNS NOTIFY message after any modification to the zone. >>> > > >>> > > https://fedorahosted.org/bind-dyndb-ldap/ticket/144 >>> > > >> > Works for me. But don't push it before Tomas check the code please. >> > Martin^2 >> > > ACK. Works for me... Pushed to master: 7dd6ba6c70273fef0ffd34b265e6f1a1b6988a26 -- Petr^2 Spacek From pvoborni at redhat.com Thu Nov 27 16:28:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Nov 2014 17:28:21 +0100 Subject: [Freeipa-devel] [PATCH 0287] Re-initialize NSS database after otptoken plugin tests In-Reply-To: <54771165.2020300@redhat.com> References: <546F1844.9000503@redhat.com> <5475C32C.9030509@redhat.com> <54771165.2020300@redhat.com> Message-ID: <54775125.2000609@redhat.com> On 11/27/2014 12:56 PM, Tomas Babej wrote: > > On 11/26/2014 01:10 PM, Petr Viktorin wrote: >> On 11/21/2014 11:47 AM, Tomas Babej wrote: >>> Hi, >>> >>> OTP token tests do not properly reinitialize the NSS db, thus >>> making subsequent xmlrpc tests fail on SSL cert validation. >>> >>> Make sure NSS db is re-initalized in the teardown method. >>> >>> https://fedorahosted.org/freeipa/ticket/4748 >>> >>> Note for reviewers: Requires Petr^3's pytest patchset, which I am >>> pushing right now. >>> >> >> Thank you! >> ACK, pushed to master: 792ff0c0c40ddd1583c6789c8f34382c050d3e92 >> >> > > Also sending rebased version for 4-1 branch. > ACK Pushed to ipa-4-1: 7215f7e2215b485daac7dc5d54478752b682181b -- Petr Vobornik From pvoborni at redhat.com Thu Nov 27 16:59:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Nov 2014 17:59:35 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 4.1.2 Message-ID: <54775877.6060102@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.2 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.2 == === Bug fixes === * CVE-2014-7850: ensure that user input is properly escaped to prevent XSS attacks [https://fedorahosted.org/freeipa/ticket/4742] [http://www.freeipa.org/page/CVE-2014-7850] * harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2 * fixed getkeytab operation [https://fedorahosted.org/freeipa/ticket/4718] [https://fedorahosted.org/freeipa/ticket/4728] * backup and restore fixes related to certificates restore and SELinux context * static code analysis fixes * various small fixes == 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 if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require 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 3.3.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 4.1.1 == === Alexander Bokovoy (2) === * Update slapi-nis dependency to pull 0.54.1 * AD trust: improve trust validation === David Kupka (6) === * Remove unneeded internal methods. Move code to public methods. * Remove service file even if it isn't link. * Produce better error in group-add command. * Fix --{user,group}-ignore-attribute in migration plugin. * ipa-restore: Check if directory is provided + better errors. * Fix error message for nonexistent members and add tests. === Gabe Alford (1) === * ipa-server-install Directory Manager help incorrect === Jan Cholasta (15) === * Fix CA certificate backup and restore * Update Requires on pki-ca to 10.2.1-0.1 * Fix wrong expiration date on renewed IPA CA certificates * Restore file extended attributes and SELinux context in ipa-restore * Use correct service name in cainstance.backup_config * Stop tracking certificates before restoring them in ipa-restore * Remove redefinition of LOG from ipa-otp-lasttoken * Unload P11_Helper object's library when it is finalized in ipap11helper * Fix Kerberos error handling in ipa-sam * Fix unchecked return value in ipa-kdb * Fix unchecked return values in ipa-winsync * Fix unchecked return value in ipa-join * Fix unchecked return value in krb5 common utils * Fix memory leak in GetKeytabControl asn1 code * Add TLS 1.2 to the protocol list in mod_nss config === Martin Ba?ti (12) === * Fix: DNS installer adds invalid zonemgr email * Fix: DNS policy upgrade raises asertion error * Fix upgrade referint plugin * Upgrade: fix trusts objectclass violationi * Fix named working directory permissions * Fix: zonemgr must be unicode value * Fix warning message should not contain CLI commands * Show warning instead of error if CA did not start * Raise right exception if domain name is not valid * Fix pk11helper module compiler warnings * Fix: read_ip_addresses should return ipaddr object * Fix detection of encoding in zonemgr option === Martin Ko?ek (1) === * Lower pki-ca requires to 10.1.2 === Nathaniel McCallum (3) === * Improve otptoken help messages * Ensure users exist when assigning tokens to them * Enable QR code display by default in otptoken-add === Petr Viktorin (5) === * ipa-restore: Don't crash if AD trust is not installed * ipaplatform: Use the dirsrv service, not target * Do not restore SELinux settings that were not backed up * Add additional backup & restore checks * copy_schema_to_ca: Fallback to old import location for ipaplatform.services === Petr Voborn?k (9) === * ranges: prohibit setting --rid-base with ipa-trust-ad-posix type * unittests: baserid for ipa-ad-trust-posix idranges * ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges * idrange: include raw range type in output * webui: prohibit setting rid base with ipa-trust-ad-posix type * webui: fix potential XSS vulnerabilities * restore: clear httpd ccache after restore * webui: use domain name instead of domain SID in idrange adder dialog * webui: normalize idview tab labels === Petr ?pa?ek (1) === * Fix minimal version of BIND for Fedora 20 and 21 === Rob Crittenden (2) === * Search using proper scope when connecting CA instances * Use NSS protocol range API to set available TLS protocols === Simo Sorce (4) === * Add UTC date to GIT snapshot version generation * Fix filtering of enctypes in server code. * Add asn1c generated code for keytab controls * Use asn1c helpers to encode/decode the getkeytab control === Thorsten Scherf (1) === * Add help string on how to configure multiple DNS forwards for various cli tools -- Petr Vobornik From mkosek at redhat.com Fri Nov 28 09:22:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Nov 2014 10:22:15 +0100 Subject: [Freeipa-devel] FreeIPA.org wiki updated to 1.24 Message-ID: <54783EC7.6000804@redhat.com> I did several updates to our FreeIPA.org mediawiki and upgraded it from obsoleting 1.21 to LTS 1.24 version: http://www.mediawiki.org/wiki/Release_notes/1.24#MediaWiki_1.24.0 The upgrade of both Mediawiki and the data looks successful, among other things the mail notifications now seem to be fixed as a by product :-) If you notice any rough edges or issues caused by the upgrade, please let me know. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pspacek at redhat.com Fri Nov 28 15:03:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Nov 2014 16:03:14 +0100 Subject: [Freeipa-devel] [PATCH 0311-0314] Preparation for 6.1 release Message-ID: <54788EB2.8090901@redhat.com> Hello, Bump NVR to 6.1. Pushed to master: 5adca1bbfc2c19c53ecda649b94960f6abe73cf6 Add release engineering tools to source tree. Pushed to master: b85fed4c4512537d9dce39f525c556a02e436753 Update NEWS for upcoming 6.1 release. Pushed to master: e92d96de044c1b1a36d1d1a2a444656278edf0a6 Update .gitignore to skip compile script from Autotools. Pushed to master: 75a706252bf816cbe236791e187c80d83774ad7d -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0311-Update-.gitignore-to-skip-compile-script-from-Autoto.patch Type: text/x-patch Size: 577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0312-Update-NEWS-for-upcoming-6.1-release.patch Type: text/x-patch Size: 1005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0313-Add-release-engineering-tools-to-source-tree.patch Type: text/x-patch Size: 11046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0314-Bump-NVR-to-6.1.patch Type: text/x-patch Size: 1146 bytes Desc: not available URL: From pviktori at redhat.com Fri Nov 28 18:24:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Nov 2014 19:24:53 +0100 Subject: [Freeipa-devel] [PATCH] 0678 test_integration: Use collect_log from the host, not the testing class Message-ID: <5478BDF5.1020304@redhat.com> I removed a convenience function from the testing class but didn't catch all its uses. Here's a fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0678-test_integration-Use-collect_log-from-the-host-not-t.patch Type: text/x-patch Size: 2390 bytes Desc: not available URL: From redhatrises at gmail.com Sun Nov 30 01:03:04 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sat, 29 Nov 2014 19:03:04 -0600 Subject: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4583 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0038-Update-default-NTP-configuration.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: From redhatrises at gmail.com Sun Nov 30 01:03:54 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sat, 29 Nov 2014 19:03:54 -0600 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <54774605.2090603@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> Message-ID: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek wrote: > Exactly, this was the message from Martin :-) I did not test it myself, but > removing all app_PYTHON should be benign given we use Python setup.py > packaging. > > On 11/27/2014 04:27 PM, Gabe Alford wrote: > > Thanks guys. Sounds like it would be better to submit a patch that > removes > > app_PYTHON if it is considered dead code. > > > > Gabe > > > > On Thursday, November 27, 2014, Petr Spacek wrote: > > > >> On 27.11.2014 11:00, Martin Basti wrote: > >>> On 27/11/14 00:50, Gabe Alford wrote: > >>>> Hello, > >>>> > >>>> Wondering if I could get a review. Updated patch attached. > >>>> > >>>> Thanks, > >>>> Gabe > >>>> > >>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >> > >>>> >> wrote: > >>>> > >>>> Hello, > >>>> > >>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >>>> > >>>> Thanks, > >>>> > >>>> Gabe > >>>> > >>>> > >>>> > >>> Hello, > >>> > >>> sorry for late response. > >>> > >>> We push this ticket to backlog, as it would be part of build system > >> refactoring. > >>> The "app_PYTHON" statement is not used anymore in IPA, the better > >> solution is > >>> remove it, instead of keeping dead code up-to-date. > >> > >> Just to clarify: > >> It can be pushed if it works, there is no need to postpone accepting > patch > >> if > >> the patch seems okay and doesn't break anything. > >> > >> Martin, please keep in mind that contributions are welcome at any time. > >> > >> Milestones in Trac reflect our view of priorities but it doesn't > prevent us > >> from accepting correct patches from contributions at any time, no matter > >> which > >> priority is stated in Trac (or even if there is no ticket for it ...). > >> > >> -- > >> Petr^2 Spacek > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > > > > > > > > _______________________________________________ > > 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-rga-0036-3-Add-missing-python-files-to-Makefiles.patch Type: text/x-patch Size: 3469 bytes Desc: not available URL: From redhatrises at gmail.com Sun Nov 30 02:28:56 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sat, 29 Nov 2014 19:28:56 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> Message-ID: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford wrote: > This patch removes the app_PYTHON usage. > > Thanks, > > Gabe > > On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek wrote: > >> Exactly, this was the message from Martin :-) I did not test it myself, >> but >> removing all app_PYTHON should be benign given we use Python setup.py >> packaging. >> >> On 11/27/2014 04:27 PM, Gabe Alford wrote: >> > Thanks guys. Sounds like it would be better to submit a patch that >> removes >> > app_PYTHON if it is considered dead code. >> > >> > Gabe >> > >> > On Thursday, November 27, 2014, Petr Spacek wrote: >> > >> >> On 27.11.2014 11:00, Martin Basti wrote: >> >>> On 27/11/14 00:50, Gabe Alford wrote: >> >>>> Hello, >> >>>> >> >>>> Wondering if I could get a review. Updated patch attached. >> >>>> >> >>>> Thanks, >> >>>> Gabe >> >>>> >> >>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >> >> >>>> >> wrote: >> >>>> >> >>>> Hello, >> >>>> >> >>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Gabe >> >>>> >> >>>> >> >>>> >> >>> Hello, >> >>> >> >>> sorry for late response. >> >>> >> >>> We push this ticket to backlog, as it would be part of build system >> >> refactoring. >> >>> The "app_PYTHON" statement is not used anymore in IPA, the better >> >> solution is >> >>> remove it, instead of keeping dead code up-to-date. >> >> >> >> Just to clarify: >> >> It can be pushed if it works, there is no need to postpone accepting >> patch >> >> if >> >> the patch seems okay and doesn't break anything. >> >> >> >> Martin, please keep in mind that contributions are welcome at any time. >> >> >> >> Milestones in Trac reflect our view of priorities but it doesn't >> prevent us >> >> from accepting correct patches from contributions at any time, no >> matter >> >> which >> >> priority is stated in Trac (or even if there is no ticket for it ...). >> >> >> >> -- >> >> Petr^2 Spacek >> >> >> >> _______________________________________________ >> >> Freeipa-devel mailing list >> >> Freeipa-devel at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> > >> > >> > >> > _______________________________________________ >> > 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-rga-0036-3-Remove-usage-of-app_PYTHON-in-ipaserver-Makefiles.patch Type: text/x-patch Size: 1973 bytes Desc: not available URL: