From mkosek at redhat.com Tue Jul 1 07:21:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 09:21:21 +0200 Subject: [Freeipa-devel] [PATCH] 1108 Remove smartproxy In-Reply-To: <53B1E660.9040702@redhat.com> References: <53B1E660.9040702@redhat.com> Message-ID: <53B26171.6080900@redhat.com> On 07/01/2014 12:36 AM, Rob Crittenden wrote: > The Foreman Smart Proxy server has its own upstream now at > https://fedorahosted.org/freeipa-foreman-smartproxy/ so this source is > no longer needed. > > rob ACK, thanks. Pushed to master: 54e4891fef1efc7af5f1d1485cadfc7ae2e98ad2 Martin From mkosek at redhat.com Tue Jul 1 07:27:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 09:27:11 +0200 Subject: [Freeipa-devel] [PATCH] 1108 Remove smartproxy In-Reply-To: <53B26171.6080900@redhat.com> References: <53B1E660.9040702@redhat.com> <53B26171.6080900@redhat.com> Message-ID: <53B262CF.5070808@redhat.com> On 07/01/2014 09:21 AM, Martin Kosek wrote: > On 07/01/2014 12:36 AM, Rob Crittenden wrote: >> The Foreman Smart Proxy server has its own upstream now at >> https://fedorahosted.org/freeipa-foreman-smartproxy/ so this source is >> no longer needed. >> >> rob > > ACK, thanks. > > Pushed to master: 54e4891fef1efc7af5f1d1485cadfc7ae2e98ad2 > > Martin I spoke too fast. We forget to remove python-cherrypy as a BuildRequires. Fixed with the attached one liner and pushed to master. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-473-remove-python-cherrypy-buildrequires.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: From mkosek at redhat.com Tue Jul 1 07:37:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 09:37:54 +0200 Subject: [Freeipa-devel] [PATCH] 0612 permission plugin: Ignore unparseable ACIs In-Reply-To: <53B1CAA9.1020608@redhat.com> References: <53B1CAA9.1020608@redhat.com> Message-ID: <53B26552.1080701@redhat.com> On 06/30/2014 10:38 PM, Petr Viktorin wrote: > Hello, > The new ipaAllowedOperation ACIs cannot be parsed by the ACI parser. This made > operations on ACIs on the same entry fail (because the plugin needs to go > through all ACIs on the entry, parsing out the name, until it finds one with > the correct name). > > This fixes the issue, and adds a test that fails without the patch. > > > Workaround for: https://fedorahosted.org/freeipa/ticket/4376 Yup, this fixed it for me, tests are (almost) clean. ACK, pushed to master: fdef2e1bd80d688467aeb8ac425e9010bf00c530 Martin From pviktori at redhat.com Tue Jul 1 07:59:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Jul 2014 09:59:33 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount In-Reply-To: <53B1744F.8060509@redhat.com> References: <53B13CC2.6010301@redhat.com> <53B14FBC.8070406@redhat.com> <53B150E1.9000700@redhat.com> <53B1744F.8060509@redhat.com> Message-ID: <53B26A65.2060702@redhat.com> On 06/30/2014 04:29 PM, Martin Kosek wrote: > On 06/30/2014 01:58 PM, Petr Viktorin wrote: >> On 06/30/2014 01:53 PM, Martin Kosek wrote: >>> On 06/30/2014 12:32 PM, Petr Viktorin wrote: >>>> Fix for https://fedorahosted.org/freeipa/ticket/4409 >>> >>> I think something is missing here :-) >>> >> >> Sorry for that. > > Looks ok. Do we need to add the new "remove" definitions given that the > respective ACIs were never released? I am just aiming for update file sanity. Right, we don't. I only left the ones up to the ipa-3-3 version. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0610.2-Allow-admins-to-write-krbLoginFailedCount.patch Type: text/x-patch Size: 5930 bytes Desc: not available URL: From mkosek at redhat.com Tue Jul 1 08:00:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 10:00:17 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140630131623.GE13108@redhat.com> References: <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> <20140627110329.GY7233@redhat.com> <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> <20140630084332.GA13108@redhat.com> <1404128954.2332.17.camel@unused-4-145.brq.redhat.com> <20140630131623.GE13108@redhat.com> Message-ID: <53B26A91.5070005@redhat.com> On 06/30/2014 03:16 PM, Alexander Bokovoy wrote: > On Mon, 30 Jun 2014, Martin Basti wrote: >>> >We can use 'label = label.encode("ascii")' to detect if IDNA is needed, >>> >without idna.ToASCII() conversion, and then use: >>> > >>> >is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) >>> Sounds good but don't forget exceptions' handling. :) >>> >> >> Updated patch attached. >> >> I modified error messages, IDNA mapping is not only mapping to lowercase > Looks good to me. ipa-adtrust-install, ipa dnsrecord-add validation worked as expected. I just had to add link to ticket https://fedorahosted.org/freeipa/ticket/4382 to the description. ACK. Pushed to master. Martin From mkosek at redhat.com Tue Jul 1 08:03:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 10:03:49 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount In-Reply-To: <53B26A65.2060702@redhat.com> References: <53B13CC2.6010301@redhat.com> <53B14FBC.8070406@redhat.com> <53B150E1.9000700@redhat.com> <53B1744F.8060509@redhat.com> <53B26A65.2060702@redhat.com> Message-ID: <53B26B65.4030102@redhat.com> On 07/01/2014 09:59 AM, Petr Viktorin wrote: > On 06/30/2014 04:29 PM, Martin Kosek wrote: >> On 06/30/2014 01:58 PM, Petr Viktorin wrote: >>> On 06/30/2014 01:53 PM, Martin Kosek wrote: >>>> On 06/30/2014 12:32 PM, Petr Viktorin wrote: >>>>> Fix for https://fedorahosted.org/freeipa/ticket/4409 >>>> >>>> I think something is missing here :-) >>>> >>> >>> Sorry for that. >> >> Looks ok. Do we need to add the new "remove" definitions given that the >> respective ACIs were never released? I am just aiming for update file sanity. > > Right, we don't. > I only left the ones up to the ipa-3-3 version. ACK! Pushed to master: d1ede2068008e367f538a7f3d7e0e2d3ee128b79 Martin From mbasti at redhat.com Tue Jul 1 08:11:28 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 10:11:28 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSSEC: Add TLSA record In-Reply-To: <53B18B39.6040605@redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> <53AC0AAA.1090403@redhat.com> <1403873746.2249.5.camel@unused-4-145.brq.redhat.com> <53B18B39.6040605@redhat.com> Message-ID: <1404202288.24263.4.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-30 at 18:07 +0200, Petr Vobornik wrote: > On 27.6.2014 14:55, Martin Basti wrote: > > On Thu, 2014-06-26 at 13:57 +0200, Petr Vobornik wrote: > >> On 25.6.2014 14:35, Martin Basti wrote: > >>> On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: > >>>> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 > >>>> Patches attached. > >>>> > >>>> Note: ACI will be updated in another patch which fix ACIs in DNS plugin > >>> > >>> Patches are here > >>> > >> What are patch 0078's dependencies? I'm missing necessary blobs.. > >> (current master). Also it requires rebase because of today's pushes to > >> master (VERSION conflict). > > > > Rebased patch attached > > > > Patch 0078-2: > > Just nitpicks. > > 1. The LDAP attribute type description should be changed to something > more meaningful. the "DNS-Based Authentication of Named Entities - > Transport Layer Security Protocol, RFC 6698" is the complete effort. It > does not say anything about the TLSA record itself. I suggest: "TLSA > certificate association, RFC 6698" which is used in chapter 2 of RFC 6698. This is synced with bind-dyndb-ldap, I use the same description. > 2. Nitpick: Not a proper alphabetic order ;) > - u'TSIG', u'TXT', > + u'TSIG', u'TLSA', u'TXT', Fixed > > Patch 0079: > > 3. A js-lint warning: > > /dns.js(1140): lint warning: extra comma is not recommended in array > initializers > ] > ............^ > > Just remove the comma on line 1139. To check it, run: > > `jsl -nofilelisting -nologo -nosummary -conf jsl.conf` > > in install/ui directory Fixed Updated patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0078-3-DNSSEC-add-TLSA-record-type.patch Type: text/x-patch Size: 22885 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0079-3-DNSSEC-WebUI-add-TLSA-record.patch Type: text/x-patch Size: 1817 bytes Desc: not available URL: From pspacek at redhat.com Tue Jul 1 08:43:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Jul 2014 10:43:27 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> Message-ID: <53B274AF.5010007@redhat.com> On 30.6.2014 17:10, Martin Basti wrote: > On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >> On 30.6.2014 14:33, Martin Basti wrote: >>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>> Patch attached. >> >> It works for me. >> >> Please change the string little bit, I have realized that we should ensure >> that file permissions are correct: >> >> chown named: * >> chmod u= * >> >> (the chmod part new) >> >> Thanks! >> > > Updated patch attached I'm really sorry, I had to change the message once again :-) None of us noticed that chmod command was completely incorrect. I'm attaching fixed patch as an apology. It works for me when applied to master (50c30c8401c21d43414404bd5caa157196449e4c). Functional self-ACK :-) IMHO it can be pushed if Python-review is okay. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch Type: text/x-patch Size: 3453 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jul 1 08:47:24 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Jul 2014 10:47:24 +0200 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <53B172CD.4040002@redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> <53AD314F.50906@redhat.com> <53B172CD.4040002@redhat.com> Message-ID: <53B2759C.3060603@redhat.com> On 30.6.2014 16:23, Endi Sukma Dewata wrote: > On 6/27/2014 3:54 AM, Petr Vobornik wrote: >> On 27.6.2014 09:48, Fraser Tweedale wrote: >>> On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: >>>> Patch 618 fixes a bug. >>>> >>>> Patches 680 and 681 were implemented along with it. They address >>>> pspacek's >>>> usability rant :). >>>> >>>> [PATCH] 680 webui: show notification instead of modal dialog on >>>> validation >>>> error >>>> [PATCH] 681 webui: fix required error notification in multivalued >>>> widget >>>> [PATCH] 682 webui: focus invalid widget on validation error >>>> -- >>>> Petr Vobornik >>> >>> ACK on 680 and 682. >>> >>> On 681: diff makes sense; I'm not 100% sure my testing has covered >>> cases that were previously failing. ACK if you're confident, >>> otherwise could you provide steps to verify? >> >> You need to find a required multivalued field. One is in "Identity/Realm >> Domains". Delete all values and hit update. It's little bit related to >> ticket: https://fedorahosted.org/freeipa/ticket/4057 >> >> Also when verifying validators in multivalued field, it's good to check >> if errors are provided only for "invalid" values, etc.. good test field >> is in "DNS/DNS Zones/some zone/Settings/ there is "Allow query" field >> which accepts network address, "any" or "none". > > ACK. pushed to master: * 93de5db39e5b2e5991c32a57958cedb0f8b41848 webui: show notification instead of modal dialog on validation error * c693b28babf97d22c14d37e024d551b583c4327f webui: fix required error notification in multivalued widget * 99c5f0511f697cc54a9de7994c3e6999c6fd119f webui: focus invalid widget on validation error > > This should be sufficient to close #4057. But just wondering, the Realm > Domains page right now is implemented as a details page with a > multi-valued widget. Would it make more sense to be a list page instead? > The realmdomains-mod CLI is kind of unusual too with the > --add/del-domain parameters. Why not use realmdomain-add/del commands? > Are there other commands implemented in this fashion? > Wrt CLI: Depends how you look at it and if/how much should our CLI/API reflect data structure. If you say, we have an object which contains/manages the realm domains used by IPA server, then it's implemented as in every other similar object with multivalued attribute. But it's also a singleton therefore the closest similar thing is a configuration. There could also be an argument that this functionality could have been added to config itself. If you say that each realm domain is an object or if you don't want to reflect the data structure and just focus on API then it's not implemented the best way. Wrt Web UI: Makes sense. The list UI would fit better (until the realmdomains object is extended by additional attr). -- Petr Vobornik From pviktori at redhat.com Tue Jul 1 08:49:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Jul 2014 10:49:42 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B274AF.5010007@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> Message-ID: <53B27626.5090902@redhat.com> On 07/01/2014 10:43 AM, Petr Spacek wrote: > On 30.6.2014 17:10, Martin Basti wrote: >> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>> On 30.6.2014 14:33, Martin Basti wrote: >>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>> Patch attached. >>> >>> It works for me. >>> >>> Please change the string little bit, I have realized that we should >>> ensure >>> that file permissions are correct: >>> >>> chown named: * >>> chmod u= * >>> >>> (the chmod part new) >>> >>> Thanks! >>> >> >> Updated patch attached > > I'm really sorry, I had to change the message once again :-) > > None of us noticed that chmod command was completely incorrect. I'm > attaching fixed patch as an apology. > > It works for me when applied to master > (50c30c8401c21d43414404bd5caa157196449e4c). > > Functional self-ACK :-) > > IMHO it can be pushed if Python-review is okay. Once again, please define new message classes in messages.py instead of just using PublicMessage with a custom string. Also, these messages will work for console output, but I'm not sure pre-wrapped text would look good in web UI. I'm not sold on the idea of giving instructions in warning messages. Would a link to some documentation be better? -- Petr? From pspacek at redhat.com Tue Jul 1 08:55:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Jul 2014 10:55:59 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B27626.5090902@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> Message-ID: <53B2779F.3040002@redhat.com> On 1.7.2014 10:49, Petr Viktorin wrote: > On 07/01/2014 10:43 AM, Petr Spacek wrote: >> On 30.6.2014 17:10, Martin Basti wrote: >>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>> Patch attached. >>>> >>>> It works for me. >>>> >>>> Please change the string little bit, I have realized that we should >>>> ensure >>>> that file permissions are correct: >>>> >>>> chown named: * >>>> chmod u= * >>>> >>>> (the chmod part new) >>>> >>>> Thanks! >>>> >>> >>> Updated patch attached >> >> I'm really sorry, I had to change the message once again :-) >> >> None of us noticed that chmod command was completely incorrect. I'm >> attaching fixed patch as an apology. >> >> It works for me when applied to master >> (50c30c8401c21d43414404bd5caa157196449e4c). >> >> Functional self-ACK :-) >> >> IMHO it can be pushed if Python-review is okay. > > Once again, please define new message classes in messages.py instead of just > using PublicMessage with a custom string. > > Also, these messages will work for console output, but I'm not sure > pre-wrapped text would look good in web UI. > I'm not sold on the idea of giving instructions in warning messages. Would a > link to some documentation be better? Well, the idea was to provide copy&paste instructions directly in the console, not speaking about problems with URLs downstream. If you insist on URL ... here it is: http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support -- Petr^2 Spacek From mbasti at redhat.com Tue Jul 1 10:10:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 12:10:10 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <53B150BC.1080505@redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> Message-ID: <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-30 at 13:57 +0200, Petr Viktorin wrote: > On 06/30/2014 12:48 PM, Martin Basti wrote: > > Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 > > Patch attached. > > > > When you add a new message, you should also define a new class for it in > messages.py with a new errno, not just reuse PublicMessage with a custom > string. > > Could it be WarningMessage? Or should I be more specific ForwardersWarningMessage, DNSSECWarningMessage ? Is there any rule how to choose errno? -- Martin^2 Basti From pviktori at redhat.com Tue Jul 1 10:17:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Jul 2014 12:17:34 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53B28ABE.5000904@redhat.com> On 07/01/2014 12:10 PM, Martin Basti wrote: > On Mon, 2014-06-30 at 13:57 +0200, Petr Viktorin wrote: >> On 06/30/2014 12:48 PM, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 >>> Patch attached. >>> >> >> When you add a new message, you should also define a new class for it in >> messages.py with a new errno, not just reuse PublicMessage with a custom >> string. >> >> > > Could it be WarningMessage? Or should I be more specific > ForwardersWarningMessage, DNSSECWarningMessage ? Be specific. I'd go for DNSSECWarning; "message" is already in the module name. > Is there any rule how to choose errno? Just use the next unused one. -- Petr? From mkosek at redhat.com Tue Jul 1 10:19:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 12:19:19 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABDD6D.6050905@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> <53ABDC28.1040607@redhat.com> <53ABDD6D.6050905@redhat.com> Message-ID: <53B28B27.1010609@redhat.com> On 06/26/2014 10:44 AM, Jan Cholasta wrote: > On 26.6.2014 10:39, Petr Viktorin wrote: >> On 06/26/2014 10:33 AM, Jan Cholasta wrote: >>> On 26.6.2014 09:40, Petr Viktorin wrote: >>>> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>>>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>>>> to string representation of the attribute. >>>>>>>>>> >>>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>>>> time attribute. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>>>> >>>>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>>>> requires you to check the type of the value before using it. >>>>>>>>> >>>>>>>>> Instead, you should either fix the code that uses the >>>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>>>> value >>>>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >> [...] >>>> >>>> The problem is that "unset" is a valid value here, >>> >>> It is not, according to Generalized Time syntax (RFC 4517 section >>> 3.3.13) "0" is an invalid value and we should treat it the same way as >>> any other invalid value (hence my original suggestion). >> >> OK, in that case ignore what I said here. >> >> So am I correct that 389-ds storing a value that doesn't comply with the >> attribute's syntax? Should we file a DS bug? >> > > AFAIK syntax checks are done only on LDAP adds and mods, so unless we are > setting "0" somewhere and DS does not complain, it is not a bug. What is the final resolution here? Do we plan to ignore the attribute conversion for these attributes as, fixing DS or are we fixing the framework? Surprisingly, I did not see the filed failure any more in my ipa-replica-install tests nor in the latest CI run, I wonder if anything changed in our code or if the issue is intermittent. Anyway, I am willing to close this ticket if this is no longer a problem. Martin From mkosek at redhat.com Tue Jul 1 10:20:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 12:20:37 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B2779F.3040002@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> Message-ID: <53B28B75.9000106@redhat.com> On 07/01/2014 10:55 AM, Petr Spacek wrote: > On 1.7.2014 10:49, Petr Viktorin wrote: >> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>> On 30.6.2014 17:10, Martin Basti wrote: >>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>> Patch attached. >>>>> >>>>> It works for me. >>>>> >>>>> Please change the string little bit, I have realized that we should >>>>> ensure >>>>> that file permissions are correct: >>>>> >>>>> chown named: * >>>>> chmod u= * >>>>> >>>>> (the chmod part new) >>>>> >>>>> Thanks! >>>>> >>>> >>>> Updated patch attached >>> >>> I'm really sorry, I had to change the message once again :-) >>> >>> None of us noticed that chmod command was completely incorrect. I'm >>> attaching fixed patch as an apology. >>> >>> It works for me when applied to master >>> (50c30c8401c21d43414404bd5caa157196449e4c). >>> >>> Functional self-ACK :-) >>> >>> IMHO it can be pushed if Python-review is okay. >> >> Once again, please define new message classes in messages.py instead of just >> using PublicMessage with a custom string. >> >> Also, these messages will work for console output, but I'm not sure >> pre-wrapped text would look good in web UI. >> I'm not sold on the idea of giving instructions in warning messages. Would a >> link to some documentation be better? > > Well, the idea was to provide copy&paste instructions directly in the console, > not speaking about problems with URLs downstream. > > If you insist on URL ... here it is: > http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support > Please use something more stable, like http://www.freeipa.org/page/DNSSEC which we would use as a gathering place for information about FreeIPA and DNSSEC. Martin From pspacek at redhat.com Tue Jul 1 10:23:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Jul 2014 12:23:56 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B28B75.9000106@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> Message-ID: <53B28C3C.2050903@redhat.com> On 1.7.2014 12:20, Martin Kosek wrote: > On 07/01/2014 10:55 AM, Petr Spacek wrote: >> On 1.7.2014 10:49, Petr Viktorin wrote: >>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>> Patch attached. >>>>>> >>>>>> It works for me. >>>>>> >>>>>> Please change the string little bit, I have realized that we should >>>>>> ensure >>>>>> that file permissions are correct: >>>>>> >>>>>> chown named: * >>>>>> chmod u= * >>>>>> >>>>>> (the chmod part new) >>>>>> >>>>>> Thanks! >>>>>> >>>>> >>>>> Updated patch attached >>>> >>>> I'm really sorry, I had to change the message once again :-) >>>> >>>> None of us noticed that chmod command was completely incorrect. I'm >>>> attaching fixed patch as an apology. >>>> >>>> It works for me when applied to master >>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>> >>>> Functional self-ACK :-) >>>> >>>> IMHO it can be pushed if Python-review is okay. >>> >>> Once again, please define new message classes in messages.py instead of just >>> using PublicMessage with a custom string. >>> >>> Also, these messages will work for console output, but I'm not sure >>> pre-wrapped text would look good in web UI. >>> I'm not sold on the idea of giving instructions in warning messages. Would a >>> link to some documentation be better? >> >> Well, the idea was to provide copy&paste instructions directly in the console, >> not speaking about problems with URLs downstream. >> >> If you insist on URL ... here it is: >> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >> > > Please use something more stable, like > > http://www.freeipa.org/page/DNSSEC > > which we would use as a gathering place for information about FreeIPA and DNSSEC. IMHO this particular warning should point to version-specific information. I'm not opposing to /page/DNSSEC idea in general but this warning should point to very specific steps which will be valid only to very specific version of FreeIPA. -- Petr^2 Spacek From tbabej at redhat.com Tue Jul 1 10:35:42 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Jul 2014 12:35:42 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53B28B27.1010609@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> <53ABDC28.1040607@redhat.com> <53ABDD6D.6050905@redhat.com> <53B28B27.1010609@redhat.com> Message-ID: <53B28EFE.4060507@redhat.com> On 07/01/2014 12:19 PM, Martin Kosek wrote: > On 06/26/2014 10:44 AM, Jan Cholasta wrote: >> On 26.6.2014 10:39, Petr Viktorin wrote: >>> On 06/26/2014 10:33 AM, Jan Cholasta wrote: >>>> On 26.6.2014 09:40, Petr Viktorin wrote: >>>>> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>>>>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>>>>> to string representation of the attribute. >>>>>>>>>>> >>>>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>>>>> time attribute. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>>>>> requires you to check the type of the value before using it. >>>>>>>>>> >>>>>>>>>> Instead, you should either fix the code that uses the >>>>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>>>>> value >>>>>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>> [...] >>>>> The problem is that "unset" is a valid value here, >>>> It is not, according to Generalized Time syntax (RFC 4517 section >>>> 3.3.13) "0" is an invalid value and we should treat it the same way as >>>> any other invalid value (hence my original suggestion). >>> OK, in that case ignore what I said here. >>> >>> So am I correct that 389-ds storing a value that doesn't comply with the >>> attribute's syntax? Should we file a DS bug? >>> >> AFAIK syntax checks are done only on LDAP adds and mods, so unless we are >> setting "0" somewhere and DS does not complain, it is not a bug. > What is the final resolution here? Do we plan to ignore the attribute > conversion for these attributes as, fixing DS or are we fixing the framework? > > Surprisingly, I did not see the filed failure any more in my > ipa-replica-install tests nor in the latest CI run, I wonder if anything > changed in our code or if the issue is intermittent. Anyway, I am willing to > close this ticket if this is no longer a problem. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Issue is not 100% reproducible in my testing. The underlying problem here is that sometimes the values of nsds5replicalastupdatestart and nsds5replicalastupdateend attributes are not being set during replication (intermittent issue) and thus 389 falls back and returns '0' if any of these attributes were explicitily requested, which is not a valid value for LDAP Generalized time. The reason you're not hitting the conversion errors is probably that during replication nsds5replicalastupdatestart and nsds5replicalastupdateend were assigned proper values. You can check that in the replication log (search for "Replication Update in progress: %s: status: %s: start: %d: end: %d" in the logs). I am checking with Ludvig, but if this behaviour is specific to the nsds5replicalastupdatestart and nsds5replicalastupdateend I'd go with the SYNTAX_OVERRIDE solution. However, it is worth noting that these conversion errors are harmless themselves. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Tue Jul 1 10:40:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Jul 2014 12:40:48 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSSEC: Add TLSA record In-Reply-To: <1404202288.24263.4.camel@unused-4-145.brq.redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> <53AC0AAA.1090403@redhat.com> <1403873746.2249.5.camel@unused-4-145.brq.redhat.com> <53B18B39.6040605@redhat.com> <1404202288.24263.4.camel@unused-4-145.brq.redhat.com> Message-ID: <53B29030.8060104@redhat.com> On 1.7.2014 10:11, Martin Basti wrote: > On Mon, 2014-06-30 at 18:07 +0200, Petr Vobornik wrote: >> On 27.6.2014 14:55, Martin Basti wrote: >>> On Thu, 2014-06-26 at 13:57 +0200, Petr Vobornik wrote: >>>> On 25.6.2014 14:35, Martin Basti wrote: >>>>> On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: >>>>>> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 >>>>>> Patches attached. >>>>>> >>>>>> Note: ACI will be updated in another patch which fix ACIs in DNS plugin >>>>> >>>>> Patches are here >>>>> >>>> What are patch 0078's dependencies? I'm missing necessary blobs.. >>>> (current master). Also it requires rebase because of today's pushes to >>>> master (VERSION conflict). >>> >>> Rebased patch attached >>> >> >> Patch 0078-2: >> >> Just nitpicks. >> >> 1. The LDAP attribute type description should be changed to something >> more meaningful. the "DNS-Based Authentication of Named Entities - >> Transport Layer Security Protocol, RFC 6698" is the complete effort. It >> does not say anything about the TLSA record itself. I suggest: "TLSA >> certificate association, RFC 6698" which is used in chapter 2 of RFC 6698. > This is synced with bind-dyndb-ldap, I use the same description. > >> 2. Nitpick: Not a proper alphabetic order ;) >> - u'TSIG', u'TXT', >> + u'TSIG', u'TLSA', u'TXT', > Fixed > >> >> Patch 0079: >> >> 3. A js-lint warning: >> >> /dns.js(1140): lint warning: extra comma is not recommended in array >> initializers >> ] >> ............^ >> >> Just remove the comma on line 1139. To check it, run: >> >> `jsl -nofilelisting -nologo -nosummary -conf jsl.conf` >> >> in install/ui directory > Fixed > > Updated patches attached. > ACK and pushed to master: * 12cb31575ca84d8084687c9906e5824462bd33ec DNSSEC: add TLSA record type * 8e911fcabc2c07cce42e32554cf8c9bcc6a544f5 DNSSEC: WebUI: add TLSA record -- Petr Vobornik From pviktori at redhat.com Tue Jul 1 10:44:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Jul 2014 12:44:52 +0200 Subject: [Freeipa-devel] [PATCH 0077] Fix ACI in DNS (was Add dnssecinlinesigning attribute to ACI) In-Reply-To: <53B193EE.3060409@redhat.com> References: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> <53AAA0C7.80501@redhat.com> <1403714829.2323.12.camel@unused-4-145.brq.redhat.com> <1403714941.2323.13.camel@unused-4-145.brq.redhat.com> <53B193EE.3060409@redhat.com> Message-ID: <53B29124.3070306@redhat.com> On 06/30/2014 06:44 PM, Petr Viktorin wrote: > On 06/25/2014 06:49 PM, Martin Basti wrote: >> On Wed, 2014-06-25 at 18:47 +0200, Martin Basti wrote: >>> On Wed, 2014-06-25 at 12:13 +0200, Petr Viktorin wrote: >>>> On 06/20/2014 03:32 PM, Martin Basti wrote: >>>>> Required patches: mbasti-0060, mbasti-0073 >>>>> >>>>> Patch attached. >>>>> >>>> >>>> Hi, >>>> >>>> For the raw ACI in dns.ldif, there are some more hoops to jump through. >>>> >>>> Remove the ACI from /install/share/dns.ldif entirely (except for >>>> schema, >>>> we're slowly replacing the .ldif content by .update files). >>>> >>>> In install/updates/40-dns.update, you'll notice the "Update DNS entries >>>> in a zone" ACI is already being added. You'll need to replace it, using >>>> a line like: >>>> replace:aci:'::' >>>> This will remove the old value that IPA 3.x users still have. >>>> >>>> I see you already changed the ACI in 7cdc417, in dns.ldif only. Be >>>> sureto use the original value for . >>>> >>>> >>> As we discuss personally, ACI requires more changes than add >>> idnssecinlinesingning only. >>> >>> Updated patch attached. >>> >> Patch freeipa-mbasti-0078-DNSSEC-add-TLSA-record-type.patch is required. > > If 0078 doesn't change substantially, ACK. Pushed to master: c655aa28321f3a0ef00de89dd4c726f39f62653e -- Petr? From mkosek at redhat.com Tue Jul 1 11:26:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 13:26:23 +0200 Subject: [Freeipa-devel] 4.0 schema in 60basev3.ldif? In-Reply-To: <1403875099.3551.7.camel@willson.usersys.redhat.com> References: <53AD5422.3070606@redhat.com> <1403875099.3551.7.camel@willson.usersys.redhat.com> Message-ID: <53B29ADF.9080107@redhat.com> On 06/27/2014 03:18 PM, Simo Sorce wrote: > On Fri, 2014-06-27 at 13:23 +0200, Martin Kosek wrote: >> It seems to me that we are being inconsistent with regards to our FreeIPA >> version and the schema files. >> >> We now have 60basev2.ldif containing FreeIPA 2.x schema, 60basev3.ldif >> containing FreeIPA 3.x schema. However, we now also added FreeIPA 4.x schema to >> 60basev3.ldif which seems as an inconsistency to me. >> >> Should we simply create 60basev4.ldif and move the new schema (mostly >> permissionsv2 related) there? > > If you think it make sense go ahead and do it. I think we kept > everything in the same file because at some point we changed (by adding > MAY attributes) older objectclasses and these modifications were made > before we decided to change version numbers to 4.0, but I find this > mostly cosmetic so I do not really care one way or the other. > >> I am wondering that in that case we may also >> think about making a new OID space for v4 schema as current one is defined as >> >> ## Attributes: 2.16.840.1.113730.3.8.11 - V3 base attributres >> ## ObjectClasses: 2.16.840.1.113730.3.8.12 - V3 base objectclasses >> >> If we ever want to fix the OID space, now is the right time, it won't be >> possible after release. Alternatively, we could also define >> 2.16.840.1.113730.3.8.11 and 2.16.840.1.113730.3.8.12 as "V3+" space. > > I do not think it makes any sense to change OID space now. > Feel free to mark the space as V3+ > > Simo. Ok, marking this as V3+ space seems as the way to go. It seems that nobody cares so I will not bikeshed on this myself. Martin From mkosek at redhat.com Tue Jul 1 11:45:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 13:45:41 +0200 Subject: [Freeipa-devel] [PATCH] 474 Update X-ORIGIN for 4.0 Message-ID: <53B29F65.8090303@redhat.com> This is a follow up to my origin question about 60basev3.ldif. I could not hold myself and had to fix the inconsistency and make the schema x-origin correct. No functional changes were made. --- It was decided not to change the OID space for FreeIPA 4.0+ objectclasses. However, we should still at least properly mark the X-ORIGIN to make analyzing schema easier. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-474-update-x-origin-for-4.0.patch Type: text/x-patch Size: 12140 bytes Desc: not available URL: From mbasti at redhat.com Tue Jul 1 11:51:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 13:51:46 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B28C3C.2050903@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> Message-ID: <1404215506.24263.12.camel@unused-4-145.brq.redhat.com> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: > On 1.7.2014 12:20, Martin Kosek wrote: > > On 07/01/2014 10:55 AM, Petr Spacek wrote: > >> On 1.7.2014 10:49, Petr Viktorin wrote: > >>> On 07/01/2014 10:43 AM, Petr Spacek wrote: > >>>> On 30.6.2014 17:10, Martin Basti wrote: > >>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: > >>>>>> On 30.6.2014 14:33, Martin Basti wrote: > >>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: > >>>>>>>> Patch attached. > >>>>>> > >>>>>> It works for me. > >>>>>> > >>>>>> Please change the string little bit, I have realized that we should > >>>>>> ensure > >>>>>> that file permissions are correct: > >>>>>> > >>>>>> chown named: * > >>>>>> chmod u= * > >>>>>> > >>>>>> (the chmod part new) > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>> > >>>>> Updated patch attached > >>>> > >>>> I'm really sorry, I had to change the message once again :-) > >>>> > >>>> None of us noticed that chmod command was completely incorrect. I'm > >>>> attaching fixed patch as an apology. > >>>> > >>>> It works for me when applied to master > >>>> (50c30c8401c21d43414404bd5caa157196449e4c). > >>>> > >>>> Functional self-ACK :-) > >>>> > >>>> IMHO it can be pushed if Python-review is okay. > >>> > >>> Once again, please define new message classes in messages.py instead of just > >>> using PublicMessage with a custom string. > >>> > >>> Also, these messages will work for console output, but I'm not sure > >>> pre-wrapped text would look good in web UI. > >>> I'm not sold on the idea of giving instructions in warning messages. Would a > >>> link to some documentation be better? > >> > >> Well, the idea was to provide copy&paste instructions directly in the console, > >> not speaking about problems with URLs downstream. > >> > >> If you insist on URL ... here it is: > >> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support > >> > > > > Please use something more stable, like > > > > http://www.freeipa.org/page/DNSSEC > > > > which we would use as a gathering place for information about FreeIPA and DNSSEC. > > IMHO this particular warning should point to version-specific information. > > I'm not opposing to /page/DNSSEC idea in general but this warning should point > to very specific steps which will be valid only to very specific version of > FreeIPA. > Make DNSSEC subsections per IPA version is IMO better, than change warnings in code per release. -- Martin^2 Basti From pviktori at redhat.com Tue Jul 1 11:58:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Jul 2014 13:58:36 +0200 Subject: [Freeipa-devel] [PATCH] 474 Update X-ORIGIN for 4.0 In-Reply-To: <53B29F65.8090303@redhat.com> References: <53B29F65.8090303@redhat.com> Message-ID: <53B2A26C.8030200@redhat.com> On 07/01/2014 01:45 PM, Martin Kosek wrote: > This is a follow up to my origin question about 60basev3.ldif. I could not hold > myself and had to fix the inconsistency and make the schema x-origin correct. > No functional changes were made. ACK, sure. Pushed to master: 21e1e4ac3bd62c20c6331ea3dc09793e3a869c22 > --- > > It was decided not to change the OID space for FreeIPA 4.0+ objectclasses. > However, we should still at least properly mark the X-ORIGIN to make > analyzing schema easier. Note for those that want to analyze the schema: the updater will put in the exact IPA version that touches the schema element. So for upgraded schema I'd now get something like: X-ORIGIN ( 'IPA v3.3.90GIT21e1e4a' 'user defined' ) -- Petr? From pspacek at redhat.com Tue Jul 1 11:59:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Jul 2014 13:59:48 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404215506.24263.12.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404215506.24263.12.camel@unused-4-145.brq.redhat.com> Message-ID: <53B2A2B4.4010103@redhat.com> On 1.7.2014 13:51, Martin Basti wrote: > On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >> On 1.7.2014 12:20, Martin Kosek wrote: >>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>> Patch attached. >>>>>>>> >>>>>>>> It works for me. >>>>>>>> >>>>>>>> Please change the string little bit, I have realized that we should >>>>>>>> ensure >>>>>>>> that file permissions are correct: >>>>>>>> >>>>>>>> chown named: * >>>>>>>> chmod u= * >>>>>>>> >>>>>>>> (the chmod part new) >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>> >>>>>>> Updated patch attached >>>>>> >>>>>> I'm really sorry, I had to change the message once again :-) >>>>>> >>>>>> None of us noticed that chmod command was completely incorrect. I'm >>>>>> attaching fixed patch as an apology. >>>>>> >>>>>> It works for me when applied to master >>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>> >>>>>> Functional self-ACK :-) >>>>>> >>>>>> IMHO it can be pushed if Python-review is okay. >>>>> >>>>> Once again, please define new message classes in messages.py instead of just >>>>> using PublicMessage with a custom string. >>>>> >>>>> Also, these messages will work for console output, but I'm not sure >>>>> pre-wrapped text would look good in web UI. >>>>> I'm not sold on the idea of giving instructions in warning messages. Would a >>>>> link to some documentation be better? >>>> >>>> Well, the idea was to provide copy&paste instructions directly in the console, >>>> not speaking about problems with URLs downstream. >>>> >>>> If you insist on URL ... here it is: >>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>> >>> >>> Please use something more stable, like >>> >>> http://www.freeipa.org/page/DNSSEC >>> >>> which we would use as a gathering place for information about FreeIPA and DNSSEC. >> >> IMHO this particular warning should point to version-specific information. >> >> I'm not opposing to /page/DNSSEC idea in general but this warning should point >> to very specific steps which will be valid only to very specific version of >> FreeIPA. >> > > Make DNSSEC subsections per IPA version is IMO better, than change > warnings in code per release. I thought that this warning will go away completely in the next version. Please keep in mind that we need to keep the link alive 'forever'. For this reason I would like to have version number in the URL so we don't have to mix instructions for IPA 4.0, 4.1, 4.2, 5.0 etc. on single page. Another option is to put the page into /usr/share/doc... and serve it through local Apache. -- Petr^2 Spacek From mkosek at redhat.com Tue Jul 1 12:04:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Jul 2014 14:04:04 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B2A2B4.4010103@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404215506.24263.12.camel@unused-4-145.brq.redhat.com> <53B2A2B4.4010103@redhat.com> Message-ID: <53B2A3B4.8020807@redhat.com> On 07/01/2014 01:59 PM, Petr Spacek wrote: > On 1.7.2014 13:51, Martin Basti wrote: >> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >>> On 1.7.2014 12:20, Martin Kosek wrote: >>>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>>> It works for me. >>>>>>>>> >>>>>>>>> Please change the string little bit, I have realized that we should >>>>>>>>> ensure >>>>>>>>> that file permissions are correct: >>>>>>>>> >>>>>>>>> chown named: * >>>>>>>>> chmod u= * >>>>>>>>> >>>>>>>>> (the chmod part new) >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>> >>>>>>>> Updated patch attached >>>>>>> >>>>>>> I'm really sorry, I had to change the message once again :-) >>>>>>> >>>>>>> None of us noticed that chmod command was completely incorrect. I'm >>>>>>> attaching fixed patch as an apology. >>>>>>> >>>>>>> It works for me when applied to master >>>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>>> >>>>>>> Functional self-ACK :-) >>>>>>> >>>>>>> IMHO it can be pushed if Python-review is okay. >>>>>> >>>>>> Once again, please define new message classes in messages.py instead of just >>>>>> using PublicMessage with a custom string. >>>>>> >>>>>> Also, these messages will work for console output, but I'm not sure >>>>>> pre-wrapped text would look good in web UI. >>>>>> I'm not sold on the idea of giving instructions in warning messages. Would a >>>>>> link to some documentation be better? >>>>> >>>>> Well, the idea was to provide copy&paste instructions directly in the >>>>> console, >>>>> not speaking about problems with URLs downstream. >>>>> >>>>> If you insist on URL ... here it is: >>>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>>> >>>> >>>> Please use something more stable, like >>>> >>>> http://www.freeipa.org/page/DNSSEC >>>> >>>> which we would use as a gathering place for information about FreeIPA and >>>> DNSSEC. >>> >>> IMHO this particular warning should point to version-specific information. >>> >>> I'm not opposing to /page/DNSSEC idea in general but this warning should point >>> to very specific steps which will be valid only to very specific version of >>> FreeIPA. >>> >> >> Make DNSSEC subsections per IPA version is IMO better, than change >> warnings in code per release. > > I thought that this warning will go away completely in the next version. > > Please keep in mind that we need to keep the link alive 'forever'. For this > reason I would like to have version number in the URL so we don't have to mix > instructions for IPA 4.0, 4.1, 4.2, 5.0 etc. on single page. > > Another option is to put the page into /usr/share/doc... and serve it through > local Apache. Please do not over-engineer this, we just want to pass couple simple commands. Could we just add the steps to "$ ipa help dns" online help + to the release notes + to DNS page on wiki? This should allow people interested in the manual steps to find the information without requiring us to invent some machinery for that help. Martin From pspacek at redhat.com Tue Jul 1 12:08:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Jul 2014 14:08:07 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B2A3B4.8020807@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404215506.24263.12.camel@unused-4-145.brq.redhat.com> <53B2A2B4.4010103@redhat.com> <53B2A3B4.8020807@redhat.com> Message-ID: <53B2A4A7.6010600@redhat.com> On 1.7.2014 14:04, Martin Kosek wrote: > On 07/01/2014 01:59 PM, Petr Spacek wrote: >> On 1.7.2014 13:51, Martin Basti wrote: >>> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >>>> On 1.7.2014 12:20, Martin Kosek wrote: >>>>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>>> It works for me. >>>>>>>>>> >>>>>>>>>> Please change the string little bit, I have realized that we should >>>>>>>>>> ensure >>>>>>>>>> that file permissions are correct: >>>>>>>>>> >>>>>>>>>> chown named: * >>>>>>>>>> chmod u= * >>>>>>>>>> >>>>>>>>>> (the chmod part new) >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>> >>>>>>>>> Updated patch attached >>>>>>>> >>>>>>>> I'm really sorry, I had to change the message once again :-) >>>>>>>> >>>>>>>> None of us noticed that chmod command was completely incorrect. I'm >>>>>>>> attaching fixed patch as an apology. >>>>>>>> >>>>>>>> It works for me when applied to master >>>>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>>>> >>>>>>>> Functional self-ACK :-) >>>>>>>> >>>>>>>> IMHO it can be pushed if Python-review is okay. >>>>>>> >>>>>>> Once again, please define new message classes in messages.py instead of just >>>>>>> using PublicMessage with a custom string. >>>>>>> >>>>>>> Also, these messages will work for console output, but I'm not sure >>>>>>> pre-wrapped text would look good in web UI. >>>>>>> I'm not sold on the idea of giving instructions in warning messages. Would a >>>>>>> link to some documentation be better? >>>>>> >>>>>> Well, the idea was to provide copy&paste instructions directly in the >>>>>> console, >>>>>> not speaking about problems with URLs downstream. >>>>>> >>>>>> If you insist on URL ... here it is: >>>>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>>>> >>>>> >>>>> Please use something more stable, like >>>>> >>>>> http://www.freeipa.org/page/DNSSEC >>>>> >>>>> which we would use as a gathering place for information about FreeIPA and >>>>> DNSSEC. >>>> >>>> IMHO this particular warning should point to version-specific information. >>>> >>>> I'm not opposing to /page/DNSSEC idea in general but this warning should point >>>> to very specific steps which will be valid only to very specific version of >>>> FreeIPA. >>>> >>> >>> Make DNSSEC subsections per IPA version is IMO better, than change >>> warnings in code per release. >> >> I thought that this warning will go away completely in the next version. >> >> Please keep in mind that we need to keep the link alive 'forever'. For this >> reason I would like to have version number in the URL so we don't have to mix >> instructions for IPA 4.0, 4.1, 4.2, 5.0 etc. on single page. >> >> Another option is to put the page into /usr/share/doc... and serve it through >> local Apache. > > Please do not over-engineer this, we just want to pass couple simple commands. > > Could we just add the steps to "$ ipa help dns" online help + to the release > notes + to DNS page on wiki? This should allow people interested in the manual > steps to find the information without requiring us to invent some machinery for > that help. WebUI users can't run 'ipa help dns' command :-) Maybe it is okay because they will have to open terminal anyway (to generate dnssec keys etc.). Maybe we can have 'ipa help dnssec' command. I'm personally okay with that as long as it contains the original text. -- Petr^2 Spacek From mbasti at redhat.com Tue Jul 1 12:24:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 14:24:19 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings Message-ID: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4413 Patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0084-Remove-NSEC3PARAM-record.patch Type: text/x-patch Size: 27170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0085-Add-NSEC3PARAM-to-zone-settings.patch Type: text/x-patch Size: 22346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0086-NSEC3PARAM-tests.patch Type: text/x-patch Size: 5095 bytes Desc: not available URL: From ssorce at redhat.com Tue Jul 1 12:39:45 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Jul 2014 08:39:45 -0400 Subject: [Freeipa-devel] [PATCH] 474 Update X-ORIGIN for 4.0 In-Reply-To: <53B29F65.8090303@redhat.com> References: <53B29F65.8090303@redhat.com> Message-ID: <1404218385.6436.63.camel@willson.usersys.redhat.com> On Tue, 2014-07-01 at 13:45 +0200, Martin Kosek wrote: > This is a follow up to my origin question about 60basev3.ldif. I could not hold > myself and had to fix the inconsistency and make the schema x-origin correct. > No functional changes were made. > > --- > > It was decided not to change the OID space for FreeIPA 4.0+ objectclasses. > However, we should still at least properly mark the X-ORIGIN to make > analyzing schema easier. Oh I did not think you'd go changing the X-ORIGIN in the schema but I see no issue in principle, so ACK. Simo. From rcritten at redhat.com Tue Jul 1 12:41:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2014 08:41:17 -0400 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53B28EFE.4060507@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> <53ABDC28.1040607@redhat.com> <53ABDD6D.6050905@redhat.com> <53B28B27.1010609@redhat.com> <53B28EFE.4060507@redhat.com> Message-ID: <53B2AC6D.8080602@redhat.com> Tomas Babej wrote: > > On 07/01/2014 12:19 PM, Martin Kosek wrote: >> On 06/26/2014 10:44 AM, Jan Cholasta wrote: >>> On 26.6.2014 10:39, Petr Viktorin wrote: >>>> On 06/26/2014 10:33 AM, Jan Cholasta wrote: >>>>> On 26.6.2014 09:40, Petr Viktorin wrote: >>>>>> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>>>>>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>>>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>>>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>>>>>> to string representation of the attribute. >>>>>>>>>>>> >>>>>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>>>>>> time attribute. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>>>>>> requires you to check the type of the value before using it. >>>>>>>>>>> >>>>>>>>>>> Instead, you should either fix the code that uses the >>>>>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>>>>>> value >>>>>>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>> [...] >>>>>> The problem is that "unset" is a valid value here, >>>>> It is not, according to Generalized Time syntax (RFC 4517 section >>>>> 3.3.13) "0" is an invalid value and we should treat it the same way as >>>>> any other invalid value (hence my original suggestion). >>>> OK, in that case ignore what I said here. >>>> >>>> So am I correct that 389-ds storing a value that doesn't comply with the >>>> attribute's syntax? Should we file a DS bug? >>>> >>> AFAIK syntax checks are done only on LDAP adds and mods, so unless we are >>> setting "0" somewhere and DS does not complain, it is not a bug. >> What is the final resolution here? Do we plan to ignore the attribute >> conversion for these attributes as, fixing DS or are we fixing the framework? >> >> Surprisingly, I did not see the filed failure any more in my >> ipa-replica-install tests nor in the latest CI run, I wonder if anything >> changed in our code or if the issue is intermittent. Anyway, I am willing to >> close this ticket if this is no longer a problem. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Issue is not 100% reproducible in my testing. The underlying problem > here is that sometimes the values of nsds5replicalastupdatestart and > nsds5replicalastupdateend attributes are not being set during > replication (intermittent issue) and thus 389 falls back and returns '0' > if any of these attributes were explicitily requested, which is not a > valid value for LDAP Generalized time. > > The reason you're not hitting the conversion errors is probably that > during replication nsds5replicalastupdatestart and > nsds5replicalastupdateend were assigned proper values. You can check > that in the replication log (search for "Replication Update in progress: > %s: status: %s: start: %d: end: %d" in the logs). > > I am checking with Ludvig, but if this behaviour is specific to the > nsds5replicalastupdatestart and nsds5replicalastupdateend I'd go with > the SYNTAX_OVERRIDE solution. > > However, it is worth noting that these conversion errors are harmless > themselves. > IIRC I also saw this with: ipa-replica-manage list -v `hostname` That may be easier to reproduce/validate. rob From mbasti at redhat.com Tue Jul 1 13:15:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 15:15:55 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> Message-ID: <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4413 > Patches attached > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0084-2-Remove-NSEC3PARAM-record.patch Type: text/x-patch Size: 27172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0085-2-Add-NSEC3PARAM-to-zone-settings.patch Type: text/x-patch Size: 22183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0086-2-NSEC3PARAM-tests.patch Type: text/x-patch Size: 5095 bytes Desc: not available URL: From edewata at redhat.com Tue Jul 1 13:47:56 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 01 Jul 2014 08:47:56 -0500 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <53B2759C.3060603@redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> <53AD314F.50906@redhat.com> <53B172CD.4040002@redhat.com> <53B2759C.3060603@redhat.com> Message-ID: <53B2BC0C.8090708@redhat.com> On 7/1/2014 3:47 AM, Petr Vobornik wrote: >> This should be sufficient to close #4057. But just wondering, the Realm >> Domains page right now is implemented as a details page with a >> multi-valued widget. Would it make more sense to be a list page instead? >> The realmdomains-mod CLI is kind of unusual too with the >> --add/del-domain parameters. Why not use realmdomain-add/del commands? >> Are there other commands implemented in this fashion? > > Wrt CLI: Depends how you look at it and if/how much should our CLI/API > reflect data structure. > > If you say, we have an object which contains/manages the realm domains > used by IPA server, then it's implemented as in every other similar > object with multivalued attribute. But it's also a singleton therefore > the closest similar thing is a configuration. There could also be an > argument that this functionality could have been added to config itself. > > If you say that each realm domain is an object or if you don't want to > reflect the data structure and just focus on API then it's not > implemented the best way. > > Wrt Web UI: Makes sense. The list UI would fit better (until the > realmdomains object is extended by additional attr). I think we should design CLI/UI from user's perspective because it's an interface after all, regardless of how it's stored on the server. Right now the design seems to be based on assumption that there won't be many realm domains (e.g. no need to search, no need to page), and there's no other attributes required for each realm domain (e.g. no description, no owner, etc.). But as soon as the assumption is no longer correct the current interface is no longer adequate. Treating realm domains as separate objects I think is more future-proof. -- Endi S. Dewata From rcritten at redhat.com Tue Jul 1 14:13:54 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2014 10:13:54 -0400 Subject: [Freeipa-devel] Smart proxy Fedora package Message-ID: <53B2C222.5000509@redhat.com> The smart proxy source was pulled from the IPA tree and moved into its own repository. I've created a Fedora package for it if someone can review it: https://bugzilla.redhat.com/show_bug.cgi?id=1114764 rob From tbabej at redhat.com Tue Jul 1 14:45:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Jul 2014 16:45:33 +0200 Subject: [Freeipa-devel] [PATCH 0238] ipaldap: Override conversion of nsds5replicalastupdatestart Message-ID: <53B2C98D.3030405@redhat.com> Hi, The replication related attributes nsds5replicalastupdatestart and nsds5replicalastupdateend have special behaviour implemented in 389, as follows: In case they are explicitly requested for and not set, 0 is returned. However, 0 is not a valid value for LDAP Generalized time. Thus we need to add these attributes to the _SYNTAX_OVERRIDE dictionary, overriding their conversion to datetime and converting them to string instead, which preserves the old behaviour expected by the replication codebase. https://fedorahosted.org/freeipa/ticket/4350 Note: This makes patch 236 obsolete. Note II: This is a short-term fix from my point of view. Ticket to resolve the underlying issue has been filed to 389: https://fedorahosted.org/389/ticket/47836 -- 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-0238-ipaldap-Override-conversion-of-nsds5replicalastupdat.patch Type: text/x-patch Size: 1436 bytes Desc: not available URL: From tbabej at redhat.com Tue Jul 1 14:48:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Jul 2014 16:48:39 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53B2AC6D.8080602@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> <53ABDC28.1040607@redhat.com> <53ABDD6D.6050905@redhat.com> <53B28B27.1010609@redhat.com> <53B28EFE.4060507@redhat.com> <53B2AC6D.8080602@redhat.com> Message-ID: <53B2CA47.4050003@redhat.com> On 07/01/2014 02:41 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 07/01/2014 12:19 PM, Martin Kosek wrote: >>> On 06/26/2014 10:44 AM, Jan Cholasta wrote: >>>> On 26.6.2014 10:39, Petr Viktorin wrote: >>>>> On 06/26/2014 10:33 AM, Jan Cholasta wrote: >>>>>> On 26.6.2014 09:40, Petr Viktorin wrote: >>>>>>> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>>>>>>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>>>>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>>>>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>>>>>>> to string representation of the attribute. >>>>>>>>>>>>> >>>>>>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>>>>>>> time attribute. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>>>>>>> requires you to check the type of the value before using it. >>>>>>>>>>>> >>>>>>>>>>>> Instead, you should either fix the code that uses the >>>>>>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>>>>>>> value >>>>>>>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>> [...] >>>>>>> The problem is that "unset" is a valid value here, >>>>>> It is not, according to Generalized Time syntax (RFC 4517 section >>>>>> 3.3.13) "0" is an invalid value and we should treat it the same way as >>>>>> any other invalid value (hence my original suggestion). >>>>> OK, in that case ignore what I said here. >>>>> >>>>> So am I correct that 389-ds storing a value that doesn't comply with the >>>>> attribute's syntax? Should we file a DS bug? >>>>> >>>> AFAIK syntax checks are done only on LDAP adds and mods, so unless we are >>>> setting "0" somewhere and DS does not complain, it is not a bug. >>> What is the final resolution here? Do we plan to ignore the attribute >>> conversion for these attributes as, fixing DS or are we fixing the framework? >>> >>> Surprisingly, I did not see the filed failure any more in my >>> ipa-replica-install tests nor in the latest CI run, I wonder if anything >>> changed in our code or if the issue is intermittent. Anyway, I am willing to >>> close this ticket if this is no longer a problem. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Issue is not 100% reproducible in my testing. The underlying problem >> here is that sometimes the values of nsds5replicalastupdatestart and >> nsds5replicalastupdateend attributes are not being set during >> replication (intermittent issue) and thus 389 falls back and returns '0' >> if any of these attributes were explicitily requested, which is not a >> valid value for LDAP Generalized time. >> >> The reason you're not hitting the conversion errors is probably that >> during replication nsds5replicalastupdatestart and >> nsds5replicalastupdateend were assigned proper values. You can check >> that in the replication log (search for "Replication Update in progress: >> %s: status: %s: start: %d: end: %d" in the logs). >> >> I am checking with Ludvig, but if this behaviour is specific to the >> nsds5replicalastupdatestart and nsds5replicalastupdateend I'd go with >> the SYNTAX_OVERRIDE solution. >> >> However, it is worth noting that these conversion errors are harmless >> themselves. >> > IIRC I also saw this with: > > ipa-replica-manage list -v `hostname` > > That may be easier to reproduce/validate. > > rob Please see my patch 238 on the list, which obsoletes this thread. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mbasti at redhat.com Tue Jul 1 15:23:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 17:23:54 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <53B28ABE.5000904@redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> <53B28ABE.5000904@redhat.com> Message-ID: <1404228234.24263.24.camel@unused-4-145.brq.redhat.com> On Tue, 2014-07-01 at 12:17 +0200, Petr Viktorin wrote: > On 07/01/2014 12:10 PM, Martin Basti wrote: > > On Mon, 2014-06-30 at 13:57 +0200, Petr Viktorin wrote: > >> On 06/30/2014 12:48 PM, Martin Basti wrote: > >>> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 > >>> Patch attached. > >>> > >> > >> When you add a new message, you should also define a new class for it in > >> messages.py with a new errno, not just reuse PublicMessage with a custom > >> string. > >> > >> > > > > Could it be WarningMessage? Or should I be more specific > > ForwardersWarningMessage, DNSSECWarningMessage ? > > Be specific. I'd go for DNSSECWarning; "message" is already in the > module name. > > > Is there any rule how to choose errno? > > Just use the next unused one. > > Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0082-2-Add-warning-about-semantic-change-for-zones.patch Type: text/x-patch Size: 4278 bytes Desc: not available URL: From mbasti at redhat.com Tue Jul 1 15:28:57 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Jul 2014 17:28:57 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing tlsarecord in 40-dns.update Message-ID: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0087-Fix-Missing-tlsarecord-in-40-dns.update.patch Type: text/x-patch Size: 4982 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jul 1 16:20:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Jul 2014 18:20:42 +0200 Subject: [Freeipa-devel] [PATCH] 693 webui-build: use /usr/share/java/js.jar instead of rhino.jar Message-ID: <53B2DFDA.6020604@redhat.com> /usr/share/java/rhino.jar is a Fedora's symlink to /usr/share/java/js.jar Debian doesn't have it. Direct usage of upstream /usr/share/java/js.jar should work on both systems. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0693-webui-build-use-usr-share-java-js.jar-instead-of-rhi.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: From tjaalton at ubuntu.com Tue Jul 1 16:27:54 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 01 Jul 2014 19:27:54 +0300 Subject: [Freeipa-devel] [PATCH] 693 webui-build: use /usr/share/java/js.jar instead of rhino.jar In-Reply-To: <53B2DFDA.6020604@redhat.com> References: <53B2DFDA.6020604@redhat.com> Message-ID: <53B2E18A.8060103@ubuntu.com> On 01.07.2014 19:20, Petr Vobornik wrote: > /usr/share/java/rhino.jar is a Fedora's symlink to /usr/share/java/js.jar > > Debian doesn't have it. Direct usage of upstream /usr/share/java/js.jar > should work on both systems. yup, tested on Debian and checked fedora rhino rpm that it has both. thanks! -- t From ftweedal at redhat.com Wed Jul 2 05:11:44 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 2 Jul 2014 15:11:44 +1000 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <53B125C4.9000708@redhat.com> References: <53AD5F83.5040003@redhat.com> <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> <53B125C4.9000708@redhat.com> Message-ID: <20140702051144.GR2417@dhcp-40-8.bne.redhat.com> On Mon, Jun 30, 2014 at 10:54:28AM +0200, Petr Vobornik wrote: > On 30.6.2014 09:13, Fraser Tweedale wrote: > >On Fri, Jun 27, 2014 at 02:11:47PM +0200, Petr Vobornik wrote: > >>Make the label of these buttons consistent with other buttons which have > >>capital first letters. > >>-- > >>Petr Vobornik > > > >> From 7214242fb0c5accc45b6af476a8ff7e7b1a7883f Mon Sep 17 00:00:00 2001 > >>From: Petr Vobornik > >>Date: Fri, 27 Jun 2014 13:59:11 +0200 > >>Subject: [PATCH] webui: capitalize labels of undo and undo all buttons > >> > >>Make the label of these buttons consistent with other buttons which have > >>capital first letters. > >>--- > >> install/ui/test/data/ipa_init.json | 4 ++-- > >> ipalib/plugins/internal.py | 4 ++-- > >> 2 files changed, 4 insertions(+), 4 deletions(-) > >> > >>diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json > >>index 0c32395ee7d68440aea0271359b0ac88fed86c42..20a462fff3b664d2320946765d1dac21ac2b1929 100644 > >>--- a/install/ui/test/data/ipa_init.json > >>+++ b/install/ui/test/data/ipa_init.json > >>@@ -563,8 +563,8 @@ > >> "next": "Next", > >> "page": "Page", > >> "prev": "Prev", > >>- "undo": "undo", > >>- "undo_all": "undo all", > >>+ "undo": "Undo", > >>+ "undo_all": "Undo All", > >> "validation": { > >> "error": "Text does not match field pattern", > >> "datetime": "Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")", > >>diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py > >>index f9ae831dc665b1282ded798023856dacec480e3b..cda9fdc7ba5237bc5bcfddbce20f47abbc210a40 100644 > >>--- a/ipalib/plugins/internal.py > >>+++ b/ipalib/plugins/internal.py > >>@@ -708,8 +708,8 @@ class i18n_messages(Command): > >> "next": _("Next"), > >> "page": _("Page"), > >> "prev": _("Prev"), > >>- "undo": _("undo"), > >>- "undo_all": _("undo all"), > >>+ "undo": _("Undo"), > >>+ "undo_all": _("Undo All"), > > > >Does this affect translations? The msgid "undo all" is present in > >the PO files. > > Yes > Translations are lost as a result of this change, due to case sensitive translation lookup by msgid. I guess our translation workflow takes care of this - in which case, ACK. Speaking of which, I couldn't find anything on the wiki about how we do our translations (i.e., how or when stuff gets pulled into/out of transifex, who's responsible for that part of the process). Would be good to find out more about it :) Cheers, Fraser > > > >Fraser > > > >> "validation": { > >> "error": _("Text does not match field pattern"), > >> "datetime": _("Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")"), > >>-- > >>1.9.0 > >> > > > -- > Petr Vobornik From jcholast at redhat.com Wed Jul 2 06:14:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 02 Jul 2014 08:14:42 +0200 Subject: [Freeipa-devel] [PATCH 0238] ipaldap: Override conversion of nsds5replicalastupdatestart In-Reply-To: <53B2C98D.3030405@redhat.com> References: <53B2C98D.3030405@redhat.com> Message-ID: <53B3A352.8080702@redhat.com> On 1.7.2014 16:45, Tomas Babej wrote: > Hi, > > The replication related attributes nsds5replicalastupdatestart and > nsds5replicalastupdateend have special behaviour implemented in 389, > as follows: > > In case they are explicitly requested for and not set, 0 is returned. > > However, 0 is not a valid value for LDAP Generalized time. Thus > we need to add these attributes to the _SYNTAX_OVERRIDE dictionary, > overriding their conversion to datetime and converting them to > string instead, which preserves the old behaviour expected by the > replication codebase. > > https://fedorahosted.org/freeipa/ticket/4350 > > Note: This makes patch 236 obsolete. > Note II: This is a short-term fix from my point of view. Ticket to > resolve the underlying issue has been filed to 389: > > https://fedorahosted.org/389/ticket/47836 It should be unicode, not str, if you want old behavior. -- Jan Cholasta From mkosek at redhat.com Wed Jul 2 06:52:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Jul 2014 08:52:23 +0200 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <20140702051144.GR2417@dhcp-40-8.bne.redhat.com> References: <53AD5F83.5040003@redhat.com> <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> <53B125C4.9000708@redhat.com> <20140702051144.GR2417@dhcp-40-8.bne.redhat.com> Message-ID: <53B3AC27.1060909@redhat.com> On 07/02/2014 07:11 AM, Fraser Tweedale wrote: > On Mon, Jun 30, 2014 at 10:54:28AM +0200, Petr Vobornik wrote: >> On 30.6.2014 09:13, Fraser Tweedale wrote: >>> On Fri, Jun 27, 2014 at 02:11:47PM +0200, Petr Vobornik wrote: >>>> Make the label of these buttons consistent with other buttons which have >>>> capital first letters. >>>> -- >>>> Petr Vobornik >>> >>>> From 7214242fb0c5accc45b6af476a8ff7e7b1a7883f Mon Sep 17 00:00:00 2001 >>>> From: Petr Vobornik >>>> Date: Fri, 27 Jun 2014 13:59:11 +0200 >>>> Subject: [PATCH] webui: capitalize labels of undo and undo all buttons >>>> >>>> Make the label of these buttons consistent with other buttons which have >>>> capital first letters. >>>> --- >>>> install/ui/test/data/ipa_init.json | 4 ++-- >>>> ipalib/plugins/internal.py | 4 ++-- >>>> 2 files changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json >>>> index 0c32395ee7d68440aea0271359b0ac88fed86c42..20a462fff3b664d2320946765d1dac21ac2b1929 100644 >>>> --- a/install/ui/test/data/ipa_init.json >>>> +++ b/install/ui/test/data/ipa_init.json >>>> @@ -563,8 +563,8 @@ >>>> "next": "Next", >>>> "page": "Page", >>>> "prev": "Prev", >>>> - "undo": "undo", >>>> - "undo_all": "undo all", >>>> + "undo": "Undo", >>>> + "undo_all": "Undo All", >>>> "validation": { >>>> "error": "Text does not match field pattern", >>>> "datetime": "Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")", >>>> diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py >>>> index f9ae831dc665b1282ded798023856dacec480e3b..cda9fdc7ba5237bc5bcfddbce20f47abbc210a40 100644 >>>> --- a/ipalib/plugins/internal.py >>>> +++ b/ipalib/plugins/internal.py >>>> @@ -708,8 +708,8 @@ class i18n_messages(Command): >>>> "next": _("Next"), >>>> "page": _("Page"), >>>> "prev": _("Prev"), >>>> - "undo": _("undo"), >>>> - "undo_all": _("undo all"), >>>> + "undo": _("Undo"), >>>> + "undo_all": _("Undo All"), >>> >>> Does this affect translations? The msgid "undo all" is present in >>> the PO files. >> >> Yes >> > > Translations are lost as a result of this change, due to case > sensitive translation lookup by msgid. I guess our translation > workflow takes care of this - in which case, ACK. > > Speaking of which, I couldn't find anything on the wiki about how we > do our translations (i.e., how or when stuff gets pulled into/out of > transifex, who's responsible for that part of the process). Would > be good to find out more about it :) Petr Viktorin takes care of pulling the translations before the release. However, I must admit we do not have a firm translation workflow defined yet, we try not to mess with translations close to the release, but we do not announce official string freeze. Martin From pviktori at redhat.com Wed Jul 2 07:39:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 09:39:37 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3B739.4040301@redhat.com> On 07/01/2014 03:15 PM, Martin Basti wrote: > On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4413 >> Patches attached > > Rebased patches attached > 0084: in dns.py, you'll also want to remove NSEC3PARAMRecord from _dns_records. Otherwise I still see it in API.txt for dnsrecord_add & friends. 0085: _nsec3param_errmsg will not get picked up by xgettext, so it won't be translated. The argument to _() must be a literal string, not a variable. -- Petr? From pspacek at redhat.com Wed Jul 2 07:40:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Jul 2014 09:40:08 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing tlsarecord in 40-dns.update In-Reply-To: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3B758.2060809@redhat.com> On 1.7.2014 17:28, Martin Basti wrote: > Patch attached I'm not able to apply it on top of current master (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). -- Petr^2 Spacek From pviktori at redhat.com Wed Jul 2 07:43:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 09:43:02 +0200 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <53B3AC27.1060909@redhat.com> References: <53AD5F83.5040003@redhat.com> <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> <53B125C4.9000708@redhat.com> <20140702051144.GR2417@dhcp-40-8.bne.redhat.com> <53B3AC27.1060909@redhat.com> Message-ID: <53B3B806.1020807@redhat.com> On 07/02/2014 08:52 AM, Martin Kosek wrote: > On 07/02/2014 07:11 AM, Fraser Tweedale wrote: >> On Mon, Jun 30, 2014 at 10:54:28AM +0200, Petr Vobornik wrote: >>> On 30.6.2014 09:13, Fraser Tweedale wrote: >>>> On Fri, Jun 27, 2014 at 02:11:47PM +0200, Petr Vobornik wrote: >>>>> Make the label of these buttons consistent with other buttons which have >>>>> capital first letters. >>>>> -- >>>>> Petr Vobornik >>>> >>>>> From 7214242fb0c5accc45b6af476a8ff7e7b1a7883f Mon Sep 17 00:00:00 2001 >>>>> From: Petr Vobornik >>>>> Date: Fri, 27 Jun 2014 13:59:11 +0200 >>>>> Subject: [PATCH] webui: capitalize labels of undo and undo all buttons >>>>> >>>>> Make the label of these buttons consistent with other buttons which have >>>>> capital first letters. >>>>> --- >>>>> install/ui/test/data/ipa_init.json | 4 ++-- >>>>> ipalib/plugins/internal.py | 4 ++-- >>>>> 2 files changed, 4 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json >>>>> index 0c32395ee7d68440aea0271359b0ac88fed86c42..20a462fff3b664d2320946765d1dac21ac2b1929 100644 >>>>> --- a/install/ui/test/data/ipa_init.json >>>>> +++ b/install/ui/test/data/ipa_init.json >>>>> @@ -563,8 +563,8 @@ >>>>> "next": "Next", >>>>> "page": "Page", >>>>> "prev": "Prev", >>>>> - "undo": "undo", >>>>> - "undo_all": "undo all", >>>>> + "undo": "Undo", >>>>> + "undo_all": "Undo All", >>>>> "validation": { >>>>> "error": "Text does not match field pattern", >>>>> "datetime": "Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")", >>>>> diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py >>>>> index f9ae831dc665b1282ded798023856dacec480e3b..cda9fdc7ba5237bc5bcfddbce20f47abbc210a40 100644 >>>>> --- a/ipalib/plugins/internal.py >>>>> +++ b/ipalib/plugins/internal.py >>>>> @@ -708,8 +708,8 @@ class i18n_messages(Command): >>>>> "next": _("Next"), >>>>> "page": _("Page"), >>>>> "prev": _("Prev"), >>>>> - "undo": _("undo"), >>>>> - "undo_all": _("undo all"), >>>>> + "undo": _("Undo"), >>>>> + "undo_all": _("Undo All"), >>>> >>>> Does this affect translations? The msgid "undo all" is present in >>>> the PO files. >>> >>> Yes >>> >> >> Translations are lost as a result of this change, due to case >> sensitive translation lookup by msgid. I guess our translation >> workflow takes care of this - in which case, ACK. >> >> Speaking of which, I couldn't find anything on the wiki about how we >> do our translations (i.e., how or when stuff gets pulled into/out of >> transifex, who's responsible for that part of the process). Would >> be good to find out more about it :) > > Petr Viktorin takes care of pulling the translations before the release. > However, I must admit we do not have a firm translation workflow defined yet, > we try not to mess with translations close to the release, but we do not > announce official string freeze. > > Martin > Hi, I'd rather delay pushing this until 4.0.1, as with all non-essential changes. Due to patches coming in late in the release cycle we can't release with translations for all the new features. I guess that's acceptable, but we don't need to break the string "Undo". -- Petr? From mbasti at redhat.com Wed Jul 2 08:23:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 10:23:21 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing tlsarecord in 40-dns.update In-Reply-To: <53B3B758.2060809@redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> Message-ID: <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 09:40 +0200, Petr Spacek wrote: > On 1.7.2014 17:28, Martin Basti wrote: > > Patch attached > > I'm not able to apply it on top of current master > (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). > Sorry I lost myself in ACIs, it depends on the patch mbasti-0084-2 and 0085-2 -- Martin^2 Basti From pspacek at redhat.com Wed Jul 2 08:32:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Jul 2014 10:32:41 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing tlsarecord in 40-dns.update In-Reply-To: <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3C3A9.6080200@redhat.com> On 2.7.2014 10:23, Martin Basti wrote: > On Wed, 2014-07-02 at 09:40 +0200, Petr Spacek wrote: >> On 1.7.2014 17:28, Martin Basti wrote: >>> Patch attached >> >> I'm not able to apply it on top of current master >> (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). >> > Sorry I lost myself in ACIs, it depends on the patch mbasti-0084-2 and > 0085-2 Okay, I will test it when you send new versions of 0084 and 0085. -- Petr^2 Spacek From pvoborni at redhat.com Wed Jul 2 08:49:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Jul 2014 10:49:19 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3C78F.1020701@redhat.com> On 1.7.2014 15:15, Martin Basti wrote: > On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4413 >> Patches attached > > Rebased patches attached > Besides #1, mostly minor stuff. 1. The regex r'^\d+ \d+ \d+ ([0-9a-fA-F]+|-)$' should be extended to validate even number of hex chars, e.g.: "^\d+ \d+ \d+ ((([0-9a-fA-F]{2})+)|-)$" Should be then also reflected in _nsec3param_errmsg This change will make Web UI more usable. 2. abbreviation 'alg' in 'hash_alg' is not so common as, for example, 'arg'. Full 'hash_algorithm' is more clear, there is enough space. + doc=_('NSEC3PARAM record for zone in format: hash_alg flags iterations salt'), 3. I think we should rather catch TypeError + try: + binascii.a2b_hex(salt) + except Exception, e: + return _('salt value: %(err)s') % {'err': e} 4. Extra empty line + pattern_errmsg=_nsec3param_errmsg, + + ), Unrelated: 5. IMO framework should be extended to support translations in `pattern_errmsg` -- Petr Vobornik From pviktori at redhat.com Wed Jul 2 10:49:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 12:49:14 +0200 Subject: [Freeipa-devel] [PATCH 0238] ipaldap: Override conversion of nsds5replicalastupdatestart In-Reply-To: <53B3A352.8080702@redhat.com> References: <53B2C98D.3030405@redhat.com> <53B3A352.8080702@redhat.com> Message-ID: <53B3E3AA.7090502@redhat.com> On 07/02/2014 08:14 AM, Jan Cholasta wrote: > On 1.7.2014 16:45, Tomas Babej wrote: >> Hi, >> >> The replication related attributes nsds5replicalastupdatestart and >> nsds5replicalastupdateend have special behaviour implemented in 389, >> as follows: >> >> In case they are explicitly requested for and not set, 0 is returned. >> >> However, 0 is not a valid value for LDAP Generalized time. Thus >> we need to add these attributes to the _SYNTAX_OVERRIDE dictionary, >> overriding their conversion to datetime and converting them to >> string instead, which preserves the old behaviour expected by the >> replication codebase. >> >> https://fedorahosted.org/freeipa/ticket/4350 >> >> Note: This makes patch 236 obsolete. >> Note II: This is a short-term fix from my point of view. Ticket to >> resolve the underlying issue has been filed to 389: >> >> https://fedorahosted.org/389/ticket/47836 > > It should be unicode, not str, if you want old behavior. > Since Tom?? is on vacation now, I made the change and tested it. As Rob noted in the other patch thread, this problem also appears in `ipa-replica-manage list -v `, where it's not benign as in the install case (the command aborts). The ipa-replica-manage list case will also fail on nsds5replicalastinit{start,end} conversion (note "init" instead of "update"). Updated patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0238+pviktori-ipaldap-Override-conversion-of-nsds5replicalast-upda.patch Type: text/x-patch Size: 1492 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 2 11:02:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 13:02:31 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help Message-ID: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> Patch attached. (Forward zones help preparation) -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0088-Use-documentation-addresses-in-dns-help.patch Type: text/x-patch Size: 4445 bytes Desc: not available URL: From pviktori at redhat.com Wed Jul 2 11:09:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 13:09:04 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help In-Reply-To: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> References: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3E850.3050805@redhat.com> On 07/02/2014 01:02 PM, Martin Basti wrote: > Patch attached. > (Forward zones help preparation) > /me sighs This will invalidate all translations of the DNS plugin help. Is it really necessary for 4.0? -- Petr? From mbasti at redhat.com Wed Jul 2 11:17:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 13:17:55 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <53B3B739.4040301@redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> <53B3B739.4040301@redhat.com> Message-ID: <1404299875.2172.4.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 09:39 +0200, Petr Viktorin wrote: > On 07/01/2014 03:15 PM, Martin Basti wrote: > > On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: > >> Ticket: https://fedorahosted.org/freeipa/ticket/4413 > >> Patches attached > > > > > Rebased patches attached > > > > > 0084: > in dns.py, you'll also want to remove NSEC3PARAMRecord from > _dns_records. Otherwise I still see it in API.txt for dnsrecord_add & > friends. If remove it, it breaks dns.py. I havent add NSEC3PARAMRecord into _dns_records in original patch. > 0085: > _nsec3param_errmsg will not get picked up by xgettext, so it won't be > translated. The argument to _() must be a literal string, not a variable. > > > -- Martin^2 Basti From mbasti at redhat.com Wed Jul 2 11:41:50 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 13:41:50 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <53B3C78F.1020701@redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> <53B3C78F.1020701@redhat.com> Message-ID: <1404301310.2172.5.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 10:49 +0200, Petr Vobornik wrote: > On 1.7.2014 15:15, Martin Basti wrote: > > On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: > >> Ticket: https://fedorahosted.org/freeipa/ticket/4413 > >> Patches attached > > > > Rebased patches attached > > > > Besides #1, mostly minor stuff. > > 1. The regex r'^\d+ \d+ \d+ ([0-9a-fA-F]+|-)$' should be extended to > validate even number of hex chars, e.g.: > "^\d+ \d+ \d+ ((([0-9a-fA-F]{2})+)|-)$" > > Should be then also reflected in _nsec3param_errmsg > > This change will make Web UI more usable. > > 2. abbreviation 'alg' in 'hash_alg' is not so common as, for example, > 'arg'. Full 'hash_algorithm' is more clear, there is enough space. > > + doc=_('NSEC3PARAM record for zone in format: hash_alg flags > iterations salt'), > > > 3. I think we should rather catch TypeError > > + try: > + binascii.a2b_hex(salt) > + except Exception, e: > + return _('salt value: %(err)s') % {'err': e} > > 4. Extra empty line > > + pattern_errmsg=_nsec3param_errmsg, > + > + ), > > > Unrelated: > > 5. IMO framework should be extended to support translations in > `pattern_errmsg` > Updated patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0084-3-Remove-NSEC3PARAM-record.patch Type: text/x-patch Size: 27221 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0085-3-Add-NSEC3PARAM-to-zone-settings.patch Type: text/x-patch Size: 22240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0086-3-NSEC3PARAM-tests.patch Type: text/x-patch Size: 5211 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 2 11:43:42 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 13:43:42 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help In-Reply-To: <53B3E850.3050805@redhat.com> References: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> <53B3E850.3050805@redhat.com> Message-ID: <1404301422.2172.7.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 13:09 +0200, Petr Viktorin wrote: > On 07/02/2014 01:02 PM, Martin Basti wrote: > > Patch attached. > > (Forward zones help preparation) > > > > /me sighs > > This will invalidate all translations of the DNS plugin help. > Is it really necessary for 4.0? Ask petr2, but I have ticket where I need to add some description about forward zones to help. -- Martin^2 Basti From pviktori at redhat.com Wed Jul 2 12:07:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 14:07:22 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help In-Reply-To: <1404301422.2172.7.camel@unused-4-145.brq.redhat.com> References: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> <53B3E850.3050805@redhat.com> <1404301422.2172.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53B3F5FA.7060206@redhat.com> On 07/02/2014 01:43 PM, Martin Basti wrote: > On Wed, 2014-07-02 at 13:09 +0200, Petr Viktorin wrote: >> On 07/02/2014 01:02 PM, Martin Basti wrote: >>> Patch attached. >>> (Forward zones help preparation) >>> >> >> /me sighs >> >> This will invalidate all translations of the DNS plugin help. >> Is it really necessary for 4.0? > > Ask petr2, but I have ticket where I need to add some description about > forward zones to help. > > If it's really absolutely unavoidable to change the strings at the last minute, please do it as fast as possible so translators can get a bit of time to retranslate. Whenever you touch a long docstring, please split up the text according to http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings (preferably in a separate patch). -- Petr? From mbasti at redhat.com Wed Jul 2 12:27:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 14:27:30 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <1404299875.2172.4.camel@unused-4-145.brq.redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> <53B3B739.4040301@redhat.com> <1404299875.2172.4.camel@unused-4-145.brq.redhat.com> Message-ID: <1404304050.2172.8.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 13:17 +0200, Martin Basti wrote: > On Wed, 2014-07-02 at 09:39 +0200, Petr Viktorin wrote: > > On 07/01/2014 03:15 PM, Martin Basti wrote: > > > On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: > > >> Ticket: https://fedorahosted.org/freeipa/ticket/4413 > > >> Patches attached > > > > > > > > Rebased patches attached > > > > > > > > > 0084: > > in dns.py, you'll also want to remove NSEC3PARAMRecord from > > _dns_records. Otherwise I still see it in API.txt for dnsrecord_add & > > friends. > If remove it, it breaks dns.py. I havent add NSEC3PARAMRecord into _dns_records in original patch. > > > 0085: > > _nsec3param_errmsg will not get picked up by xgettext, so it won't be > > translated. The argument to _() must be a literal string, not a variable. > > > > > > > > Updated patch attached (API.txt updated) -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0085-4-Add-NSEC3PARAM-to-zone-settings.patch Type: text/x-patch Size: 22255 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 2 12:46:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Jul 2014 14:46:01 +0200 Subject: [Freeipa-devel] [PATCH] 475 Clear NSS session cache when socket is closed Message-ID: <53B3FF09.6080604@redhat.com> Our CI tests were failing. After longer (tedious) investigation I came down to this minimal change that fixes the failures. --- Even when NSS connection is closed, there may be still cached certificates in the NSS lib. This may cause subsequent NSS initialization to crash. This problem especially reproduces in the unit tests. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-475-clear-nss-session-cache-when-socket-is-closed.patch Type: text/x-patch Size: 954 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 2 12:56:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Jul 2014 14:56:27 +0200 Subject: [Freeipa-devel] [PATCHES 0084-0086] NSEC3PARAM DNS record should be in DNS zone settings In-Reply-To: <1404304050.2172.8.camel@unused-4-145.brq.redhat.com> References: <1404217459.24263.14.camel@unused-4-145.brq.redhat.com> <1404220555.24263.16.camel@unused-4-145.brq.redhat.com> <53B3B739.4040301@redhat.com> <1404299875.2172.4.camel@unused-4-145.brq.redhat.com> <1404304050.2172.8.camel@unused-4-145.brq.redhat.com> Message-ID: <53B4017B.9030603@redhat.com> On 2.7.2014 14:27, Martin Basti wrote: > On Wed, 2014-07-02 at 13:17 +0200, Martin Basti wrote: >> On Wed, 2014-07-02 at 09:39 +0200, Petr Viktorin wrote: >>> On 07/01/2014 03:15 PM, Martin Basti wrote: >>>> On Tue, 2014-07-01 at 14:24 +0200, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4413 >>>>> Patches attached >>> >>>> >>>> Rebased patches attached >>>> >>> >>> >>> 0084: >>> in dns.py, you'll also want to remove NSEC3PARAMRecord from >>> _dns_records. Otherwise I still see it in API.txt for dnsrecord_add & >>> friends. >> If remove it, it breaks dns.py. I havent add NSEC3PARAMRecord into _dns_records in original patch. >> >>> 0085: >>> _nsec3param_errmsg will not get picked up by xgettext, so it won't be >>> translated. The argument to _() must be a literal string, not a variable. >>> >>> >>> >> >> > Updated patch attached (API.txt updated) > ACK pushed to master: * ff7b44e3b09b2e94fde66f918a6d1fb6db043d80 Remove NSEC3PARAM record * 30551a8aa30dcd39b3ae4c2fe97a163620773730 Add NSEC3PARAM to zone settings * 01b95805ab1428e10c79abf70c9bc9e2baf9de21 NSEC3PARAM tests -- Petr Vobornik From mbasti at redhat.com Wed Jul 2 12:57:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 14:57:49 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B28C3C.2050903@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> Message-ID: <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: > On 1.7.2014 12:20, Martin Kosek wrote: > > On 07/01/2014 10:55 AM, Petr Spacek wrote: > >> On 1.7.2014 10:49, Petr Viktorin wrote: > >>> On 07/01/2014 10:43 AM, Petr Spacek wrote: > >>>> On 30.6.2014 17:10, Martin Basti wrote: > >>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: > >>>>>> On 30.6.2014 14:33, Martin Basti wrote: > >>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: > >>>>>>>> Patch attached. > >>>>>> > >>>>>> It works for me. > >>>>>> > >>>>>> Please change the string little bit, I have realized that we should > >>>>>> ensure > >>>>>> that file permissions are correct: > >>>>>> > >>>>>> chown named: * > >>>>>> chmod u= * > >>>>>> > >>>>>> (the chmod part new) > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>> > >>>>> Updated patch attached > >>>> > >>>> I'm really sorry, I had to change the message once again :-) > >>>> > >>>> None of us noticed that chmod command was completely incorrect. I'm > >>>> attaching fixed patch as an apology. > >>>> > >>>> It works for me when applied to master > >>>> (50c30c8401c21d43414404bd5caa157196449e4c). > >>>> > >>>> Functional self-ACK :-) > >>>> > >>>> IMHO it can be pushed if Python-review is okay. > >>> > >>> Once again, please define new message classes in messages.py instead of just > >>> using PublicMessage with a custom string. > >>> > >>> Also, these messages will work for console output, but I'm not sure > >>> pre-wrapped text would look good in web UI. > >>> I'm not sold on the idea of giving instructions in warning messages. Would a > >>> link to some documentation be better? > >> > >> Well, the idea was to provide copy&paste instructions directly in the console, > >> not speaking about problems with URLs downstream. > >> > >> If you insist on URL ... here it is: > >> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support > >> > > > > Please use something more stable, like > > > > http://www.freeipa.org/page/DNSSEC > > > > which we would use as a gathering place for information about FreeIPA and DNSSEC. > > IMHO this particular warning should point to version-specific information. > > I'm not opposing to /page/DNSSEC idea in general but this warning should point > to very specific steps which will be valid only to very specific version of > FreeIPA. > Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch Type: text/x-patch Size: 3243 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 2 13:17:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 15:17:16 +0200 Subject: [Freeipa-devel] [PATCH 0089] Add help about forward zones Message-ID: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> Required patch: mbasti-0088 Patch attached I will split docstring after ACK -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0089-Help-for-forward-zones.patch Type: text/x-patch Size: 3975 bytes Desc: not available URL: From pspacek at redhat.com Wed Jul 2 13:21:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Jul 2014 15:21:01 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> Message-ID: <53B4073D.1050408@redhat.com> On 2.7.2014 14:57, Martin Basti wrote: > On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >> On 1.7.2014 12:20, Martin Kosek wrote: >>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>> Patch attached. >>>>>>>> >>>>>>>> It works for me. >>>>>>>> >>>>>>>> Please change the string little bit, I have realized that we should >>>>>>>> ensure >>>>>>>> that file permissions are correct: >>>>>>>> >>>>>>>> chown named: * >>>>>>>> chmod u= * >>>>>>>> >>>>>>>> (the chmod part new) >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>> >>>>>>> Updated patch attached >>>>>> >>>>>> I'm really sorry, I had to change the message once again :-) >>>>>> >>>>>> None of us noticed that chmod command was completely incorrect. I'm >>>>>> attaching fixed patch as an apology. >>>>>> >>>>>> It works for me when applied to master >>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>> >>>>>> Functional self-ACK :-) >>>>>> >>>>>> IMHO it can be pushed if Python-review is okay. >>>>> >>>>> Once again, please define new message classes in messages.py instead of just >>>>> using PublicMessage with a custom string. >>>>> >>>>> Also, these messages will work for console output, but I'm not sure >>>>> pre-wrapped text would look good in web UI. >>>>> I'm not sold on the idea of giving instructions in warning messages. Would a >>>>> link to some documentation be better? >>>> >>>> Well, the idea was to provide copy&paste instructions directly in the console, >>>> not speaking about problems with URLs downstream. >>>> >>>> If you insist on URL ... here it is: >>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>> >>> >>> Please use something more stable, like >>> >>> http://www.freeipa.org/page/DNSSEC >>> >>> which we would use as a gathering place for information about FreeIPA and DNSSEC. >> >> IMHO this particular warning should point to version-specific information. >> >> I'm not opposing to /page/DNSSEC idea in general but this warning should point >> to very specific steps which will be valid only to very specific version of >> FreeIPA. >> > > Updated patch attached I have bad news for you: Patch freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch cannot be applied on top of: current master (01b95805ab1428e10c79abf70c9bc9e2baf9de21) freeipa-mbasti-0080-Allow-to-add-non-string-values-to-named-conf.patch freeipa-mbasti-0081-DNSSEC-Add-experimental-support-for-DNSSEC.patch freeipa-mbasti-0082-Add-warning-about-semantic-change-for-zones.patch -- Petr^2 Spacek From mbasti at redhat.com Wed Jul 2 13:34:06 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 15:34:06 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B4073D.1050408@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> <53B4073D.1050408@redhat.com> Message-ID: <1404308046.2172.13.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 15:21 +0200, Petr Spacek wrote: > On 2.7.2014 14:57, Martin Basti wrote: > > On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: > >> On 1.7.2014 12:20, Martin Kosek wrote: > >>> On 07/01/2014 10:55 AM, Petr Spacek wrote: > >>>> On 1.7.2014 10:49, Petr Viktorin wrote: > >>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: > >>>>>> On 30.6.2014 17:10, Martin Basti wrote: > >>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: > >>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: > >>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: > >>>>>>>>>> Patch attached. > >>>>>>>> > >>>>>>>> It works for me. > >>>>>>>> > >>>>>>>> Please change the string little bit, I have realized that we should > >>>>>>>> ensure > >>>>>>>> that file permissions are correct: > >>>>>>>> > >>>>>>>> chown named: * > >>>>>>>> chmod u= * > >>>>>>>> > >>>>>>>> (the chmod part new) > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> > >>>>>>> > >>>>>>> Updated patch attached > >>>>>> > >>>>>> I'm really sorry, I had to change the message once again :-) > >>>>>> > >>>>>> None of us noticed that chmod command was completely incorrect. I'm > >>>>>> attaching fixed patch as an apology. > >>>>>> > >>>>>> It works for me when applied to master > >>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). > >>>>>> > >>>>>> Functional self-ACK :-) > >>>>>> > >>>>>> IMHO it can be pushed if Python-review is okay. > >>>>> > >>>>> Once again, please define new message classes in messages.py instead of just > >>>>> using PublicMessage with a custom string. > >>>>> > >>>>> Also, these messages will work for console output, but I'm not sure > >>>>> pre-wrapped text would look good in web UI. > >>>>> I'm not sold on the idea of giving instructions in warning messages. Would a > >>>>> link to some documentation be better? > >>>> > >>>> Well, the idea was to provide copy&paste instructions directly in the console, > >>>> not speaking about problems with URLs downstream. > >>>> > >>>> If you insist on URL ... here it is: > >>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support > >>>> > >>> > >>> Please use something more stable, like > >>> > >>> http://www.freeipa.org/page/DNSSEC > >>> > >>> which we would use as a gathering place for information about FreeIPA and DNSSEC. > >> > >> IMHO this particular warning should point to version-specific information. > >> > >> I'm not opposing to /page/DNSSEC idea in general but this warning should point > >> to very specific steps which will be valid only to very specific version of > >> FreeIPA. > >> > > > > Updated patch attached > > I have bad news for you: Patch > freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch > > cannot be applied on top of: > > current master (01b95805ab1428e10c79abf70c9bc9e2baf9de21) > freeipa-mbasti-0080-Allow-to-add-non-string-values-to-named-conf.patch > freeipa-mbasti-0081-DNSSEC-Add-experimental-support-for-DNSSEC.patch > freeipa-mbasti-0082-Add-warning-about-semantic-change-for-zones.patch > You need 0082-2 -- Martin^2 Basti From pspacek at redhat.com Wed Jul 2 13:46:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Jul 2014 15:46:28 +0200 Subject: [Freeipa-devel] [PATCH 0089] Add help about forward zones In-Reply-To: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> References: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> Message-ID: <53B40D34.8070508@redhat.com> I have only few nitpicks I didn't notice in the first round: The original proposal contained also this header: SUPPORTED ZONE TYPES * Master zone (dnszone-*) contains authoritative data. * Forward zone (dnsforwardzone-*) forwards queries to configured forwarders (a set of DNS servers). I can't see it in the patch. Rest of nit picks is in-line: On 2.7.2014 15:17, Martin Basti wrote: > - If global forwarder is configured, all requests to sub.example.com will be > - routed through the global forwarder. To change the behavior for example.com > - zone only and forward the request directly to ns.sub.example.com., global > - forwarding may be disabled per-zone: > + If a global forwarder is configured, all queries for which this server is not > + authoritative (e.g. sub.example.com) will be routed to the global forwarder. > + Global forwarding configuration can be overriden per-zone. To change behavior > + for a particular zone you can specify forwarders and forward-policy per zone. overriden => overridden (according to my spell checker :-) Sentence "To change behavior for a particular zone you can specify forwarders and forward-policy per zone." seems redundant to me. > + Semantics of forwarding in IPA matches BIND sematics and depends on type > + of the zone: > + * Master zone: local BIND replies authoritatively to queries for data in > + the given zone (including authoritative NXDOMAIN answers) and forwarding > + affects only queries for names bellow zone cuts (NS records) of locally > + served zones. > + > + * Forward zone: forward zone contains no authoritative data. BIND forwards > + queries, which cannot be answered from its local cache, to configured > + forwarders. > + > + Semantics of the --forwarder-policy option: > + * none - disable forwarding for the given zone. > + * first - forward all queries to configured forwarders. If they fail, " " should be replaced by " " > + do resolution using DNS root servers. > + * only - forward all queries to configured forwarders and if they fail, > + return failure. > + > + Disable global forwarding for given sub-tree: > ipa dnszone-mod example.com --forward-policy=none > > - Forward all requests for the zone external.com to another nameserver using > - a "first" policy (it will send the queries to the selected forwarder and if > - not answered it will use global resolvers): > - ipa dnszone-add external.com > - ipa dnszone-mod external.com --forwarder=203.0.113.1 \\ > - --forward-policy=first > + This configuration forwards all queries for names outside the example.com > + sub-tree to global forwarders. Normal recursive resolution process is used > + for names inside the example.com sub-tree (i.e. NS records are followed etc.). > + > + Forward all requests for the zone external.example.com to another nameserver nameserver => forwarder (to keep terminology consistent) > + using a "first" policy (it will send the queries to the selected forwarder > + and if not answered it will use global resolvers): resolvers => root servers > + ipa dnsforwardzone-add external.example.com --forward-policy=first \\ > + --forwarder=203.0.113.1 > + > + Change forward-policy for external.example.com: > + ipa dnsforwardzone-mod external.example.com --forward-policy=only > + > + Show forward zone external.example.com: > + ipa dnsforwardzone-show external.example.com > + > + List all forward zones: > + ipa dnsforwardzone-find > + > + Delelete forward zone external.example.com: Delelete => Delete (nice typo! :-)) > + ipa dnsforwardzone-del external.example.com > > Delete zone example.com with all resource records: > ipa dnszone-del example.com Is there section with examples for master zones? Please move it there if the answer is yes, otherwise it can stay here. -- Petr^2 Spacek From abokovoy at redhat.com Wed Jul 2 13:52:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 2 Jul 2014 16:52:31 +0300 Subject: [Freeipa-devel] [PATCH] 0153 ipa-ldap-updater does not work with hardened LDAP configuration Message-ID: <20140702135231.GM13108@redhat.com> When nsslapd-minssf is greater than 0, running as root ipa-ldap-updater [-l] will fail even if we force use of autobind for root over LDAPI. The reason for this is that schema updater doesn't get ldapi flag passed and attempts to connect to LDAP port instead and for hardened configurations using simple bind over LDAP is not enough. Additionally, report properly previously unhandled LDAP exceptions. https://fedorahosted.org/freeipa/ticket/3468 Note that the ticket is in 'Future releases' but we have this bug in 3.3 and in my view it is serious enough to fix it. -- / Alexander Bokovoy -------------- next part -------------- >From 03c9f67bf7855a9507a9ccf219a3bfeb9bb3ad1f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 2 Jul 2014 16:30:18 +0300 Subject: [PATCH] ipa-ldap-updater: make possible to use LDAPI with autobind in case of hardened LDAP configuration When nsslapd-minssf is greater than 0, running as root ipa-ldap-updater [-l] will fail even if we force use of autobind for root over LDAPI. The reason for this is that schema updater doesn't get ldapi flag passed and attempts to connect to LDAP port instead and for hardened configurations using simple bind over LDAP is not enough. Additionally, report properly previously unhandled LDAP exceptions. https://fedorahosted.org/freeipa/ticket/3468 --- ipapython/ipaldap.py | 4 ++++ ipaserver/install/ipa_ldap_updater.py | 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/ipapython/ipaldap.py b/ipapython/ipaldap.py index 21706cf..c5bd08b 100644 --- a/ipapython/ipaldap.py +++ b/ipapython/ipaldap.py @@ -1200,6 +1200,10 @@ class LDAPClient(object): pass except ldap.CONNECT_ERROR: raise errors.DatabaseError(desc=desc, info=info) + except ldap.UNWILLING_TO_PERFORM: + raise errors.DatabaseError(desc=desc, info=info) + except ldap.AUTH_UNKNOWN: + raise errors.ACIError(info='%s (%s)' % (info,desc)) except ldap.LDAPError, e: if 'NOT_ALLOWED_TO_DELEGATE' in info: raise errors.ACIError( diff --git a/ipaserver/install/ipa_ldap_updater.py b/ipaserver/install/ipa_ldap_updater.py index fbbef14..18970ce 100644 --- a/ipaserver/install/ipa_ldap_updater.py +++ b/ipaserver/install/ipa_ldap_updater.py @@ -204,7 +204,8 @@ class LDAPUpdater_NonUpgrade(LDAPUpdater): modified = schemaupdate.update_schema( options.schema_files, dm_password=self.dirman_password, - live_run=not options.test) or modified + live_run=not options.test, + ldapi=options.ldapi) or modified if not self.files: self.files = ld.get_all_files(UPDATES_DIR) -- 1.9.3 From mbasti at redhat.com Wed Jul 2 14:04:00 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 16:04:00 +0200 Subject: [Freeipa-devel] [PATCH 0089] Add help about forward zones In-Reply-To: <53B40D34.8070508@redhat.com> References: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> <53B40D34.8070508@redhat.com> Message-ID: <1404309840.2172.15.camel@unused-4-145.brq.redhat.com> On Wed, 2014-07-02 at 15:46 +0200, Petr Spacek wrote: > I have only few nitpicks I didn't notice in the first round: > > The original proposal contained also this header: > SUPPORTED ZONE TYPES > * Master zone (dnszone-*) contains authoritative data. > * Forward zone (dnsforwardzone-*) forwards queries to configured forwarders > (a set of DNS servers). > > I can't see it in the patch. > It is there > > Delete zone example.com with all resource records: > > ipa dnszone-del example.com > Is there section with examples for master zones? Please move it there if the > answer is yes, otherwise it can stay here. > Moved Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0089-2-Help-for-forward-zones.patch Type: text/x-patch Size: 4070 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 2 14:10:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Jul 2014 16:10:13 +0200 Subject: [Freeipa-devel] [PATCH 0238] ipaldap: Override conversion of nsds5replicalastupdatestart In-Reply-To: <53B3A352.8080702@redhat.com> References: <53B2C98D.3030405@redhat.com> <53B3A352.8080702@redhat.com> Message-ID: <53B412C5.7030601@redhat.com> On 07/02/2014 08:14 AM, Jan Cholasta wrote: > On 1.7.2014 16:45, Tomas Babej wrote: >> Hi, >> >> The replication related attributes nsds5replicalastupdatestart and >> nsds5replicalastupdateend have special behaviour implemented in 389, >> as follows: >> >> In case they are explicitly requested for and not set, 0 is returned. >> >> However, 0 is not a valid value for LDAP Generalized time. Thus >> we need to add these attributes to the _SYNTAX_OVERRIDE dictionary, >> overriding their conversion to datetime and converting them to >> string instead, which preserves the old behaviour expected by the >> replication codebase. >> >> https://fedorahosted.org/freeipa/ticket/4350 >> >> Note: This makes patch 236 obsolete. >> Note II: This is a short-term fix from my point of view. Ticket to >> resolve the underlying issue has been filed to 389: >> >> https://fedorahosted.org/389/ticket/47836 > > It should be unicode, not str, if you want old behavior. > Given that Tomas is away and we want this in 4.0, I revisited the patch add fixed the conversion + added 2 more date attributes which would cause issues with "ipa-replica-manage HOST -v". Now it works: # ipa-replica-manage list server.example.com -v vm-086.idm.lab.bos.redhat.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: None # ipa-replica-manage list -v replica.example.com vm-111.idm.lab.bos.redhat.com: replica last init status: 0 Total update succeeded last init ended: 2014-07-02 13:42:12+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-07-02 14:02:03+00:00 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-476-ipaldap-override-conversion-replication-agreement-va.patch Type: text/x-patch Size: 1507 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 2 14:14:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Jul 2014 16:14:13 +0200 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure Message-ID: <53B413B5.7050503@redhat.com> https://fedorahosted.org/freeipa/ticket/4418 according to latest proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0694-webui-new-navigation-structure.patch Type: text/x-patch Size: 17495 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 2 14:14:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Jul 2014 16:14:21 +0200 Subject: [Freeipa-devel] [PATCH 0238] ipaldap: Override conversion of nsds5replicalastupdatestart In-Reply-To: <53B3E3AA.7090502@redhat.com> References: <53B2C98D.3030405@redhat.com> <53B3A352.8080702@redhat.com> <53B3E3AA.7090502@redhat.com> Message-ID: <53B413BD.4090307@redhat.com> On 07/02/2014 12:49 PM, Petr Viktorin wrote: > On 07/02/2014 08:14 AM, Jan Cholasta wrote: >> On 1.7.2014 16:45, Tomas Babej wrote: >>> Hi, >>> >>> The replication related attributes nsds5replicalastupdatestart and >>> nsds5replicalastupdateend have special behaviour implemented in 389, >>> as follows: >>> >>> In case they are explicitly requested for and not set, 0 is returned. >>> >>> However, 0 is not a valid value for LDAP Generalized time. Thus >>> we need to add these attributes to the _SYNTAX_OVERRIDE dictionary, >>> overriding their conversion to datetime and converting them to >>> string instead, which preserves the old behaviour expected by the >>> replication codebase. >>> >>> https://fedorahosted.org/freeipa/ticket/4350 >>> >>> Note: This makes patch 236 obsolete. >>> Note II: This is a short-term fix from my point of view. Ticket to >>> resolve the underlying issue has been filed to 389: >>> >>> https://fedorahosted.org/389/ticket/47836 >> >> It should be unicode, not str, if you want old behavior. >> > > Since Tom?? is on vacation now, I made the change and tested it. > > As Rob noted in the other patch thread, this problem also appears in > `ipa-replica-manage list -v `, where it's not benign as in the install > case (the command aborts). > The ipa-replica-manage list case will also fail on > nsds5replicalastinit{start,end} conversion (note "init" instead of "update"). > > Updated patch attached. Ah, I see you sent the same patch as I did :-) In that case, it is an ACK, obviously. Pushed to master: a5bb758978ffdccc5a985487d57856290428abf1 Martin From mbasti at redhat.com Wed Jul 2 14:17:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Jul 2014 16:17:43 +0200 Subject: [Freeipa-devel] [PATCH 0090] Split dns.py doctring Message-ID: <1404310663.2172.17.camel@unused-4-145.brq.redhat.com> Required patches mbasti-0088, mbasti-0089-2 Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0090-Split-dns-docstring.patch Type: text/x-patch Size: 9885 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 2 14:20:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Jul 2014 16:20:08 +0200 Subject: [Freeipa-devel] [PATCH] 0589 Do not fail if there are multiple nsDS5ReplicaId values in cn=replication, cn=etc In-Reply-To: <53A17656.4020401@redhat.com> References: <53A17656.4020401@redhat.com> Message-ID: <53B41518.7090408@redhat.com> On 06/18/2014 01:21 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4375 Yup, works like a charm, ACK. Pushed to master: 8c98561c209d0ccaa692a335e3e9a10aec23ee0e Martin From pviktori at redhat.com Wed Jul 2 14:32:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 16:32:25 +0200 Subject: [Freeipa-devel] [PATCH] 475 Clear NSS session cache when socket is closed In-Reply-To: <53B3FF09.6080604@redhat.com> References: <53B3FF09.6080604@redhat.com> Message-ID: <53B417F9.4050002@redhat.com> On 07/02/2014 02:46 PM, Martin Kosek wrote: > Our CI tests were failing. After longer (tedious) investigation I came down to > this minimal change that fixes the failures. > > --- > Even when NSS connection is closed, there may be still cached > certificates in the NSS lib. This may cause subsequent NSS > initialization to crash. This problem especially reproduces in the > unit tests. > Kudos for figuring this one out. This fixes most the failing tests. I tested replication and client enrollment, those still work. ACK, pushed to master: c4b63dc48a4ab6d4a9b7e824dba23a806fd6d741 -- Petr? From jcholast at redhat.com Wed Jul 2 15:59:58 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 02 Jul 2014 17:59:58 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B1A017.4080802@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> Message-ID: <53B42C7E.9040808@redhat.com> On 28.6.2014 00:19, Rob Crittenden wrote: > > I'm going to consolidate all reviews for 241 - 303 here. I'm not doing > this in any particular order. OK, I will send further patches only in this thread. > > -------- > > Missing man page for ipa-certupdate I did not want to delay the patch, so I have sent it without man page. Will fix. > > -------- > > Not a very nice error from ipa-cacert-manage install when loading a bad > cert: > > # ipa-cacert-manage install /etc/group > Installing CA certificate, please wait > (SEC_ERROR_INVALID_ARGS) security library: invalid arguments. Right. Fixed. > > The ipa-cacert-manage makes no mention of changing the cert chaining. It > just adds the options, not what they do. Here is what happened when I > tried it: > > # ipa-cacert-manage renew --external-ca > Exporting CA certificate signing request, please wait > The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run > ipa-cacert-manage as: > ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate > --external-ca-file=/path/to/external_ca_certificate > The ipa-cacert-manage command was successful > [ go off and sign it ] > # ipa-cacert-manage renew --external-cert-file=/home/rcrit/ca_db/ipa.crt > --external-ca-file=/home/rcrit/ca_db/ca.crt > Importing the renewed CA certificate, please wait > Resubmitting certmonger request '20140627134654' timed out, please check > the request manually > > The request was actually in MONITORING, so ok. > > But the CA is now not working > > # ipa cert-request --principal test/`hostname` csr > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Internal Server Error) > > # ipa cert-show 1 > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Internal Server Error) > > The CA database doesn't have my external CA > > # certutil -Ld /etc/pki/pki-tomcat/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > caSigningCert cert-pki-ca CTu,Cu,Cu > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-ca u,u,u > > Not sure if this is related: > # pki cert-find > PKIException: Internal Server Error The problem is not in the missing external CA cert (the CA always worked fine without it for me, so I never bothered adding it). The problem is that Dogtag can't connect to DS, because it does not like its server certificate. Which is weird, because when I try doing the same using ldapsearch everything seems to work fine: # LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://$HOSTNAME -Y EXTERNAL -b o=ipaca -s base Please enter pin, password, or pass phrase for security token 'ldap(0)': SASL/EXTERNAL authentication started SASL username: cn=CA Subsystem,o=EXAMPLE.COM SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: ALL # # ipaca dn: o=ipaca objectClass: top objectClass: organization o: ipaca # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 Adding the old CA cert back to /etc/pki/pki-tomcat/alias does not fix this, although the error is different (ipa cert-show fails with internal error caused by "XMLSyntaxError: None", pki cert-find fails with "PKIException: Error searching certs in CertService.searchCerts!"). Adding the external CA cert does not fix this either. I'm pretty sure chaining change from self-signed to signed by external CA worked for me the last time I have tested it, but it has been some time. Maybe something changed in Dogtag? I don't know. Any ideas? > > -------- > > Note that I tried again with a fresh external install, this time without > the --external-ca flag and it basically went through the same steps but > this time it was successful. Good. > > -------- > > I did a re-install and tried a renewal (with just ipa-server-install). I > moved time forward and saw this: > > Request ID '20140627150913': > status: MONITORING > ca-error: Server at > "https://sif.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: > Invalid Credential. > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin='323234924210' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=GREYOAK.COM > subject: CN=CA Audit,O=GREYOAK.COM > expires: 2016-06-16 15:08:34 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > How it is monitoring with a ca-error I don't know. > > I forced a resubmit and it renewed ok. Chances are certmonger would have > taken care of this automatically. > > I leaped forward 2 more times and had to restart certmonger a few times > to kick things but again, it did eventually renew as expected. > > So that looks ok and covers much of the first patch set. OK, thanks. > > --------------- > > ipa-client-install still fails for me in RHEL-5 with an external CA: > > 2014-06-27 14:04:31,202 DEBUG trying to retrieve CA cert via LDAP from > ldap://sif.greyoak.com > 2014-06-27 14:04:32,312 INFO Successfully retrieved CA cert > Subject: /O=GREYOAK.COM/CN=Certificate Authority > Issuer: /CN=External Authority > > 2014-06-27 14:04:32,467 DEBUG args=/usr/sbin/ipa-join -s sif.greyoak.com > -b dc=greyoak,dc=com > 2014-06-27 14:04:32,467 DEBUG stdout= > 2014-06-27 14:04:32,467 DEBUG stderr=libcurl failed to execute the HTTP > POST transaction. SSL certificate problem, verify that the CA cert is > OK. Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify failed > > This is the query that is being done: > > [27/Jun/2014:14:04:31 -0400] conn=18 op=3 SRCH > base="CN=CAcert,CN=ipa,CN=etc,dc=greyoak,dc=com" scope=0 > filter="(objectClass=pkiCA)" attrs="cacertificate;binary" > > It returns a single object, the dogtag-issued CA certificate, not the > entire chain, hence the failure. I doubt this ever worked, as there can be only one certificate in cn=CAcert. Can't do much about this, unless you want to fix it in RHEL 5. > > Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while > /usr/share/ipa/html/ca.crt contains the full chain. Right, will fix. > > This works: > # wget -O /tmp/ca.crt http://sif.greyoak.com/ipa/config/ca.crt > # ipa-client-install --server=sif.greyoak.com --domain=greyoak.com -p > admin -w password -U --ca-cert-file=/tmp/ca.crt > > -------- > > Enrollment on RHEL-6 also puts a single CA in /etc/ipa/ca.crt but > enrollment succeeds. That's expected, it also uses cn=CAcert. Any idea why it works on RHEL 6 but not on RHEL 5? > > Enrollment on F-20 puts all certs into /etc/ipa/ca.crt. My last test was > re-freshing the CA cert from an external and I confirmed that both the > IPA CA certs are in /etc/ipa/ca.crt and in LDAP. > > -------- > > Ok, so I took my working, renewed Externally-issued CA install and > generated a PKCS#12 for another host. Using that I did a CA-less install. > > I tried ipa-ca-install on that and it failed. The log is attached, > though it shouldn't be called ipareplica-ca-install.log in this case. There are conflicting certificates with the same nickname in the PKCS#12 file and the certificate store, which causes the error. Will fix. > > -------- > > Installing a replica and adding a CA to it using ipa-replica-ca-install > worked fine. > > -------- > > I renewed the CA once again using ipa-cacert-manage then used > ipa-certupdate to apply the result successfully on the replica except > for the CA itself. It is still has the serial number it was installed > with and not the updated value in caSigningCert cert-pki-ca. Right, fixed. > > -------- > > Patch 293 > > Just curious, but what is the advantage of writing out the certificates > in pk11-kit format when you can drop the cert(s) and call > update-ca-trust? Is it a control thing, particularly for the > trusted/untrusted? Yes, I can add the out-of-band trust policy as well as nicknames to the certificates this way. Also, it is easier to manage one file rather than a bunch of them. > > Patch 294 > > I think the git commit should include the bit about using the CA file > from the replica config as well. OK. > > Patch 303. > > Is the context as cli_installer a cut-n-paste or a conscious choice? It is indeed copy-paste. Is it wrong? > > Should there be some logging in here? What happens if the kinit fails, > or something else goes bump? There is no debug/verbose output option to > see what is going on. This is all handled by admintool, including an option for verbose output (-v). > > In update_client() should it be paranoid enough to have a try/except > around the reads and writes? Sure, why not. > > I'm assuming that the certutil call in update_db() is because the other > cert management we have is in ipaserver, right? Perhaps certs.py needs > to be moved to ipapython (and maybe renamed)? A patch for another day if > you agree and please file a ticket. I agree: . > > I still need to do more chain-updating and upgrade testing. > > rob > > On 30.6.2014 19:36, Rob Crittenden wrote: > A few more things after more testing. > > If one renews an externally-issued CA then you can end up with multiple > certs for the IPA CA in /etc/pki/nssdb (for each issued cert). These do > not seem to be cleaned up on uninstall. Right, you need to call "certutil -D" multiple times if there are multiple certs with the same nick. Fixed. > > On upgrade from 3.3.5 seeing: > Unexpected error - see /var/log/ipaupgrade.log for details: > InvalidSyntax: object class ipaCertificate: Unknown required attribute > type "ipaPublicKey": Invalid syntax. > > /var/log/ipaupgrade ends with: > > 2014-06-30T15:03:11Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > 2014-06-30T15:08:12Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 640, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-upgradeconfig", line 1171, in main > ds.start(ds_serverid) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 297, in start > self.service.start(instance_name, capture_output=capture_output, > wait=wait) > > File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", > line 262, in start > self.wait_for_open_ports(self.service_instance(instance_name)) > > File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", > line 228, in wait_for_open_ports > self.api.env.startup_timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line > 1153, in wait_for_open_ports > raise socket.timeout() > > 2014-06-30T15:08:12Z DEBUG The ipa-upgradeconfig command failed, > exception: timeout: > > Turns out it blew up so badly that it didn't restore dse.ldif when the > upgrade finished, something I thought was impossible. This is a pretty > serious problem in itself (and likely unrelated to these patches). This might be related to the fact that I accidentally left an unresolved merge conflict in 60basev3.ldif. Fixed. > > rob > -- Jan Cholasta From pviktori at redhat.com Wed Jul 2 16:20:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 18:20:38 +0200 Subject: [Freeipa-devel] [PATCH] test_ipaserver: Add OTP token test data to ipatests package Message-ID: <53B43156.1040300@redhat.com> Hello, Some data is not put in the ipatests package. This prevents OTP token import tests from passing when run out of tree. Fix included. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0613-test_ipaserver-Add-OTP-token-test-data-to-ipatests-p.patch Type: text/x-patch Size: 1595 bytes Desc: not available URL: From pspacek at redhat.com Wed Jul 2 16:25:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Jul 2014 18:25:33 +0200 Subject: [Freeipa-devel] [PATCHES 0080-0081] DNSSEC: Add experimental support for DNSSEC In-Reply-To: <1403881861.2249.20.camel@unused-4-145.brq.redhat.com> References: <1403881861.2249.20.camel@unused-4-145.brq.redhat.com> Message-ID: <53B4327D.5020004@redhat.com> On 27.6.2014 17:11, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4408 > Patches attached. Both patches works for me. I have tested clean installation and upgrade from 3.3.5. -- Petr^2 Spacek From pviktori at redhat.com Wed Jul 2 16:32:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 18:32:54 +0200 Subject: [Freeipa-devel] [PATCH] 0614 test_ipagetkeytab: Fix expected error message Message-ID: <53B43436.8060608@redhat.com> It looks like ipa-getkeytab error message for a non-existent service changed. Simo, is this expected? Is the new message final, or should we just check for the "PrincipalName not found." substring? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0614-test_ipagetkeytab-Fix-expected-error-message.patch Type: text/x-patch Size: 1073 bytes Desc: not available URL: From pviktori at redhat.com Wed Jul 2 16:44:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Jul 2014 18:44:06 +0200 Subject: [Freeipa-devel] [PATCHES 0080-0081] DNSSEC: Add experimental support for DNSSEC In-Reply-To: <53B4327D.5020004@redhat.com> References: <1403881861.2249.20.camel@unused-4-145.brq.redhat.com> <53B4327D.5020004@redhat.com> Message-ID: <53B436D6.3090908@redhat.com> On 07/02/2014 06:25 PM, Petr Spacek wrote: > On 27.6.2014 17:11, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4408 >> Patches attached. > > Both patches works for me. I have tested clean installation and upgrade > from 3.3.5. > Code looks okay, pushed to master: 3b310d6b4f8063149d1abe823b64bc9796a97ab2 Is this all for the ticket? Can we close it? -- Petr? From rcritten at redhat.com Wed Jul 2 17:08:37 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jul 2014 13:08:37 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B42C7E.9040808@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> Message-ID: <53B43C95.1080907@redhat.com> Jan Cholasta wrote: > On 28.6.2014 00:19, Rob Crittenden wrote: >> >> I'm going to consolidate all reviews for 241 - 303 here. I'm not doing >> this in any particular order. Trimming to respond to your questions. >> Not sure if this is related: >> # pki cert-find >> PKIException: Internal Server Error I'm pretty sure the cert-find error is related to the fact that I had a test build of dogtag installed, so that can be ignored. >> ipa-client-install still fails for me in RHEL-5 with an external CA: >> >> 2014-06-27 14:04:31,202 DEBUG trying to retrieve CA cert via LDAP from >> ldap://sif.greyoak.com >> 2014-06-27 14:04:32,312 INFO Successfully retrieved CA cert >> Subject: /O=GREYOAK.COM/CN=Certificate Authority >> Issuer: /CN=External Authority >> >> 2014-06-27 14:04:32,467 DEBUG args=/usr/sbin/ipa-join -s sif.greyoak.com >> -b dc=greyoak,dc=com >> 2014-06-27 14:04:32,467 DEBUG stdout= >> 2014-06-27 14:04:32,467 DEBUG stderr=libcurl failed to execute the HTTP >> POST transaction. SSL certificate problem, verify that the CA cert is >> OK. Details: >> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >> verify failed >> >> This is the query that is being done: >> >> [27/Jun/2014:14:04:31 -0400] conn=18 op=3 SRCH >> base="CN=CAcert,CN=ipa,CN=etc,dc=greyoak,dc=com" scope=0 >> filter="(objectClass=pkiCA)" attrs="cacertificate;binary" >> >> It returns a single object, the dogtag-issued CA certificate, not the >> entire chain, hence the failure. > > I doubt this ever worked, as there can be only one certificate in > cn=CAcert. Can't do much about this, unless you want to fix it in RHEL 5. Ok, as it is not a regression I won't let that block these patches. >> Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while >> /usr/share/ipa/html/ca.crt contains the full chain. > > Right, will fix. > >> >> This works: >> # wget -O /tmp/ca.crt http://sif.greyoak.com/ipa/config/ca.crt >> # ipa-client-install --server=sif.greyoak.com --domain=greyoak.com -p >> admin -w password -U --ca-cert-file=/tmp/ca.crt >> >> -------- >> >> Enrollment on RHEL-6 also puts a single CA in /etc/ipa/ca.crt but >> enrollment succeeds. > > That's expected, it also uses cn=CAcert. Any idea why it works on RHEL 6 > but not on RHEL 5? I'd guess it has something to do with OpenSSL vs NSS. >> Patch 303. >> >> Is the context as cli_installer a cut-n-paste or a conscious choice? > > It is indeed copy-paste. Is it wrong? The context is completely arbitrary and rarely used. But it is used in a few places, though IIRC mostly on the server side. It probably doesn't matter much but being client-specific is good future-proofing. rob From jcholast at redhat.com Wed Jul 2 17:37:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 02 Jul 2014 19:37:26 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B43C95.1080907@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> Message-ID: <53B44356.2040004@redhat.com> On 2.7.2014 19:08, Rob Crittenden wrote: > Trimming to respond to your questions. >>> Not sure if this is related: >>> # pki cert-find >>> PKIException: Internal Server Error > > I'm pretty sure the cert-find error is related to the fact that I had a > test build of dogtag installed, so that can be ignored. It does not work for me as well, with the current F20 dogtag packages, but like I said, it worked some time ago. >>> Patch 303. >>> >>> Is the context as cli_installer a cut-n-paste or a conscious choice? >> >> It is indeed copy-paste. Is it wrong? > > The context is completely arbitrary and rarely used. But it is used in a > few places, though IIRC mostly on the server side. It probably doesn't > matter much but being client-specific is good future-proofing. OK, thought this was something more serious :-) I copied the context from ipa-client-automount, since ipa-certupdate is also client-side installer-like command. > > > rob > -- Jan Cholasta From ftweedal at redhat.com Thu Jul 3 06:13:17 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 3 Jul 2014 16:13:17 +1000 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure In-Reply-To: <53B413B5.7050503@redhat.com> References: <53B413B5.7050503@redhat.com> Message-ID: <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> On Wed, Jul 02, 2014 at 04:14:13PM +0200, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/4418 > > according to latest > proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html > -- > Petr Vobornik Haven't run the webui tests but lines up with the proposal and looks very nice! ACK if webui tests pass. > From 97cc94163e8ae57058b07741c7d70e44697c113f Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Wed, 2 Jul 2014 15:09:22 +0200 > Subject: [PATCH] webui: new navigation structure > > https://fedorahosted.org/freeipa/ticket/4418 > --- > install/ui/src/freeipa/certificate.js | 2 +- > install/ui/src/freeipa/dns.js | 2 +- > install/ui/src/freeipa/navigation/menu_spec.js | 195 +++++++++++++++---------- > install/ui/test/data/ipa_init.json | 2 + > ipalib/plugins/internal.py | 2 + > ipatests/test_webui/test_navigation.py | 62 +++++--- > ipatests/test_webui/ui_driver.py | 2 +- > 7 files changed, 160 insertions(+), 107 deletions(-) > > diff --git a/install/ui/src/freeipa/certificate.js b/install/ui/src/freeipa/certificate.js > index 01dfee2b64c14f487b66b91d449f63b6415dea69..6a11d959398517db6f720a36ff2a323e1d0c74a7 100755 > --- a/install/ui/src/freeipa/certificate.js > +++ b/install/ui/src/freeipa/certificate.js > @@ -1293,7 +1293,7 @@ IPA.cert.cert_update_policy = function(spec) { > > exp.remove_menu_item = function() { > if (!IPA.cert.is_enabled()) { > - menu.remove_item('identity/cert'); > + menu.remove_item('authentication/cert'); > } > }; > > diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js > index c7143ca91fef9bbc372654080fe899be1ae8367f..a566ccf61adcf4f688ac803bf5e3658b4f3a0253 100644 > --- a/install/ui/src/freeipa/dns.js > +++ b/install/ui/src/freeipa/dns.js > @@ -2543,7 +2543,7 @@ IPA.network_validator = function(spec) { > > exp.remove_menu_item = function() { > if (!IPA.dns_enabled) { > - menu.remove_item('identity/dns'); > + menu.remove_item('network_services/dns'); > } > }; > > diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js > index 01738cbe60b10bc0f1671093fc1616980780bac1..9182d11bf56c73e1fce724d438fe2211105b75ad 100644 > --- a/install/ui/src/freeipa/navigation/menu_spec.js > +++ b/install/ui/src/freeipa/navigation/menu_spec.js > @@ -43,101 +43,134 @@ var nav = {}; > { entity: 'netgroup' }, > { entity: 'service' }, > { > + name: 'automember', > + label: '@i18n:tabs.automember', > + children: [ > + { > + name: 'amgroup', > + entity: 'automember', > + facet: 'searchgroup', > + label: '@i18n:objects.automember.usergrouprules', > + children: [ > + { > + entity: 'automember', > + facet: 'usergrouprule', > + hidden: true > + } > + ] > + }, > + { > + name: 'amhostgroup', > + entity: 'automember', > + facet: 'searchhostgroup', > + label: '@i18n:objects.automember.hostgrouprules', > + children: [ > + { > + entity: 'automember', > + facet: 'hostgrouprule', > + hidden: true > + } > + ] > + } > + ] > + } > + ] > + }, > + { > + name: 'policy', > + label: '@i18n:tabs.policy', > + children: [ > + { > + name: 'hbac', > + label: '@i18n:tabs.hbac', > + children: [ > + { entity: 'hbacrule' }, > + { entity: 'hbacsvc' }, > + { entity: 'hbacsvcgroup' }, > + { entity: 'hbactest' } > + ] > + }, > + { > + name: 'sudo', > + label: '@i18n:tabs.sudo', > + children: [ > + { entity: 'sudorule' }, > + { entity: 'sudocmd' }, > + { entity: 'sudocmdgroup' } > + ] > + }, > + { entity: 'selinuxusermap' }, > + { entity: 'pwpolicy' }, > + { entity: 'krbtpolicy' } > + ] > + }, > + { > + name: 'authentication', > + label: '@i18n:tabs.authentication', > + children: [ > + { entity: 'cert', label: '@i18n:tabs.cert' }, > + { entity: 'otptoken' }, > + { entity: 'radiusproxy' } > + ] > + }, > + { > + name: 'network_services', > + label: '@i18n:tabs.network_services', > + children: [ > + { > + name:'automount', > + label: '@i18n:tabs.automount', > + entity: 'automountlocation', > + children: [ > + { entity: 'automountlocation', hidden: true }, > + { entity: 'automountmap', hidden: true }, > + { entity: 'automountkey', hidden: true } > + ] > + }, > + { > name:'dns', > label: '@i18n:tabs.dns', > children: [ > { > entity: 'dnszone', > children: [ > - { entity: 'dnsrecord', hidden:true } > + { entity: 'dnsrecord', hidden: true } > ] > }, > { entity: 'dnsforwardzone' }, > { entity: 'dnsconfig' } > ] > + } > + ] > + }, > + { > + name: 'ipaserver', > + label: '@i18n:tabs.ipaserver', > + children: [ > + { > + name: 'rbac', > + label: '@i18n:tabs.role', > + children: [ > + { entity: 'role' }, > + { entity: 'privilege' }, > + { entity: 'permission' }, > + { entity: 'selfservice' }, > + { entity: 'delegation' } > + ] > }, > - { entity: 'cert', label: '@i18n:tabs.cert' }, > + { entity: 'idrange' }, > { entity: 'realmdomains' }, > - { entity: 'otptoken' } > + { > + name: 'trusts', > + label: '@i18n:tabs.trust', > + children: [ > + { entity: 'trust' }, > + { entity: 'trustconfig' } > + ] > + }, > + { entity: 'config' } > ] > - }, > - {name: 'policy', label: '@i18n:tabs.policy', children: [ > - {name: 'hbac', label: '@i18n:tabs.hbac', children: [ > - {entity: 'hbacrule'}, > - {entity: 'hbacsvc'}, > - {entity: 'hbacsvcgroup'}, > - {entity: 'hbactest'} > - ]}, > - {name: 'sudo', label: '@i18n:tabs.sudo', children: [ > - {entity: 'sudorule'}, > - {entity: 'sudocmd'}, > - {entity: 'sudocmdgroup'} > - ]}, > - { > - name:'automount', > - label: '@i18n:tabs.automount', > - entity: 'automountlocation', > - children:[ > - {entity: 'automountlocation', hidden:true}, > - {entity: 'automountmap', hidden: true}, > - {entity: 'automountkey', hidden: true}] > - }, > - {entity: 'pwpolicy'}, > - {entity: 'krbtpolicy'}, > - {entity: 'selinuxusermap'}, > - { > - name: 'automember', > - label: '@i18n:tabs.automember', > - children: [ > - { > - name: 'amgroup', > - entity: 'automember', > - facet: 'searchgroup', > - label: '@i18n:objects.automember.usergrouprules', > - children: [ > - { > - entity: 'automember', > - facet: 'usergrouprule', > - hidden: true > - } > - ] > - }, > - { > - name: 'amhostgroup', > - entity: 'automember', > - facet: 'searchhostgroup', > - label: '@i18n:objects.automember.hostgrouprules', > - children: [ > - { > - entity: 'automember', > - facet: 'hostgrouprule', > - hidden: true > - } > - ] > - } > - ] > - } > - ]}, > - {name: 'ipaserver', label: '@i18n:tabs.ipaserver', children: [ > - {name: 'rolebased', label: '@i18n:tabs.role', children: [ > - {entity: 'role'}, > - {entity: 'privilege'}, > - {entity: 'permission'} > - ]}, > - {entity: 'selfservice'}, > - {entity: 'delegation'}, > - {entity: 'idrange'}, > - { > - name: 'trusts', > - label: '@i18n:tabs.trust', > - children:[ > - {entity: 'trust'}, > - {entity: 'trustconfig'} > - ] > - }, > - {entity: 'radiusproxy'}, > - {entity: 'config'} > - ]} > + } > ] > }; > > diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json > index 6c387690aac0f85dce7f32f9cec84d55d200f40c..284c0a643391a23f8702ed99078acd1f0250cdf6 100644 > --- a/install/ui/test/data/ipa_init.json > +++ b/install/ui/test/data/ipa_init.json > @@ -553,6 +553,7 @@ > }, > "tabs": { > "audit": "Audit", > + "authentication": "Authentication", > "automember": "Automember", > "automount": "Automount", > "cert": "Certificates", > @@ -560,6 +561,7 @@ > "hbac": "Host Based Access Control", > "identity": "Identity", > "ipaserver": "IPA Server", > + "network_services": "Network Services", > "policy": "Policy", > "role": "Role Based Access Control", > "sudo": "Sudo", > diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py > index d95794cc6806dc44fd533f277d02b330c938f99f..4d9448ab065d5b261d74ef4f126fed07eced4d5e 100644 > --- a/ipalib/plugins/internal.py > +++ b/ipalib/plugins/internal.py > @@ -698,6 +698,7 @@ class i18n_messages(Command): > }, > "tabs": { > "audit": _("Audit"), > + "authentication": _("Authentication"), > "automember": _("Automember"), > "automount": _("Automount"), > "cert": _("Certificates"), > @@ -705,6 +706,7 @@ class i18n_messages(Command): > "hbac": _("Host Based Access Control"), > "identity": _("Identity"), > "ipaserver": _("IPA Server"), > + "network_services": _("Network Services"), > "policy": _("Policy"), > "role": _("Role Based Access Control"), > "sudo": _("Sudo"), > diff --git a/ipatests/test_webui/test_navigation.py b/ipatests/test_webui/test_navigation.py > index caf291a908ec2fc9c4e1a6ee8b2f73f48924f23e..a9adb2327d5e195e3505b9657c5a6e62a2fce44b 100644 > --- a/ipatests/test_webui/test_navigation.py > +++ b/ipatests/test_webui/test_navigation.py > @@ -37,6 +37,8 @@ ENTITIES = [ > # TODO: dnsrecord > 'dnsconfig', > 'cert', > + 'otptoken', > + 'radiusproxy', > 'realmdomains', > 'hbacrule', > 'hbacsvc', > @@ -99,6 +101,7 @@ class test_navigation(UI_driver): > > self.init_app() > > + # Identity > # don't start by users (default) > self.navigate_by_menu('identity/group', False) > self.navigate_by_menu('identity/user', False) > @@ -106,18 +109,11 @@ class test_navigation(UI_driver): > self.navigate_by_menu('identity/hostgroup', False) > self.navigate_by_menu('identity/netgroup', False) > self.navigate_by_menu('identity/service', False) > - if self.has_dns(): > - self.navigate_by_menu('identity/dns/dnsconfig', True) > - self.navigate_by_menu('identity/dns', False) > - self.navigate_by_menu('identity/dns/dnszone', False) > - self.navigate_by_menu('identity/dns/dnsforwardzone') > - else: > - self.assert_menu_item('identity/dns', False) > - if self.has_ca(): > - self.navigate_by_menu('identity/cert', False) > - else: > - self.assert_menu_item('identity/cert', False) > - self.navigate_by_menu('identity/realmdomains', False) > + self.navigate_by_menu('identity/automember', False) > + self.navigate_by_menu('identity/automember/amhostgroup') > + self.navigate_by_menu('identity/automember/amgroup') > + > + # Policy > self.navigate_by_menu('policy') > self.navigate_by_menu('policy/hbac', False) > self.navigate_by_menu('policy/hbac/hbacsvc', False) > @@ -128,21 +124,40 @@ class test_navigation(UI_driver): > self.navigate_by_menu('policy/sudo/sudorule', False) > self.navigate_by_menu('policy/sudo/sudocmd') > self.navigate_by_menu('policy/sudo/sudocmdgroup') > - self.navigate_by_menu('policy/automount', False) > + self.navigate_by_menu('policy/selinuxusermap', False) > self.navigate_by_menu('policy/pwpolicy', False) > self.navigate_by_menu('policy/krbtpolicy', False) > - self.navigate_by_menu('policy/selinuxusermap', False) > - self.navigate_by_menu('policy/automember', False) > - self.navigate_by_menu('policy/automember/amhostgroup') > - self.navigate_by_menu('policy/automember/amgroup') > + > + # Authentication > + self.navigate_by_menu('authentication') > + self.navigate_by_menu('authentication/radiusproxy', False) > + self.navigate_by_menu('authentication/otptoken', False) > + if self.has_ca(): > + self.navigate_by_menu('authentication/cert', False) > + else: > + self.assert_menu_item('authentication/cert', False) > + > + # Network Services > + self.navigate_by_menu('network_services') > + self.navigate_by_menu('network_services/automount') > + if self.has_dns(): > + self.navigate_by_menu('network_services/dns/dnsconfig', True) > + self.navigate_by_menu('network_services/dns', False) > + self.navigate_by_menu('network_services/dns/dnszone', False) > + self.navigate_by_menu('network_services/dns/dnsforwardzone') > + else: > + self.assert_menu_item('network_services/dns', False) > + > + # IPA Server > self.navigate_by_menu('ipaserver') > - self.navigate_by_menu('ipaserver/rolebased', False) > - self.navigate_by_menu('ipaserver/rolebased/privilege', False) > - self.navigate_by_menu('ipaserver/rolebased/role') > - self.navigate_by_menu('ipaserver/rolebased/permission') > - self.navigate_by_menu('ipaserver/selfservice', False) > - self.navigate_by_menu('ipaserver/delegation', False) > + self.navigate_by_menu('ipaserver/rbac', False) > + self.navigate_by_menu('ipaserver/rbac/privilege', False) > + self.navigate_by_menu('ipaserver/rbac/role') > + self.navigate_by_menu('ipaserver/rbac/permission') > + self.navigate_by_menu('ipaserver/rbac/selfservice') > + self.navigate_by_menu('ipaserver/rbac/delegation') > self.navigate_by_menu('ipaserver/idrange', False) > + self.navigate_by_menu('ipaserver/realmdomains', False) > if self.has_trusts(): > self.navigate_by_menu('ipaserver/trusts', False) > self.navigate_by_menu('ipaserver/trusts/trust', False) > @@ -151,6 +166,7 @@ class test_navigation(UI_driver): > self.assert_menu_item('ipaserver/trusts', False) > self.navigate_by_menu('ipaserver/config', False) > > + > def assert_e_url(self, url, e): > """ > Assert correct url for entity > diff --git a/ipatests/test_webui/ui_driver.py b/ipatests/test_webui/ui_driver.py > index 047009a295838d0053c9c0e378e97b480db6a0e7..a1371806c2f11a42534cfcac330683e2a35853d8 100644 > --- a/ipatests/test_webui/ui_driver.py > +++ b/ipatests/test_webui/ui_driver.py > @@ -427,7 +427,7 @@ class UI_driver(object): > > s = ".navbar a[href='#%s']" % item > link = self.find(s, By.CSS_SELECTOR, strict=True) > - assert link.is_displayed(), 'Navigation link is not displayed' > + assert link.is_displayed(), 'Navigation link is not displayed: %s' % item > link.click() > self.wait_for_request() > self.wait_for_request(0.4) > -- > 1.9.0 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Thu Jul 3 07:09:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 09:09:39 +0200 Subject: [Freeipa-devel] [PATCHES 0080-0081] DNSSEC: Add experimental support for DNSSEC In-Reply-To: <53B436D6.3090908@redhat.com> References: <1403881861.2249.20.camel@unused-4-145.brq.redhat.com> <53B4327D.5020004@redhat.com> <53B436D6.3090908@redhat.com> Message-ID: <53B501B3.2000201@redhat.com> On 2.7.2014 18:44, Petr Viktorin wrote: > On 07/02/2014 06:25 PM, Petr Spacek wrote: >> On 27.6.2014 17:11, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4408 >>> Patches attached. >> >> Both patches works for me. I have tested clean installation and upgrade >> from 3.3.5. >> > > Code looks okay, pushed to master: 3b310d6b4f8063149d1abe823b64bc9796a97ab2 > > Is this all for the ticket? Can we close it? Not yet, we need to push mbasti's patch 0083. -- Petr^2 Spacek From mbasti at redhat.com Thu Jul 3 07:13:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 09:13:46 +0200 Subject: [Freeipa-devel] [PATCH 0091] Fix upgrade to forward zones Message-ID: <1404371626.2244.1.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0091-Fix-upgrade-to-forward-zones.patch Type: text/x-patch Size: 1067 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 3 07:17:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 09:17:16 +0200 Subject: [Freeipa-devel] [PATCH 0092] Fix incompatible permission in *zone-del Message-ID: <1404371836.2244.4.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0092-Fix-incompatible-permission-name-zone-del.patch Type: text/x-patch Size: 2572 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 3 08:07:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 10:07:16 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404308046.2172.13.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> <53B4073D.1050408@redhat.com> <1404308046.2172.13.camel@unused-4-145.brq.redhat.com> Message-ID: <53B50F34.20903@redhat.com> On 2.7.2014 15:34, Martin Basti wrote: > On Wed, 2014-07-02 at 15:21 +0200, Petr Spacek wrote: >> On 2.7.2014 14:57, Martin Basti wrote: >>> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >>>> On 1.7.2014 12:20, Martin Kosek wrote: >>>>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>>> It works for me. >>>>>>>>>> >>>>>>>>>> Please change the string little bit, I have realized that we should >>>>>>>>>> ensure >>>>>>>>>> that file permissions are correct: >>>>>>>>>> >>>>>>>>>> chown named: * >>>>>>>>>> chmod u= * >>>>>>>>>> >>>>>>>>>> (the chmod part new) >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>> >>>>>>>>> Updated patch attached >>>>>>>> >>>>>>>> I'm really sorry, I had to change the message once again :-) >>>>>>>> >>>>>>>> None of us noticed that chmod command was completely incorrect. I'm >>>>>>>> attaching fixed patch as an apology. >>>>>>>> >>>>>>>> It works for me when applied to master >>>>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>>>> >>>>>>>> Functional self-ACK :-) >>>>>>>> >>>>>>>> IMHO it can be pushed if Python-review is okay. >>>>>>> >>>>>>> Once again, please define new message classes in messages.py instead of just >>>>>>> using PublicMessage with a custom string. >>>>>>> >>>>>>> Also, these messages will work for console output, but I'm not sure >>>>>>> pre-wrapped text would look good in web UI. >>>>>>> I'm not sold on the idea of giving instructions in warning messages. Would a >>>>>>> link to some documentation be better? >>>>>> >>>>>> Well, the idea was to provide copy&paste instructions directly in the console, >>>>>> not speaking about problems with URLs downstream. >>>>>> >>>>>> If you insist on URL ... here it is: >>>>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>>>> >>>>> >>>>> Please use something more stable, like >>>>> >>>>> http://www.freeipa.org/page/DNSSEC >>>>> >>>>> which we would use as a gathering place for information about FreeIPA and DNSSEC. >>>> >>>> IMHO this particular warning should point to version-specific information. >>>> >>>> I'm not opposing to /page/DNSSEC idea in general but this warning should point >>>> to very specific steps which will be valid only to very specific version of >>>> FreeIPA. >>>> >>> >>> Updated patch attached >> >> I have bad news for you: Patch >> freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch >> >> cannot be applied on top of: >> >> current master (01b95805ab1428e10c79abf70c9bc9e2baf9de21) >> freeipa-mbasti-0080-Allow-to-add-non-string-values-to-named-conf.patch >> freeipa-mbasti-0081-DNSSEC-Add-experimental-support-for-DNSSEC.patch >> freeipa-mbasti-0082-Add-warning-about-semantic-change-for-zones.patch >> > > You need 0082-2 Functional tests are okay, it can be pushed if Python gurus are okay with the code. Ticket https://fedorahosted.org/freeipa/ticket/4408 can be closed. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 08:11:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 10:11:06 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help In-Reply-To: <53B3F5FA.7060206@redhat.com> References: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> <53B3E850.3050805@redhat.com> <1404301422.2172.7.camel@unused-4-145.brq.redhat.com> <53B3F5FA.7060206@redhat.com> Message-ID: <53B5101A.9040109@redhat.com> On 2.7.2014 14:07, Petr Viktorin wrote: > On 07/02/2014 01:43 PM, Martin Basti wrote: >> On Wed, 2014-07-02 at 13:09 +0200, Petr Viktorin wrote: >>> On 07/02/2014 01:02 PM, Martin Basti wrote: >>>> Patch attached. >>>> (Forward zones help preparation) >>>> >>> >>> /me sighs >>> >>> This will invalidate all translations of the DNS plugin help. >>> Is it really necessary for 4.0? >> >> Ask petr2, but I have ticket where I need to add some description about >> forward zones to help. >> >> > > If it's really absolutely unavoidable to change the strings at the last > minute, please do it as fast as possible so translators can get a bit of time > to retranslate. > > Whenever you touch a long docstring, please split up the text according to > http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings > (preferably in a separate patch). ACK from functional perspective. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 08:22:35 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 10:22:35 +0200 Subject: [Freeipa-devel] [PATCH 0089] Add help about forward zones In-Reply-To: <1404309840.2172.15.camel@unused-4-145.brq.redhat.com> References: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> <53B40D34.8070508@redhat.com> <1404309840.2172.15.camel@unused-4-145.brq.redhat.com> Message-ID: <53B512CB.9050200@redhat.com> On 2.7.2014 16:04, Martin Basti wrote: > On Wed, 2014-07-02 at 15:46 +0200, Petr Spacek wrote: >> I have only few nitpicks I didn't notice in the first round: >> >> The original proposal contained also this header: >> SUPPORTED ZONE TYPES >> * Master zone (dnszone-*) contains authoritative data. >> * Forward zone (dnsforwardzone-*) forwards queries to configured forwarders >> (a set of DNS servers). >> >> I can't see it in the patch. >> > It is there > >>> Delete zone example.com with all resource records: >>> ipa dnszone-del example.com >> Is there section with examples for master zones? Please move it there if the >> answer is yes, otherwise it can stay here. >> > Moved > > Updated patch attached > ACK from functional perspective. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 08:23:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 10:23:49 +0200 Subject: [Freeipa-devel] [PATCH 0090] Split dns.py doctring In-Reply-To: <1404310663.2172.17.camel@unused-4-145.brq.redhat.com> References: <1404310663.2172.17.camel@unused-4-145.brq.redhat.com> Message-ID: <53B51315.8050407@redhat.com> On 2.7.2014 16:17, Martin Basti wrote: > Required patches mbasti-0088, mbasti-0089-2 > > Patch attached ACK from functional perspective. As far as I know it didn't break anything. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 08:29:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 10:29:49 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <1404228234.24263.24.camel@unused-4-145.brq.redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> <53B28ABE.5000904@redhat.com> <1404228234.24263.24.camel@unused-4-145.brq.redhat.com> Message-ID: <53B5147D.1030708@redhat.com> On 1.7.2014 17:23, Martin Basti wrote: > On Tue, 2014-07-01 at 12:17 +0200, Petr Viktorin wrote: >> On 07/01/2014 12:10 PM, Martin Basti wrote: >>> On Mon, 2014-06-30 at 13:57 +0200, Petr Viktorin wrote: >>>> On 06/30/2014 12:48 PM, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 >>>>> Patch attached. >>>>> >>>> >>>> When you add a new message, you should also define a new class for it in >>>> messages.py with a new errno, not just reuse PublicMessage with a custom >>>> string. >>>> >>>> >>> >>> Could it be WarningMessage? Or should I be more specific >>> ForwardersWarningMessage, DNSSECWarningMessage ? >> >> Be specific. I'd go for DNSSECWarning; "message" is already in the >> module name. >> >>> Is there any rule how to choose errno? >> >> Just use the next unused one. >> >> > Updated patch attached ACK from functional perspective. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pviktori at redhat.com Thu Jul 3 08:34:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 10:34:48 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <53B5147D.1030708@redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> <1404209410.24263.7.camel@unused-4-145.brq.redhat.com> <53B28ABE.5000904@redhat.com> <1404228234.24263.24.camel@unused-4-145.brq.redhat.com> <53B5147D.1030708@redhat.com> Message-ID: <53B515A8.3030102@redhat.com> On 07/03/2014 10:29 AM, Petr Spacek wrote: > On 1.7.2014 17:23, Martin Basti wrote: >> On Tue, 2014-07-01 at 12:17 +0200, Petr Viktorin wrote: >>> On 07/01/2014 12:10 PM, Martin Basti wrote: >>>> On Mon, 2014-06-30 at 13:57 +0200, Petr Viktorin wrote: >>>>> On 06/30/2014 12:48 PM, Martin Basti wrote: >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 >>>>>> Patch attached. >>>>>> >>>>> >>>>> When you add a new message, you should also define a new class for >>>>> it in >>>>> messages.py with a new errno, not just reuse PublicMessage with a >>>>> custom >>>>> string. >>>>> >>>>> >>>> >>>> Could it be WarningMessage? Or should I be more specific >>>> ForwardersWarningMessage, DNSSECWarningMessage ? >>> >>> Be specific. I'd go for DNSSECWarning; "message" is already in the >>> module name. >>> >>>> Is there any rule how to choose errno? >>> >>> Just use the next unused one. >>> >>> >> Updated patch attached > > ACK from functional perspective. > > It can be pushed if there is no problem with Python side of things. > Pushed to master: 33cf958b98dc2d80d17b3de1c145d403df4a3ba3 -- Petr? From pviktori at redhat.com Thu Jul 3 08:35:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 10:35:23 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B50F34.20903@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> <53B274AF.5010007@redhat.com> <53B27626.5090902@redhat.com> <53B2779F.3040002@redhat.com> <53B28B75.9000106@redhat.com> <53B28C3C.2050903@redhat.com> <1404305869.2172.9.camel@unused-4-145.brq.redhat.com> <53B4073D.1050408@redhat.com> <1404308046.2172.13.camel@unused-4-145.brq.redhat.com> <53B50F34.20903@redhat.com> Message-ID: <53B515CB.9060503@redhat.com> On 07/03/2014 10:07 AM, Petr Spacek wrote: > On 2.7.2014 15:34, Martin Basti wrote: >> On Wed, 2014-07-02 at 15:21 +0200, Petr Spacek wrote: >>> On 2.7.2014 14:57, Martin Basti wrote: >>>> On Tue, 2014-07-01 at 12:23 +0200, Petr Spacek wrote: >>>>> On 1.7.2014 12:20, Martin Kosek wrote: >>>>>> On 07/01/2014 10:55 AM, Petr Spacek wrote: >>>>>>> On 1.7.2014 10:49, Petr Viktorin wrote: >>>>>>>> On 07/01/2014 10:43 AM, Petr Spacek wrote: >>>>>>>>> On 30.6.2014 17:10, Martin Basti wrote: >>>>>>>>>> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: >>>>>>>>>>> On 30.6.2014 14:33, Martin Basti wrote: >>>>>>>>>>>> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >>>>>>>>>>>>> Patch attached. >>>>>>>>>>> >>>>>>>>>>> It works for me. >>>>>>>>>>> >>>>>>>>>>> Please change the string little bit, I have realized that we >>>>>>>>>>> should >>>>>>>>>>> ensure >>>>>>>>>>> that file permissions are correct: >>>>>>>>>>> >>>>>>>>>>> chown named: * >>>>>>>>>>> chmod u= * >>>>>>>>>>> >>>>>>>>>>> (the chmod part new) >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Updated patch attached >>>>>>>>> >>>>>>>>> I'm really sorry, I had to change the message once again :-) >>>>>>>>> >>>>>>>>> None of us noticed that chmod command was completely incorrect. >>>>>>>>> I'm >>>>>>>>> attaching fixed patch as an apology. >>>>>>>>> >>>>>>>>> It works for me when applied to master >>>>>>>>> (50c30c8401c21d43414404bd5caa157196449e4c). >>>>>>>>> >>>>>>>>> Functional self-ACK :-) >>>>>>>>> >>>>>>>>> IMHO it can be pushed if Python-review is okay. >>>>>>>> >>>>>>>> Once again, please define new message classes in messages.py >>>>>>>> instead of just >>>>>>>> using PublicMessage with a custom string. >>>>>>>> >>>>>>>> Also, these messages will work for console output, but I'm not sure >>>>>>>> pre-wrapped text would look good in web UI. >>>>>>>> I'm not sold on the idea of giving instructions in warning >>>>>>>> messages. Would a >>>>>>>> link to some documentation be better? >>>>>>> >>>>>>> Well, the idea was to provide copy&paste instructions directly in >>>>>>> the console, >>>>>>> not speaking about problems with URLs downstream. >>>>>>> >>>>>>> If you insist on URL ... here it is: >>>>>>> http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support >>>>>>> >>>>>>> >>>>>> >>>>>> Please use something more stable, like >>>>>> >>>>>> http://www.freeipa.org/page/DNSSEC >>>>>> >>>>>> which we would use as a gathering place for information about >>>>>> FreeIPA and DNSSEC. >>>>> >>>>> IMHO this particular warning should point to version-specific >>>>> information. >>>>> >>>>> I'm not opposing to /page/DNSSEC idea in general but this warning >>>>> should point >>>>> to very specific steps which will be valid only to very specific >>>>> version of >>>>> FreeIPA. >>>>> >>>> >>>> Updated patch attached >>> >>> I have bad news for you: Patch >>> freeipa-mbasti-0083-4-DNSSEC-experimental-support-warning-message.patch >>> >>> cannot be applied on top of: >>> >>> current master (01b95805ab1428e10c79abf70c9bc9e2baf9de21) >>> freeipa-mbasti-0080-Allow-to-add-non-string-values-to-named-conf.patch >>> freeipa-mbasti-0081-DNSSEC-Add-experimental-support-for-DNSSEC.patch >>> freeipa-mbasti-0082-Add-warning-about-semantic-change-for-zones.patch >>> >> >> You need 0082-2 > > Functional tests are okay, it can be pushed if Python gurus are okay > with the code. > > Ticket > https://fedorahosted.org/freeipa/ticket/4408 > can be closed. > Pushed to master: 70224597a846cbe4cc7fe5f3b3cf3cec1e65ebd2 -- Petr? From pviktori at redhat.com Thu Jul 3 08:35:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 10:35:52 +0200 Subject: [Freeipa-devel] [PATCH 0088] Use documentation addresses in dns help In-Reply-To: <53B5101A.9040109@redhat.com> References: <1404298951.2172.2.camel@unused-4-145.brq.redhat.com> <53B3E850.3050805@redhat.com> <1404301422.2172.7.camel@unused-4-145.brq.redhat.com> <53B3F5FA.7060206@redhat.com> <53B5101A.9040109@redhat.com> Message-ID: <53B515E8.6030002@redhat.com> On 07/03/2014 10:11 AM, Petr Spacek wrote: > On 2.7.2014 14:07, Petr Viktorin wrote: >> On 07/02/2014 01:43 PM, Martin Basti wrote: >>> On Wed, 2014-07-02 at 13:09 +0200, Petr Viktorin wrote: >>>> On 07/02/2014 01:02 PM, Martin Basti wrote: >>>>> Patch attached. >>>>> (Forward zones help preparation) >>>>> >>>> >>>> /me sighs >>>> >>>> This will invalidate all translations of the DNS plugin help. >>>> Is it really necessary for 4.0? >>> >>> Ask petr2, but I have ticket where I need to add some description about >>> forward zones to help. >>> >>> >> >> If it's really absolutely unavoidable to change the strings at the last >> minute, please do it as fast as possible so translators can get a bit >> of time >> to retranslate. >> >> Whenever you touch a long docstring, please split up the text >> according to >> http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings >> >> (preferably in a separate patch). > > ACK from functional perspective. It can be pushed if there is no problem > with Python side of things. > Pushed to master: d18eea457845705aa08e068c1ca19c407a7ede88 -- Petr? From pviktori at redhat.com Thu Jul 3 08:36:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 10:36:13 +0200 Subject: [Freeipa-devel] [PATCH 0089] Add help about forward zones In-Reply-To: <53B512CB.9050200@redhat.com> References: <1404307036.2172.12.camel@unused-4-145.brq.redhat.com> <53B40D34.8070508@redhat.com> <1404309840.2172.15.camel@unused-4-145.brq.redhat.com> <53B512CB.9050200@redhat.com> Message-ID: <53B515FD.9020704@redhat.com> On 07/03/2014 10:22 AM, Petr Spacek wrote: > On 2.7.2014 16:04, Martin Basti wrote: >> On Wed, 2014-07-02 at 15:46 +0200, Petr Spacek wrote: >>> I have only few nitpicks I didn't notice in the first round: >>> >>> The original proposal contained also this header: >>> SUPPORTED ZONE TYPES >>> * Master zone (dnszone-*) contains authoritative data. >>> * Forward zone (dnsforwardzone-*) forwards queries to configured >>> forwarders >>> (a set of DNS servers). >>> >>> I can't see it in the patch. >>> >> It is there >> >>>> Delete zone example.com with all resource records: >>>> ipa dnszone-del example.com >>> Is there section with examples for master zones? Please move it there >>> if the >>> answer is yes, otherwise it can stay here. >>> >> Moved >> >> Updated patch attached >> > > ACK from functional perspective. It can be pushed if there is no problem > with Python side of things. > Pushed to master: d22d9715756b2fcc5b11a8ee088f7eaa577f9625 -- Petr? From pviktori at redhat.com Thu Jul 3 08:43:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 10:43:14 +0200 Subject: [Freeipa-devel] [PATCH 0090] Split dns.py doctring In-Reply-To: <53B51315.8050407@redhat.com> References: <1404310663.2172.17.camel@unused-4-145.brq.redhat.com> <53B51315.8050407@redhat.com> Message-ID: <53B517A2.8020803@redhat.com> On 07/03/2014 10:23 AM, Petr Spacek wrote: > On 2.7.2014 16:17, Martin Basti wrote: >> Required patches mbasti-0088, mbasti-0089-2 >> >> Patch attached > > ACK from functional perspective. As far as I know it didn't break anything. > > It can be pushed if there is no problem with Python side of things. > Thanks! Pushed to master: 1c5fa1c28dd36e1f63dfe341eeb857660eef503a I've also updated the source translations on Transifex. Next time you send a set of related patches, think about using one e-mail thread for all of them. It's not easy to track which patches depend on each other when each one is in a different thread. -- Petr? From pspacek at redhat.com Thu Jul 3 11:47:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 13:47:51 +0200 Subject: [Freeipa-devel] [PATCH 0091] Fix upgrade to forward zones In-Reply-To: <1404371626.2244.1.camel@unused-4-145.brq.redhat.com> References: <1404371626.2244.1.camel@unused-4-145.brq.redhat.com> Message-ID: <53B542E7.1070500@redhat.com> On 3.7.2014 09:13, Martin Basti wrote: > Patch attached ACK from functional perspective. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 11:49:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 13:49:20 +0200 Subject: [Freeipa-devel] [PATCH 0092] Fix incompatible permission in *zone-del In-Reply-To: <1404371836.2244.4.camel@unused-4-145.brq.redhat.com> References: <1404371836.2244.4.camel@unused-4-145.brq.redhat.com> Message-ID: <53B54340.90300@redhat.com> On 3.7.2014 09:17, Martin Basti wrote: > Patch attached ACK from functional perspective. It almost works :-) Old permissions are deleted correctly but new permissions are not added to privileges. IMHO the permission adding should be fixed in separate patch. This patch can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pviktori at redhat.com Thu Jul 3 12:05:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 14:05:21 +0200 Subject: [Freeipa-devel] [PATCH 0092] Fix incompatible permission in *zone-del In-Reply-To: <53B54340.90300@redhat.com> References: <1404371836.2244.4.camel@unused-4-145.brq.redhat.com> <53B54340.90300@redhat.com> Message-ID: <53B54701.6000306@redhat.com> On 07/03/2014 01:49 PM, Petr Spacek wrote: > On 3.7.2014 09:17, Martin Basti wrote: >> Patch attached > > ACK from functional perspective. It almost works :-) > > Old permissions are deleted correctly but new permissions are not added > to privileges. > > IMHO the permission adding should be fixed in separate patch. This patch > can be pushed if there is no problem with Python side of things. > Pushed to master: 21c829ffa52aa3a7af67eb267007aa92622f7eba -- Petr? From pviktori at redhat.com Thu Jul 3 12:05:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Jul 2014 14:05:33 +0200 Subject: [Freeipa-devel] [PATCH 0091] Fix upgrade to forward zones In-Reply-To: <53B542E7.1070500@redhat.com> References: <1404371626.2244.1.camel@unused-4-145.brq.redhat.com> <53B542E7.1070500@redhat.com> Message-ID: <53B5470D.8030005@redhat.com> On 07/03/2014 01:47 PM, Petr Spacek wrote: > On 3.7.2014 09:13, Martin Basti wrote: >> Patch attached > > ACK from functional perspective. > > It can be pushed if there is no problem with Python side of things. > Pushed to master: eea101544125895b3d4f66b61cf8e3870bffed66 -- Petr? From mkosek at redhat.com Thu Jul 3 12:20:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Jul 2014 14:20:48 +0200 Subject: [Freeipa-devel] [PATCH] 693 webui-build: use /usr/share/java/js.jar instead of rhino.jar In-Reply-To: <53B2E18A.8060103@ubuntu.com> References: <53B2DFDA.6020604@redhat.com> <53B2E18A.8060103@ubuntu.com> Message-ID: <53B54AA0.7080001@redhat.com> On 07/01/2014 06:27 PM, Timo Aaltonen wrote: > On 01.07.2014 19:20, Petr Vobornik wrote: >> /usr/share/java/rhino.jar is a Fedora's symlink to /usr/share/java/js.jar >> >> Debian doesn't have it. Direct usage of upstream /usr/share/java/js.jar >> should work on both systems. > > yup, tested on Debian and checked fedora rhino rpm that it has both. > > thanks! Works for me as well. Pushed to master: 76ec9384fb112ee528c5198af0261182f1ad049e Thanks! Martin From pspacek at redhat.com Thu Jul 3 12:59:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 14:59:51 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing tlsarecord in 40-dns.update In-Reply-To: <53B3C3A9.6080200@redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> Message-ID: <53B553C7.9090307@redhat.com> On 2.7.2014 10:32, Petr Spacek wrote: > On 2.7.2014 10:23, Martin Basti wrote: >> On Wed, 2014-07-02 at 09:40 +0200, Petr Spacek wrote: >>> On 1.7.2014 17:28, Martin Basti wrote: >>>> Patch attached >>> >>> I'm not able to apply it on top of current master >>> (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). >>> >> Sorry I lost myself in ACIs, it depends on the patch mbasti-0084-2 and >> 0085-2 > > Okay, I will test it when you send new versions of 0084 and 0085. NACK. It doesn't work for me for some reason, tlsarecord was not added to aci for some reason. The same problem applies to DLVRecord and nSEC3PARAMRecord. DS record seems to be okay. -- Petr^2 Spacek From pvoborni at redhat.com Thu Jul 3 13:06:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Jul 2014 15:06:45 +0200 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure In-Reply-To: <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> References: <53B413B5.7050503@redhat.com> <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> Message-ID: <53B55565.5080006@redhat.com> On 3.7.2014 08:13, Fraser Tweedale wrote: > On Wed, Jul 02, 2014 at 04:14:13PM +0200, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4418 >> >> according to latest >> proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html >> -- >> Petr Vobornik > > Haven't run the webui tests but lines up with the proposal and looks > very nice! > > ACK if webui tests pass. I've run the complete test suite and discovered that I forgot to modify 2 other tests. Also there was an existing fail in test_navigation in DNS-less installation. All fixed, updated patch attached. > >> From 97cc94163e8ae57058b07741c7d70e44697c113f Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Wed, 2 Jul 2014 15:09:22 +0200 >> Subject: [PATCH] webui: new navigation structure >> >> https://fedorahosted.org/freeipa/ticket/4418 >> --- >> install/ui/src/freeipa/certificate.js | 2 +- >> install/ui/src/freeipa/dns.js | 2 +- >> install/ui/src/freeipa/navigation/menu_spec.js | 195 +++++++++++++++---------- >> install/ui/test/data/ipa_init.json | 2 + >> ipalib/plugins/internal.py | 2 + >> ipatests/test_webui/test_navigation.py | 62 +++++--- >> ipatests/test_webui/ui_driver.py | 2 +- >> 7 files changed, 160 insertions(+), 107 deletions(-) >> >> diff --git a/install/ui/src/freeipa/certificate.js b/install/ui/src/freeipa/certificate.js >> index 01dfee2b64c14f487b66b91d449f63b6415dea69..6a11d959398517db6f720a36ff2a323e1d0c74a7 100755 >> --- a/install/ui/src/freeipa/certificate.js >> +++ b/install/ui/src/freeipa/certificate.js >> @@ -1293,7 +1293,7 @@ IPA.cert.cert_update_policy = function(spec) { >> >> exp.remove_menu_item = function() { >> if (!IPA.cert.is_enabled()) { >> - menu.remove_item('identity/cert'); >> + menu.remove_item('authentication/cert'); >> } >> }; >> >> diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js >> index c7143ca91fef9bbc372654080fe899be1ae8367f..a566ccf61adcf4f688ac803bf5e3658b4f3a0253 100644 >> --- a/install/ui/src/freeipa/dns.js >> +++ b/install/ui/src/freeipa/dns.js >> @@ -2543,7 +2543,7 @@ IPA.network_validator = function(spec) { >> >> exp.remove_menu_item = function() { >> if (!IPA.dns_enabled) { >> - menu.remove_item('identity/dns'); >> + menu.remove_item('network_services/dns'); >> } >> }; >> >> diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js >> index 01738cbe60b10bc0f1671093fc1616980780bac1..9182d11bf56c73e1fce724d438fe2211105b75ad 100644 >> --- a/install/ui/src/freeipa/navigation/menu_spec.js >> +++ b/install/ui/src/freeipa/navigation/menu_spec.js >> @@ -43,101 +43,134 @@ var nav = {}; >> { entity: 'netgroup' }, >> { entity: 'service' }, >> { >> + name: 'automember', >> + label: '@i18n:tabs.automember', >> + children: [ >> + { >> + name: 'amgroup', >> + entity: 'automember', >> + facet: 'searchgroup', >> + label: '@i18n:objects.automember.usergrouprules', >> + children: [ >> + { >> + entity: 'automember', >> + facet: 'usergrouprule', >> + hidden: true >> + } >> + ] >> + }, >> + { >> + name: 'amhostgroup', >> + entity: 'automember', >> + facet: 'searchhostgroup', >> + label: '@i18n:objects.automember.hostgrouprules', >> + children: [ >> + { >> + entity: 'automember', >> + facet: 'hostgrouprule', >> + hidden: true >> + } >> + ] >> + } >> + ] >> + } >> + ] >> + }, >> + { >> + name: 'policy', >> + label: '@i18n:tabs.policy', >> + children: [ >> + { >> + name: 'hbac', >> + label: '@i18n:tabs.hbac', >> + children: [ >> + { entity: 'hbacrule' }, >> + { entity: 'hbacsvc' }, >> + { entity: 'hbacsvcgroup' }, >> + { entity: 'hbactest' } >> + ] >> + }, >> + { >> + name: 'sudo', >> + label: '@i18n:tabs.sudo', >> + children: [ >> + { entity: 'sudorule' }, >> + { entity: 'sudocmd' }, >> + { entity: 'sudocmdgroup' } >> + ] >> + }, >> + { entity: 'selinuxusermap' }, >> + { entity: 'pwpolicy' }, >> + { entity: 'krbtpolicy' } >> + ] >> + }, >> + { >> + name: 'authentication', >> + label: '@i18n:tabs.authentication', >> + children: [ >> + { entity: 'cert', label: '@i18n:tabs.cert' }, >> + { entity: 'otptoken' }, >> + { entity: 'radiusproxy' } >> + ] >> + }, >> + { >> + name: 'network_services', >> + label: '@i18n:tabs.network_services', >> + children: [ >> + { >> + name:'automount', >> + label: '@i18n:tabs.automount', >> + entity: 'automountlocation', >> + children: [ >> + { entity: 'automountlocation', hidden: true }, >> + { entity: 'automountmap', hidden: true }, >> + { entity: 'automountkey', hidden: true } >> + ] >> + }, >> + { >> name:'dns', >> label: '@i18n:tabs.dns', >> children: [ >> { >> entity: 'dnszone', >> children: [ >> - { entity: 'dnsrecord', hidden:true } >> + { entity: 'dnsrecord', hidden: true } >> ] >> }, >> { entity: 'dnsforwardzone' }, >> { entity: 'dnsconfig' } >> ] >> + } >> + ] >> + }, >> + { >> + name: 'ipaserver', >> + label: '@i18n:tabs.ipaserver', >> + children: [ >> + { >> + name: 'rbac', >> + label: '@i18n:tabs.role', >> + children: [ >> + { entity: 'role' }, >> + { entity: 'privilege' }, >> + { entity: 'permission' }, >> + { entity: 'selfservice' }, >> + { entity: 'delegation' } >> + ] >> }, >> - { entity: 'cert', label: '@i18n:tabs.cert' }, >> + { entity: 'idrange' }, >> { entity: 'realmdomains' }, >> - { entity: 'otptoken' } >> + { >> + name: 'trusts', >> + label: '@i18n:tabs.trust', >> + children: [ >> + { entity: 'trust' }, >> + { entity: 'trustconfig' } >> + ] >> + }, >> + { entity: 'config' } >> ] >> - }, >> - {name: 'policy', label: '@i18n:tabs.policy', children: [ >> - {name: 'hbac', label: '@i18n:tabs.hbac', children: [ >> - {entity: 'hbacrule'}, >> - {entity: 'hbacsvc'}, >> - {entity: 'hbacsvcgroup'}, >> - {entity: 'hbactest'} >> - ]}, >> - {name: 'sudo', label: '@i18n:tabs.sudo', children: [ >> - {entity: 'sudorule'}, >> - {entity: 'sudocmd'}, >> - {entity: 'sudocmdgroup'} >> - ]}, >> - { >> - name:'automount', >> - label: '@i18n:tabs.automount', >> - entity: 'automountlocation', >> - children:[ >> - {entity: 'automountlocation', hidden:true}, >> - {entity: 'automountmap', hidden: true}, >> - {entity: 'automountkey', hidden: true}] >> - }, >> - {entity: 'pwpolicy'}, >> - {entity: 'krbtpolicy'}, >> - {entity: 'selinuxusermap'}, >> - { >> - name: 'automember', >> - label: '@i18n:tabs.automember', >> - children: [ >> - { >> - name: 'amgroup', >> - entity: 'automember', >> - facet: 'searchgroup', >> - label: '@i18n:objects.automember.usergrouprules', >> - children: [ >> - { >> - entity: 'automember', >> - facet: 'usergrouprule', >> - hidden: true >> - } >> - ] >> - }, >> - { >> - name: 'amhostgroup', >> - entity: 'automember', >> - facet: 'searchhostgroup', >> - label: '@i18n:objects.automember.hostgrouprules', >> - children: [ >> - { >> - entity: 'automember', >> - facet: 'hostgrouprule', >> - hidden: true >> - } >> - ] >> - } >> - ] >> - } >> - ]}, >> - {name: 'ipaserver', label: '@i18n:tabs.ipaserver', children: [ >> - {name: 'rolebased', label: '@i18n:tabs.role', children: [ >> - {entity: 'role'}, >> - {entity: 'privilege'}, >> - {entity: 'permission'} >> - ]}, >> - {entity: 'selfservice'}, >> - {entity: 'delegation'}, >> - {entity: 'idrange'}, >> - { >> - name: 'trusts', >> - label: '@i18n:tabs.trust', >> - children:[ >> - {entity: 'trust'}, >> - {entity: 'trustconfig'} >> - ] >> - }, >> - {entity: 'radiusproxy'}, >> - {entity: 'config'} >> - ]} >> + } >> ] >> }; >> >> diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json >> index 6c387690aac0f85dce7f32f9cec84d55d200f40c..284c0a643391a23f8702ed99078acd1f0250cdf6 100644 >> --- a/install/ui/test/data/ipa_init.json >> +++ b/install/ui/test/data/ipa_init.json >> @@ -553,6 +553,7 @@ >> }, >> "tabs": { >> "audit": "Audit", >> + "authentication": "Authentication", >> "automember": "Automember", >> "automount": "Automount", >> "cert": "Certificates", >> @@ -560,6 +561,7 @@ >> "hbac": "Host Based Access Control", >> "identity": "Identity", >> "ipaserver": "IPA Server", >> + "network_services": "Network Services", >> "policy": "Policy", >> "role": "Role Based Access Control", >> "sudo": "Sudo", >> diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py >> index d95794cc6806dc44fd533f277d02b330c938f99f..4d9448ab065d5b261d74ef4f126fed07eced4d5e 100644 >> --- a/ipalib/plugins/internal.py >> +++ b/ipalib/plugins/internal.py >> @@ -698,6 +698,7 @@ class i18n_messages(Command): >> }, >> "tabs": { >> "audit": _("Audit"), >> + "authentication": _("Authentication"), >> "automember": _("Automember"), >> "automount": _("Automount"), >> "cert": _("Certificates"), >> @@ -705,6 +706,7 @@ class i18n_messages(Command): >> "hbac": _("Host Based Access Control"), >> "identity": _("Identity"), >> "ipaserver": _("IPA Server"), >> + "network_services": _("Network Services"), >> "policy": _("Policy"), >> "role": _("Role Based Access Control"), >> "sudo": _("Sudo"), >> diff --git a/ipatests/test_webui/test_navigation.py b/ipatests/test_webui/test_navigation.py >> index caf291a908ec2fc9c4e1a6ee8b2f73f48924f23e..a9adb2327d5e195e3505b9657c5a6e62a2fce44b 100644 >> --- a/ipatests/test_webui/test_navigation.py >> +++ b/ipatests/test_webui/test_navigation.py >> @@ -37,6 +37,8 @@ ENTITIES = [ >> # TODO: dnsrecord >> 'dnsconfig', >> 'cert', >> + 'otptoken', >> + 'radiusproxy', >> 'realmdomains', >> 'hbacrule', >> 'hbacsvc', >> @@ -99,6 +101,7 @@ class test_navigation(UI_driver): >> >> self.init_app() >> >> + # Identity >> # don't start by users (default) >> self.navigate_by_menu('identity/group', False) >> self.navigate_by_menu('identity/user', False) >> @@ -106,18 +109,11 @@ class test_navigation(UI_driver): >> self.navigate_by_menu('identity/hostgroup', False) >> self.navigate_by_menu('identity/netgroup', False) >> self.navigate_by_menu('identity/service', False) >> - if self.has_dns(): >> - self.navigate_by_menu('identity/dns/dnsconfig', True) >> - self.navigate_by_menu('identity/dns', False) >> - self.navigate_by_menu('identity/dns/dnszone', False) >> - self.navigate_by_menu('identity/dns/dnsforwardzone') >> - else: >> - self.assert_menu_item('identity/dns', False) >> - if self.has_ca(): >> - self.navigate_by_menu('identity/cert', False) >> - else: >> - self.assert_menu_item('identity/cert', False) >> - self.navigate_by_menu('identity/realmdomains', False) >> + self.navigate_by_menu('identity/automember', False) >> + self.navigate_by_menu('identity/automember/amhostgroup') >> + self.navigate_by_menu('identity/automember/amgroup') >> + >> + # Policy >> self.navigate_by_menu('policy') >> self.navigate_by_menu('policy/hbac', False) >> self.navigate_by_menu('policy/hbac/hbacsvc', False) >> @@ -128,21 +124,40 @@ class test_navigation(UI_driver): >> self.navigate_by_menu('policy/sudo/sudorule', False) >> self.navigate_by_menu('policy/sudo/sudocmd') >> self.navigate_by_menu('policy/sudo/sudocmdgroup') >> - self.navigate_by_menu('policy/automount', False) >> + self.navigate_by_menu('policy/selinuxusermap', False) >> self.navigate_by_menu('policy/pwpolicy', False) >> self.navigate_by_menu('policy/krbtpolicy', False) >> - self.navigate_by_menu('policy/selinuxusermap', False) >> - self.navigate_by_menu('policy/automember', False) >> - self.navigate_by_menu('policy/automember/amhostgroup') >> - self.navigate_by_menu('policy/automember/amgroup') >> + >> + # Authentication >> + self.navigate_by_menu('authentication') >> + self.navigate_by_menu('authentication/radiusproxy', False) >> + self.navigate_by_menu('authentication/otptoken', False) >> + if self.has_ca(): >> + self.navigate_by_menu('authentication/cert', False) >> + else: >> + self.assert_menu_item('authentication/cert', False) >> + >> + # Network Services >> + self.navigate_by_menu('network_services') >> + self.navigate_by_menu('network_services/automount') >> + if self.has_dns(): >> + self.navigate_by_menu('network_services/dns/dnsconfig', True) >> + self.navigate_by_menu('network_services/dns', False) >> + self.navigate_by_menu('network_services/dns/dnszone', False) >> + self.navigate_by_menu('network_services/dns/dnsforwardzone') >> + else: >> + self.assert_menu_item('network_services/dns', False) >> + >> + # IPA Server >> self.navigate_by_menu('ipaserver') >> - self.navigate_by_menu('ipaserver/rolebased', False) >> - self.navigate_by_menu('ipaserver/rolebased/privilege', False) >> - self.navigate_by_menu('ipaserver/rolebased/role') >> - self.navigate_by_menu('ipaserver/rolebased/permission') >> - self.navigate_by_menu('ipaserver/selfservice', False) >> - self.navigate_by_menu('ipaserver/delegation', False) >> + self.navigate_by_menu('ipaserver/rbac', False) >> + self.navigate_by_menu('ipaserver/rbac/privilege', False) >> + self.navigate_by_menu('ipaserver/rbac/role') >> + self.navigate_by_menu('ipaserver/rbac/permission') >> + self.navigate_by_menu('ipaserver/rbac/selfservice') >> + self.navigate_by_menu('ipaserver/rbac/delegation') >> self.navigate_by_menu('ipaserver/idrange', False) >> + self.navigate_by_menu('ipaserver/realmdomains', False) >> if self.has_trusts(): >> self.navigate_by_menu('ipaserver/trusts', False) >> self.navigate_by_menu('ipaserver/trusts/trust', False) >> @@ -151,6 +166,7 @@ class test_navigation(UI_driver): >> self.assert_menu_item('ipaserver/trusts', False) >> self.navigate_by_menu('ipaserver/config', False) >> >> + >> def assert_e_url(self, url, e): >> """ >> Assert correct url for entity >> diff --git a/ipatests/test_webui/ui_driver.py b/ipatests/test_webui/ui_driver.py >> index 047009a295838d0053c9c0e378e97b480db6a0e7..a1371806c2f11a42534cfcac330683e2a35853d8 100644 >> --- a/ipatests/test_webui/ui_driver.py >> +++ b/ipatests/test_webui/ui_driver.py >> @@ -427,7 +427,7 @@ class UI_driver(object): >> >> s = ".navbar a[href='#%s']" % item >> link = self.find(s, By.CSS_SELECTOR, strict=True) >> - assert link.is_displayed(), 'Navigation link is not displayed' >> + assert link.is_displayed(), 'Navigation link is not displayed: %s' % item >> link.click() >> self.wait_for_request() >> self.wait_for_request(0.4) >> -- >> 1.9.0 >> -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0694-1-webui-new-navigation-structure.patch Type: text/x-patch Size: 19115 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 3 13:21:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 15:21:02 +0200 Subject: [Freeipa-devel] [PATCH] 0153 ipa-ldap-updater does not work with hardened LDAP configuration In-Reply-To: <20140702135231.GM13108@redhat.com> References: <20140702135231.GM13108@redhat.com> Message-ID: <53B558BE.5080705@redhat.com> On 2.7.2014 15:52, Alexander Bokovoy wrote: > When nsslapd-minssf is greater than 0, running as root > ipa-ldap-updater [-l] > will fail even if we force use of autobind for root over LDAPI. > > The reason for this is that schema updater doesn't get ldapi flag passed > and attempts to connect to LDAP port instead and for hardened > configurations using simple bind over LDAP is not enough. > > Additionally, report properly previously unhandled LDAP exceptions. > https://fedorahosted.org/freeipa/ticket/3468 > > Note that the ticket is in 'Future releases' but we have this bug in 3.3 > and in my view it is serious enough to fix it. ACK from functional perspective. I have tested clean installation and upgrade from 3.3.5 (Fedora 20) and both works. Also ipa-ldap-updates works with minssf = 56. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pvoborni at redhat.com Thu Jul 3 13:30:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Jul 2014 15:30:39 +0200 Subject: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses Message-ID: <53B55AFF.2040905@redhat.com> API responses can contain warnings in "messages" array. This patch also adds support for displaying multiple notifications at the same time in order to show the message and a status of finished operation. Notes: - was implemented because of https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 --> test by modifying Master DNS Zone which has a Zone forwarder set. - I'd like to move the notification code to separate module in a future and then extend it according to PatternFly pattern which is currently under developemnt (should contain history, ...). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0695-webui-display-messages-contained-in-API-responses.patch Type: text/x-patch Size: 10325 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 3 15:03:58 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Jul 2014 17:03:58 +0200 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <538CA7B8.4050503@redhat.com> References: <52CEC112.9010802@redhat.com> <52D4F674.5080302@redhat.com> <52D547C3.4060309@redhat.com> <538CA7B8.4050503@redhat.com> Message-ID: <53B570DE.4070000@redhat.com> On 2.6.2014 18:35, Petr Vobornik wrote: > On 14.1.2014 15:20, Petr Viktorin wrote: >> On 01/14/2014 09:33 AM, Jan Cholasta wrote: >>> On 9.1.2014 16:32, Tomas Babej wrote: >>>> Hi, >>>> >>>> For ipatokennotbefore and ipatokennotafter attributes use DateTime >>>> parameter class instead of Str, since these are represented as >>>> LDAP Generalized Time in LDAP. >>>> >>>> Tomas >>>> >>> >>> ACK. >> >> This apparently depends on tbabej-0137, so let's not push it yet. >> > > I've rebased the patch and wanted to push it but I found out, that in > patch 138 - expose krbPrincipalExpiration we removed the "(UTC)" from > labels [1]. > > We should do the same here. > > [1] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00442.html > Since Tomas is on vacation, I've rebased it again and addressed ^^. If we want this change, it should be pushed before GA since it changes API. Web UI part is pvoborni-548-1 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0140-3-ipalib-Use-DateTime-parameter-class-for-OTP-token-ti.patch Type: text/x-patch Size: 7357 bytes Desc: not available URL: From simo at redhat.com Thu Jul 3 15:21:27 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2014 11:21:27 -0400 Subject: [Freeipa-devel] [PATCH] 0153 ipa-ldap-updater does not work with hardened LDAP configuration In-Reply-To: <53B558BE.5080705@redhat.com> References: <20140702135231.GM13108@redhat.com> <53B558BE.5080705@redhat.com> Message-ID: <1404400887.14455.12.camel@willson.usersys.redhat.com> On Thu, 2014-07-03 at 15:21 +0200, Petr Spacek wrote: > On 2.7.2014 15:52, Alexander Bokovoy wrote: > > When nsslapd-minssf is greater than 0, running as root > > ipa-ldap-updater [-l] > > will fail even if we force use of autobind for root over LDAPI. > > > > The reason for this is that schema updater doesn't get ldapi flag passed > > and attempts to connect to LDAP port instead and for hardened > > configurations using simple bind over LDAP is not enough. > > > > Additionally, report properly previously unhandled LDAP exceptions. > > https://fedorahosted.org/freeipa/ticket/3468 > > > > Note that the ticket is in 'Future releases' but we have this bug in 3.3 > > and in my view it is serious enough to fix it. > > ACK from functional perspective. I have tested clean installation and upgrade > from 3.3.5 (Fedora 20) and both works. > > Also ipa-ldap-updates works with minssf = 56. > > It can be pushed if there is no problem with Python side of things. > I would love to see this in 4.0 GA too. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Jul 3 15:23:47 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2014 11:23:47 -0400 Subject: [Freeipa-devel] [PATCH] 0614 test_ipagetkeytab: Fix expected error message In-Reply-To: <53B43436.8060608@redhat.com> References: <53B43436.8060608@redhat.com> Message-ID: <1404401027.14455.14.camel@willson.usersys.redhat.com> On Wed, 2014-07-02 at 18:32 +0200, Petr Viktorin wrote: > It looks like ipa-getkeytab error message for a non-existent service > changed. > > Simo, is this expected? I was asked to change some messages and I guess this got changed with all the other new ones. It wasn't strictly intentional but it wasn't done by mistake either. > Is the new message final, or should we just check for the "PrincipalName > not found." substring? I do not expect other changes for the near future. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Jul 3 16:02:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 03 Jul 2014 18:02:07 +0200 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <53B570DE.4070000@redhat.com> References: <52CEC112.9010802@redhat.com> <52D4F674.5080302@redhat.com> <52D547C3.4060309@redhat.com> <538CA7B8.4050503@redhat.com> <53B570DE.4070000@redhat.com> Message-ID: <53B57E7F.9060107@redhat.com> On 3.7.2014 17:03, Petr Vobornik wrote: > On 2.6.2014 18:35, Petr Vobornik wrote: >> On 14.1.2014 15:20, Petr Viktorin wrote: >>> On 01/14/2014 09:33 AM, Jan Cholasta wrote: >>>> On 9.1.2014 16:32, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> For ipatokennotbefore and ipatokennotafter attributes use DateTime >>>>> parameter class instead of Str, since these are represented as >>>>> LDAP Generalized Time in LDAP. >>>>> >>>>> Tomas >>>>> >>>> >>>> ACK. >>> >>> This apparently depends on tbabej-0137, so let's not push it yet. >>> >> >> I've rebased the patch and wanted to push it but I found out, that in >> patch 138 - expose krbPrincipalExpiration we removed the "(UTC)" from >> labels [1]. >> >> We should do the same here. >> >> [1] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00442.html >> > > Since Tomas is on vacation, I've rebased it again and addressed ^^. > > If we want this change, it should be pushed before GA since it changes API. > > Web UI part is pvoborni-548-1 Thanks, ACK again. -- Jan Cholasta From mbasti at redhat.com Thu Jul 3 17:00:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 19:00:16 +0200 Subject: [Freeipa-devel] [PATCH 0093] Restore priviledges after forward zone upgrade Message-ID: <1404406816.2232.1.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0093-Restore-privileges-after-forward-zones-update.patch Type: text/x-patch Size: 5275 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 3 17:03:00 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 19:03:00 +0200 Subject: [Freeipa-devel] [PATCH 0093] Non IDNA zone name should be normalized to lowercase Message-ID: <1404406980.2232.4.camel@unused-4-145.brq.redhat.com> Regresion caused by removing validation in DNSName for regular domain names In original code before IDNA, zones were normalized Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0094-Non-IDNA-zonename-should-be-normalized-to-lowercase.patch Type: text/x-patch Size: 1327 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 3 17:04:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 19:04:27 +0200 Subject: [Freeipa-devel] [PATCH 0094] Non IDNA zone name should be normalized to lowercase In-Reply-To: <1404406980.2232.4.camel@unused-4-145.brq.redhat.com> References: <1404406980.2232.4.camel@unused-4-145.brq.redhat.com> Message-ID: <1404407067.2232.6.camel@unused-4-145.brq.redhat.com> On Thu, 2014-07-03 at 19:03 +0200, Martin Basti wrote: > Regresion caused by removing validation in DNSName for regular domain > names > In original code before IDNA, zones were normalized > Patch attached > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Subject changed to patch 0094 sorry, I attach patch again. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0094-Non-IDNA-zonename-should-be-normalized-to-lowercase.patch Type: text/x-patch Size: 1327 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 3 17:34:04 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Jul 2014 19:34:04 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <53B553C7.9090307@redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> Message-ID: <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> On Thu, 2014-07-03 at 14:59 +0200, Petr Spacek wrote: > On 2.7.2014 10:32, Petr Spacek wrote: > > On 2.7.2014 10:23, Martin Basti wrote: > >> On Wed, 2014-07-02 at 09:40 +0200, Petr Spacek wrote: > >>> On 1.7.2014 17:28, Martin Basti wrote: > >>>> Patch attached > >>> > >>> I'm not able to apply it on top of current master > >>> (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). > >>> > >> Sorry I lost myself in ACIs, it depends on the patch mbasti-0084-2 and > >> 0085-2 > > > > Okay, I will test it when you send new versions of 0084 and 0085. > > NACK. It doesn't work for me for some reason, tlsarecord was not added to aci > for some reason. > > The same problem applies to DLVRecord and nSEC3PARAMRecord. DS record seems to > be okay. > Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0087-2-Fix-Missing-ACI-for-records-in-40-dns.update.patch Type: text/x-patch Size: 7144 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 3 18:07:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 03 Jul 2014 20:07:49 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B44356.2040004@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> Message-ID: <53B59BF5.6080404@redhat.com> On 2.7.2014 19:37, Jan Cholasta wrote: > On 2.7.2014 19:08, Rob Crittenden wrote: >> Trimming to respond to your questions. >>>> Not sure if this is related: >>>> # pki cert-find >>>> PKIException: Internal Server Error >> >> I'm pretty sure the cert-find error is related to the fact that I had a >> test build of dogtag installed, so that can be ignored. > > It does not work for me as well, with the current F20 dogtag packages, > but like I said, it worked some time ago. Still haven't figured this out, unfortunately. Added patches 304 and 305 to fix /etc/ipa/ca.crt not having all the CA certificates on master. Updated rebased patches attached. The correct order to apply is 295-294, 303-305, 295-299. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.6-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.6-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.6-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.6-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.6-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.6-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.6-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.6-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.6-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.6-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.6-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.6-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.6-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.5-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.4-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.4-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.4-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.3-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.3-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.3-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.3-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.3-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 9990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.3-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 3725 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.3-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.3-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.3-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.3-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 13369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.3-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.3-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.3-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 14520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.3-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.3-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.3-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.3-Add-new-add_cert-method-for-adding-certificates-to-N.patch Type: text/x-patch Size: 3420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.3-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.3-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.3-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.3-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.3-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.3-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 3612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.3-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.3-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.3-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.3-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.3-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.3-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.3-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296.3-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 5793 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297.3-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3230 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298.3-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299.3-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 15852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-303.1-Add-client-certificate-update-tool-ipa-certupdate.patch Type: text/x-patch Size: 12216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-304-Export-full-CA-chain-to-etc-ipa-ca.crt-in-ipa-server.patch Type: text/x-patch Size: 1105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-305-Allow-multiple-CA-certificates-in-replica-info-files.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 3 18:57:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 20:57:06 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53B5A782.9000003@redhat.com> On 3.7.2014 19:34, Martin Basti wrote: > On Thu, 2014-07-03 at 14:59 +0200, Petr Spacek wrote: >> On 2.7.2014 10:32, Petr Spacek wrote: >>> On 2.7.2014 10:23, Martin Basti wrote: >>>> On Wed, 2014-07-02 at 09:40 +0200, Petr Spacek wrote: >>>>> On 1.7.2014 17:28, Martin Basti wrote: >>>>>> Patch attached >>>>> >>>>> I'm not able to apply it on top of current master >>>>> (21e1e4ac3bd62c20c6331ea3dc09793e3a869c22). >>>>> >>>> Sorry I lost myself in ACIs, it depends on the patch mbasti-0084-2 and >>>> 0085-2 >>> >>> Okay, I will test it when you send new versions of 0084 and 0085. >> >> NACK. It doesn't work for me for some reason, tlsarecord was not added to aci >> for some reason. >> >> The same problem applies to DLVRecord and nSEC3PARAMRecord. DS record seems to >> be okay. >> > > Updated patch attached Sorry, NACK! ;-) Upgrade from 3.3.5 died with error in ipa-ldap-updater: Parsing update file '/usr/share/ipa/updates/40-dns.update' Updating existing entry: cn=IPA DNS,cn=plugins,cn=config Done Updating existing entry: cn=dns,dc=ipa,dc=example Unexpected error - see /var/log/ipaupgrade.log for details: InvalidSyntax: targetattr "idnsforwarders dlvrecord" does not exist in schema. Please add attributeTypes "idnsforwarders dlvrecord" to schema if necessary. ACL Syntax Error(-5):(targetattr = \22idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy || idnsallowquery || idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy || idnsforwarders dlvrecord || idnssecinlinesigning || nsec3paramrecord || tlsarecord\22)(target = \22ldap:///idnsname=\2a,cn=dns,dc=ipa,dc=example\22)(version 3.0;acl \22Update DNS entries in a zone\22;allow (write) userattr = \22parent[0,1].managedby#GROUPDN\22;): Invalid syntax. /var/log/ipaupgrade.log says this: 2014-07-03T18:52:48Z DEBUG Final value after applying updates 2014-07-03T18:52:48Z DEBUG dn: cn=dns,dc=ipa,dc=example 2014-07-03T18:52:48Z DEBUG objectClass: 2014-07-03T18:52:48Z DEBUG nsContainer 2014-07-03T18:52:48Z DEBUG top 2014-07-03T18:52:48Z DEBUG idnsConfigObject 2014-07-03T18:52:48Z DEBUG idnsConfigObject 2014-07-03T18:52:48Z DEBUG aci: 2014-07-03T18:52:48Z DEBUG (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Add DNS entries in a zone";allow (add) userattr = "parent[1].manage dby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Remove DNS entries from a zone";allow (delete) userattr = "parent[1 ].managedby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord | | kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaseria l || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy || idnsallowquery || idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy || idnsforwarders")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Update DNS entries in a zone";allow (write) userattr = "parent[0,1].managedby#GROU PDN";) 2014-07-03T18:52:48Z DEBUG (targetattr = "*")(version 3.0; acl "Allow read access"; allow (read,search,compare) groupdn = "ldap:///cn=Read DNS Entries,cn=permissions,cn =pbac,dc=ipa,dc=example" or userattr = "parent[0,1].managedby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Add DNS entries in a zone";allow (add) userattr = "parent[1].manage dby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG (target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Remove DNS entries from a zone";allow (delete) userattr = "parent[1 ].managedby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord | | kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaseria l || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy || idnsallowquery || idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy || idnsforwarders dlvrecord || idnssecinlinesigning || nsec3paramrecord || tlsarecord")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Update DNS entries in a zone";allow (write) userattr = "parent[0,1].managedby#GROUPDN";) 2014-07-03T18:52:48Z DEBUG cn: 2014-07-03T18:52:48Z DEBUG dns 2014-07-03T18:52:48Z DEBUG [(0, u'aci', ['(targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy || idnsallowquery || idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy || idnsforwarders dlvrecord || idnssecinlinesigning || nsec3paramrecord || tlsarecord")(target = "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example")(version 3.0;acl "Update DNS entries in a zone";allow (write) userattr = "parent[0,1].managedby#GROUPDN";)'])] 2014-07-03T18:52:48Z DEBUG Live 1, updated 1 2014-07-03T18:52:48Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 213, in run modified = ld.update(self.files, ordered=True) or modified File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 859, in update self._run_updates(all_updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 791, in _run_updates self._update_record(update) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 712, in _update_record self.conn.update_entry(entry) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1622, in update_entry self.conn.modify_s(entry.dn, modlist) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1183, in error_handler raise errors.InvalidSyntax(attr=info) -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 19:24:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 21:24:21 +0200 Subject: [Freeipa-devel] [PATCH 0093] Restore priviledges after forward zone upgrade In-Reply-To: <1404406816.2232.1.camel@unused-4-145.brq.redhat.com> References: <1404406816.2232.1.camel@unused-4-145.brq.redhat.com> Message-ID: <53B5ADE5.4010703@redhat.com> On 3.7.2014 19:00, Martin Basti wrote: > Patch attached Congratulations! I wasn't able to find any bug in this ;-) ACK from functional perspective. It can be pushed if there is no problem with Python side of things. -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 3 19:41:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 03 Jul 2014 21:41:21 +0200 Subject: [Freeipa-devel] [PATCH 0094] Non IDNA zone name should be normalized to lowercase In-Reply-To: <1404407067.2232.6.camel@unused-4-145.brq.redhat.com> References: <1404406980.2232.4.camel@unused-4-145.brq.redhat.com> <1404407067.2232.6.camel@unused-4-145.brq.redhat.com> Message-ID: <53B5B1E1.1010803@redhat.com> On 3.7.2014 19:04, Martin Basti wrote: > On Thu, 2014-07-03 at 19:03 +0200, Martin Basti wrote: >> Regresion caused by removing validation in DNSName for regular domain >> names >> In original code before IDNA, zones were normalized >> Patch attached > > Subject changed to patch 0094 > sorry, I attach patch again. ACK from functional perspective. Command "ipa dnszone TEST" adds DNS zone "test.". It can be pushed if there is no problem on Python side of things. -- Petr^2 Spacek From rcritten at redhat.com Thu Jul 3 21:52:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jul 2014 17:52:49 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B59BF5.6080404@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> Message-ID: <53B5D0B1.7070706@redhat.com> Jan Cholasta wrote: > On 2.7.2014 19:37, Jan Cholasta wrote: >> On 2.7.2014 19:08, Rob Crittenden wrote: >>> Trimming to respond to your questions. >>>>> Not sure if this is related: >>>>> # pki cert-find >>>>> PKIException: Internal Server Error >>> >>> I'm pretty sure the cert-find error is related to the fact that I had a >>> test build of dogtag installed, so that can be ignored. >> >> It does not work for me as well, with the current F20 dogtag packages, >> but like I said, it worked some time ago. > > Still haven't figured this out, unfortunately. > > Added patches 304 and 305 to fix /etc/ipa/ca.crt not having all the CA > certificates on master. > > Updated rebased patches attached. The correct order to apply is 295-294, > 303-305, 295-299. > 251 I'm a little confused about the profile names. I see you changed the renewal profile from ipaCACertRenewal to caCACert which I guess makes sense. I don't see a ipaCACertRenewal profile. There is still a reference to a ipaRetrieval profile, what is that? ACK to the changes in 291 299 I guess you added the check for existing certs to avoid conflicts? I guess it means that a user is hosed if they chose the same name for their CA that we use? I think you're missing a sys.exit(1) here. 303 Looks good. The man page is still a little thin 304 Not to be too pedantic but if removing the old CACERT fails (SELinux, immutable file) then the install will blow up and this is the very end. I think the removal should happen earlier, before anything else happens. That way at least you don't wait 10 minuts to find out the install failed. 305 ACK I didn't have a ton of time to test but a basic install fails with: 2014-07-03T21:44:49Z DEBUG stderr= 2014-07-03T21:44:49Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 640, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1046, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 489, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1041, in __import_ca_chain (rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 79, in get_cert_nickname nsscert = x509.load_certificate(cert) File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 119, in load_certificate return nss.Certificate(buffer(data)) 2014-07-03T21:44:49Z DEBUG The ipa-server-install command failed, exception: NSPRError: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. rob From mkosek at redhat.com Fri Jul 4 06:15:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 08:15:20 +0200 Subject: [Freeipa-devel] [PATCH] 0153 ipa-ldap-updater does not work with hardened LDAP configuration In-Reply-To: <53B558BE.5080705@redhat.com> References: <20140702135231.GM13108@redhat.com> <53B558BE.5080705@redhat.com> Message-ID: <53B64678.9070609@redhat.com> On 07/03/2014 03:21 PM, Petr Spacek wrote: > On 2.7.2014 15:52, Alexander Bokovoy wrote: >> When nsslapd-minssf is greater than 0, running as root >> ipa-ldap-updater [-l] >> will fail even if we force use of autobind for root over LDAPI. >> >> The reason for this is that schema updater doesn't get ldapi flag passed >> and attempts to connect to LDAP port instead and for hardened >> configurations using simple bind over LDAP is not enough. >> >> Additionally, report properly previously unhandled LDAP exceptions. >> https://fedorahosted.org/freeipa/ticket/3468 >> >> Note that the ticket is in 'Future releases' but we have this bug in 3.3 >> and in my view it is serious enough to fix it. > > ACK from functional perspective. I have tested clean installation and upgrade > from 3.3.5 (Fedora 20) and both works. > > Also ipa-ldap-updates works with minssf = 56. > > It can be pushed if there is no problem with Python side of things. > Looks good to me. Pushed to master: a9fe37e0664079ad2da7b0d9b9b7c7e244a25bf9 Martin From mkosek at redhat.com Fri Jul 4 06:18:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 08:18:22 +0200 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <53B57E7F.9060107@redhat.com> References: <52CEC112.9010802@redhat.com> <52D4F674.5080302@redhat.com> <52D547C3.4060309@redhat.com> <538CA7B8.4050503@redhat.com> <53B570DE.4070000@redhat.com> <53B57E7F.9060107@redhat.com> Message-ID: <53B6472E.6060609@redhat.com> On 07/03/2014 06:02 PM, Jan Cholasta wrote: > On 3.7.2014 17:03, Petr Vobornik wrote: >> On 2.6.2014 18:35, Petr Vobornik wrote: >>> On 14.1.2014 15:20, Petr Viktorin wrote: >>>> On 01/14/2014 09:33 AM, Jan Cholasta wrote: >>>>> On 9.1.2014 16:32, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> For ipatokennotbefore and ipatokennotafter attributes use DateTime >>>>>> parameter class instead of Str, since these are represented as >>>>>> LDAP Generalized Time in LDAP. >>>>>> >>>>>> Tomas >>>>>> >>>>> >>>>> ACK. >>>> >>>> This apparently depends on tbabej-0137, so let's not push it yet. >>>> >>> >>> I've rebased the patch and wanted to push it but I found out, that in >>> patch 138 - expose krbPrincipalExpiration we removed the "(UTC)" from >>> labels [1]. >>> >>> We should do the same here. >>> >>> [1] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00442.html >>> >> >> Since Tomas is on vacation, I've rebased it again and addressed ^^. >> >> If we want this change, it should be pushed before GA since it changes API. >> >> Web UI part is pvoborni-548-1 > > Thanks, ACK again. > Pushed to master: 9bf29c270d703eeae5c0ccfe6b99cd7d1a8e8c86 Martin From dkupka at redhat.com Fri Jul 4 06:47:01 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 04 Jul 2014 08:47:01 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Fix ipa-client-install --uninstall crash Message-ID: <53B64DE5.5030202@redhat.com> https://fedorahosted.org/freeipa/ticket/4273 David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0001-Fix-ipa-client-install-uninstall-crash.patch Type: text/x-patch Size: 1205 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 4 06:49:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 08:49:40 +0200 Subject: [Freeipa-devel] [PATCH] 548 webui: change ipatokennotbefore and ipatokennotafter types to datetime In-Reply-To: <53233E41.2040606@redhat.com> References: <530CCE75.7010808@redhat.com> <53233E41.2040606@redhat.com> Message-ID: <53B64E84.7010908@redhat.com> On 03/14/2014 06:37 PM, Petr Vobornik wrote: > On 25.2.2014 18:10, Petr Vobornik wrote: >> Depends on tbabej's patches # 137, 140 and pvoborni's 546 and 531-541. >> >> https://fedorahosted.org/freeipa/ticket/3369 >> >> > > Attaching rebased patch. Works fine with Tomas' patch. ACK. Pushed to master: bc1979ac09f6e01e1d8e13c21f41aee3c7e78ee0 Martin From mkosek at redhat.com Fri Jul 4 06:52:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 08:52:48 +0200 Subject: [Freeipa-devel] [PATCH] 0614 test_ipagetkeytab: Fix expected error message In-Reply-To: <1404401027.14455.14.camel@willson.usersys.redhat.com> References: <53B43436.8060608@redhat.com> <1404401027.14455.14.camel@willson.usersys.redhat.com> Message-ID: <53B64F40.6000506@redhat.com> On 07/03/2014 05:23 PM, Simo Sorce wrote: > On Wed, 2014-07-02 at 18:32 +0200, Petr Viktorin wrote: >> It looks like ipa-getkeytab error message for a non-existent service >> changed. >> >> Simo, is this expected? > > I was asked to change some messages and I guess this got changed with > all the other new ones. It wasn't strictly intentional but it wasn't > done by mistake either. > >> Is the new message final, or should we just check for the "PrincipalName >> not found." substring? > > I do not expect other changes for the near future. > > Simo. > In that case ACK for Petr's patch, tests were fixed. Pushed to master: a7e400fa654c8afb44b25f0645747c200ef34e09 Martin From mkosek at redhat.com Fri Jul 4 07:05:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 09:05:05 +0200 Subject: [Freeipa-devel] [PATCH] test_ipaserver: Add OTP token test data to ipatests package In-Reply-To: <53B43156.1040300@redhat.com> References: <53B43156.1040300@redhat.com> Message-ID: <53B65221.4020903@redhat.com> On 07/02/2014 06:20 PM, Petr Viktorin wrote: > Hello, > > Some data is not put in the ipatests package. This prevents OTP token import > tests from passing when run out of tree. > > Fix included. Thanks, package now contains the test date. ACK. Pushed to master: 6f2451ce9e68e2425c665f5dc11d0800ae83a0b2 Martin From mkosek at redhat.com Fri Jul 4 07:28:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 09:28:13 +0200 Subject: [Freeipa-devel] [PATCH 0094] Non IDNA zone name should be normalized to lowercase In-Reply-To: <53B5B1E1.1010803@redhat.com> References: <1404406980.2232.4.camel@unused-4-145.brq.redhat.com> <1404407067.2232.6.camel@unused-4-145.brq.redhat.com> <53B5B1E1.1010803@redhat.com> Message-ID: <53B6578D.2060300@redhat.com> On 07/03/2014 09:41 PM, Petr Spacek wrote: > On 3.7.2014 19:04, Martin Basti wrote: >> On Thu, 2014-07-03 at 19:03 +0200, Martin Basti wrote: >>> Regresion caused by removing validation in DNSName for regular domain >>> names >>> In original code before IDNA, zones were normalized >>> Patch attached >> >> Subject changed to patch 0094 >> sorry, I attach patch again. > > ACK from functional perspective. Command "ipa dnszone TEST" adds DNS zone "test.". > > It can be pushed if there is no problem on Python side of things. Looks good to me. Pushed to master: 29951ada9fd7dd8e0887f0832c6b58f266960b72 Martin From mkosek at redhat.com Fri Jul 4 07:34:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 09:34:25 +0200 Subject: [Freeipa-devel] [PATCH] 477 Add Modify Realm Domains permission Message-ID: <53B65901.2040306@redhat.com> The permission is required for DNS Administrators as realm domains object is updated when a master zone is added. https://fedorahosted.org/freeipa/ticket/4423 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-477-add-modify-realm-domains-permission.patch Type: text/x-patch Size: 1174 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 4 07:52:29 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 09:52:29 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <53B5A782.9000003@redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> <53B5A782.9000003@redhat.com> Message-ID: <1404460349.2304.0.camel@unused-4-145.brq.redhat.com> Updated patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0087-3-Fix-Missing-ACI-for-records-in-40-dns.update.patch Type: text/x-patch Size: 7147 bytes Desc: not available URL: From pspacek at redhat.com Fri Jul 4 08:00:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 10:00:47 +0200 Subject: [Freeipa-devel] [PATCH] 477 Add Modify Realm Domains permission In-Reply-To: <53B65901.2040306@redhat.com> References: <53B65901.2040306@redhat.com> Message-ID: <53B65F2F.2080306@redhat.com> On 4.7.2014 09:34, Martin Kosek wrote: > The permission is required for DNS Administrators as realm domains > object is updated when a master zone is added. > > https://fedorahosted.org/freeipa/ticket/4423 I can't resist ;-) NACK: Build failed. --- existing ACI.txt +++ new result @@ -154,6 +154,8 @@ aci: (targetattr = "krbmaxpwdlife || krbminpwdlife || krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength")(targetfilter = "(objectclass=krbpwdpolicy)")(version 3.0;acl "permission:System: Modify Group Password Policy";allow (write) groupdn = "ldap:///cn=System: Modify Group Password Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=System: Read Group Password Policy,cn=permissions,cn=pbac,dc=ipa,dc=example aci: (targetattr = "cn || cospriority || krbmaxpwdlife || krbminpwdlife || krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength || objectclass")(targetfilter = "(objectclass=krbpwdpolicy)")(version 3.0;acl "permission:System: Read Group Password Policy";allow (compare,read,search) groupdn = "ldap:///cn=System: Read Group Password Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: cn=System: Modify Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example +aci: (targetattr = "associateddomain")(targetfilter = "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Modify Realm Domains";allow (write) groupdn = "ldap:///cn=System: Modify Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=System: Read Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example aci: (targetattr = "associateddomain || cn || objectclass")(targetfilter = "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Read Realm Domains";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=System: Add Roles,cn=permissions,cn=pbac,dc=ipa,dc=example Managed permission ACI validation failed. Re-check permission changes and run `makeaci`. ACI.txt validation failed -- Petr^2 Spacek From mkosek at redhat.com Fri Jul 4 08:08:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 10:08:23 +0200 Subject: [Freeipa-devel] [PATCH] 477 Add Modify Realm Domains permission In-Reply-To: <53B65F2F.2080306@redhat.com> References: <53B65901.2040306@redhat.com> <53B65F2F.2080306@redhat.com> Message-ID: <53B660F7.5040209@redhat.com> On 07/04/2014 10:00 AM, Petr Spacek wrote: > On 4.7.2014 09:34, Martin Kosek wrote: >> The permission is required for DNS Administrators as realm domains >> object is updated when a master zone is added. >> >> https://fedorahosted.org/freeipa/ticket/4423 > > I can't resist ;-) > > NACK: Build failed. > > --- existing ACI.txt > +++ new result > @@ -154,6 +154,8 @@ > aci: (targetattr = "krbmaxpwdlife || krbminpwdlife || > krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || > krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength")(targetfilter = > "(objectclass=krbpwdpolicy)")(version 3.0;acl "permission:System: Modify Group > Password Policy";allow (write) groupdn = "ldap:///cn=System: Modify Group > Password Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) > dn: cn=System: Read Group Password > Policy,cn=permissions,cn=pbac,dc=ipa,dc=example > aci: (targetattr = "cn || cospriority || krbmaxpwdlife || krbminpwdlife || > krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || > krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength || > objectclass")(targetfilter = "(objectclass=krbpwdpolicy)")(version 3.0;acl > "permission:System: Read Group Password Policy";allow (compare,read,search) > groupdn = "ldap:///cn=System: Read Group Password > Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) > +dn: cn=System: Modify Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example > +aci: (targetattr = "associateddomain")(targetfilter = > "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Modify > Realm Domains";allow (write) groupdn = "ldap:///cn=System: Modify Realm > Domains,cn=permissions,cn=pbac,dc=ipa,dc=example";) > dn: cn=System: Read Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example > aci: (targetattr = "associateddomain || cn || objectclass")(targetfilter = > "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Read > Realm Domains";allow (compare,read,search) userdn = "ldap:///all";) > dn: cn=System: Add Roles,cn=permissions,cn=pbac,dc=ipa,dc=example > > Managed permission ACI validation failed. > Re-check permission changes and run `makeaci`. > ACI.txt validation failed Oh, well - here is an updated patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-477-2-add-modify-realm-domains-permission.patch Type: text/x-patch Size: 3145 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 4 08:18:44 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 10:18:44 +0200 Subject: [Freeipa-devel] [PATCH 0095] Fix dns_realmdomains_integration test Message-ID: <1404461924.2304.2.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0095-Fix-tests-dns_realmdomains_integration.patch Type: text/x-patch Size: 1484 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 4 08:37:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 10:37:59 +0200 Subject: [Freeipa-devel] [PATCH 0095] Fix dns_realmdomains_integration test In-Reply-To: <1404461924.2304.2.camel@unused-4-145.brq.redhat.com> References: <1404461924.2304.2.camel@unused-4-145.brq.redhat.com> Message-ID: <53B667E7.5030106@redhat.com> On 07/04/2014 10:18 AM, Martin Basti wrote: > Patch attached Yup, this fixed the test. ACK. Pushed to master: 52bcf5345c9a920db513ed3fc8c2dc029661ecf2 Martin From pspacek at redhat.com Fri Jul 4 10:09:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 12:09:39 +0200 Subject: [Freeipa-devel] [PATCH] 477 Add Modify Realm Domains permission In-Reply-To: <53B660F7.5040209@redhat.com> References: <53B65901.2040306@redhat.com> <53B65F2F.2080306@redhat.com> <53B660F7.5040209@redhat.com> Message-ID: <53B67D63.9030607@redhat.com> On 4.7.2014 10:08, Martin Kosek wrote: > On 07/04/2014 10:00 AM, Petr Spacek wrote: >> On 4.7.2014 09:34, Martin Kosek wrote: >>> The permission is required for DNS Administrators as realm domains >>> object is updated when a master zone is added. >>> >>> https://fedorahosted.org/freeipa/ticket/4423 >> >> I can't resist ;-) >> >> NACK: Build failed. >> >> --- existing ACI.txt >> +++ new result >> @@ -154,6 +154,8 @@ >> aci: (targetattr = "krbmaxpwdlife || krbminpwdlife || >> krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || >> krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength")(targetfilter = >> "(objectclass=krbpwdpolicy)")(version 3.0;acl "permission:System: Modify Group >> Password Policy";allow (write) groupdn = "ldap:///cn=System: Modify Group >> Password Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> dn: cn=System: Read Group Password >> Policy,cn=permissions,cn=pbac,dc=ipa,dc=example >> aci: (targetattr = "cn || cospriority || krbmaxpwdlife || krbminpwdlife || >> krbpwdfailurecountinterval || krbpwdhistorylength || krbpwdlockoutduration || >> krbpwdmaxfailure || krbpwdmindiffchars || krbpwdminlength || >> objectclass")(targetfilter = "(objectclass=krbpwdpolicy)")(version 3.0;acl >> "permission:System: Read Group Password Policy";allow (compare,read,search) >> groupdn = "ldap:///cn=System: Read Group Password >> Policy,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> +dn: cn=System: Modify Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example >> +aci: (targetattr = "associateddomain")(targetfilter = >> "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Modify >> Realm Domains";allow (write) groupdn = "ldap:///cn=System: Modify Realm >> Domains,cn=permissions,cn=pbac,dc=ipa,dc=example";) >> dn: cn=System: Read Realm Domains,cn=permissions,cn=pbac,dc=ipa,dc=example >> aci: (targetattr = "associateddomain || cn || objectclass")(targetfilter = >> "(objectclass=domainrelatedobject)")(version 3.0;acl "permission:System: Read >> Realm Domains";allow (compare,read,search) userdn = "ldap:///all";) >> dn: cn=System: Add Roles,cn=permissions,cn=pbac,dc=ipa,dc=example >> >> Managed permission ACI validation failed. >> Re-check permission changes and run `makeaci`. >> ACI.txt validation failed > > Oh, well - here is an updated patch. ACK from functional perspective. I'm not able to reproduce the problem with the patch applied. I have tested clean installation and also upgrade from 3.3.5. It can be pushed if there is no problem on Python side of things. -- Petr^2 Spacek From pviktori at redhat.com Fri Jul 4 10:14:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 12:14:23 +0200 Subject: [Freeipa-devel] [PATCH] 0615 ldapupdate: Restore 'replace' functionality Message-ID: <53B67E7F.8000807@redhat.com> Some months ago, when working on the schema updater, I broke the 'replace' directive in ldapupdater. Luckily the regression didn't make it to a released version. Here is a fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0615-ldapupdate-Restore-replace-functionality.patch Type: text/x-patch Size: 1406 bytes Desc: not available URL: From pviktori at redhat.com Fri Jul 4 10:15:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 12:15:50 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <1404460349.2304.0.camel@unused-4-145.brq.redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> <53B5A782.9000003@redhat.com> <1404460349.2304.0.camel@unused-4-145.brq.redhat.com> Message-ID: <53B67ED6.9040400@redhat.com> On 07/04/2014 09:52 AM, Martin Basti wrote: > Updated patch attached > Almost there. There's a missing space in the "addifexist" ACI, quite important as the values are checked byte-for-byte on updates. Also, it turns out dns.ldif (which creates cn=dns) is loaded after updates, so a line there is needed as well. Sorry for misinformation I've spread offline. I tested the attached version with working ldapupdater (my patch 0615): upgrades and new installs, both with DNS missing and DNS installed. I can push if you agree with the changes. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0087-3+pviktori-Fix-Missing-tlsarecord-in-40-dns.update.patch Type: text/x-patch Size: 8939 bytes Desc: not available URL: From pviktori at redhat.com Fri Jul 4 10:17:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 12:17:47 +0200 Subject: [Freeipa-devel] [PATCH] 477 Add Modify Realm Domains permission In-Reply-To: <53B67D63.9030607@redhat.com> References: <53B65901.2040306@redhat.com> <53B65F2F.2080306@redhat.com> <53B660F7.5040209@redhat.com> <53B67D63.9030607@redhat.com> Message-ID: <53B67F4B.8000109@redhat.com> On 07/04/2014 12:09 PM, Petr Spacek wrote: > On 4.7.2014 10:08, Martin Kosek wrote: >> On 07/04/2014 10:00 AM, Petr Spacek wrote: >>> On 4.7.2014 09:34, Martin Kosek wrote: >>>> The permission is required for DNS Administrators as realm domains >>>> object is updated when a master zone is added. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4423 >>> >>> I can't resist ;-) >>> >>> NACK: Build failed. >>> [...] >> Oh, well - here is an updated patch. > > ACK from functional perspective. I'm not able to reproduce the problem > with the patch applied. I have tested clean installation and also > upgrade from 3.3.5. > > It can be pushed if there is no problem on Python side of things. > Pushed to master: ef83a0c67884274be000f3b4fcc8150e8910bcb7 -- Petr? From mbasti at redhat.com Fri Jul 4 10:21:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 12:21:15 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <53B67ED6.9040400@redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> <53B5A782.9000003@redhat.com> <1404460349.2304.0.camel@unused-4-145.brq.redhat.com> <53B67ED6.9040400@redhat.com> Message-ID: <1404469275.2304.3.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 12:15 +0200, Petr Viktorin wrote: > On 07/04/2014 09:52 AM, Martin Basti wrote: > > Updated patch attached > > > > Almost there. > There's a missing space in the "addifexist" ACI, quite important as the > values are checked byte-for-byte on updates. > > Also, it turns out dns.ldif (which creates cn=dns) is loaded after > updates, so a line there is needed as well. Sorry for misinformation > I've spread offline. > > I tested the attached version with working ldapupdater (my patch 0615): > upgrades and new installs, both with DNS missing and DNS installed. I > can push if you agree with the changes. > > I agree with changes -- Martin^2 Basti From pviktori at redhat.com Fri Jul 4 10:27:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 12:27:53 +0200 Subject: [Freeipa-devel] [PATCH 0087] Fix: missing records in 40-dns.update In-Reply-To: <1404469275.2304.3.camel@unused-4-145.brq.redhat.com> References: <1404228537.24263.26.camel@unused-4-145.brq.redhat.com> <53B3B758.2060809@redhat.com> <1404289401.14137.4.camel@unused-4-145.brq.redhat.com> <53B3C3A9.6080200@redhat.com> <53B553C7.9090307@redhat.com> <1404408844.2232.7.camel@unused-4-145.brq.redhat.com> <53B5A782.9000003@redhat.com> <1404460349.2304.0.camel@unused-4-145.brq.redhat.com> <53B67ED6.9040400@redhat.com> <1404469275.2304.3.camel@unused-4-145.brq.redhat.com> Message-ID: <53B681A9.6010908@redhat.com> On 07/04/2014 12:21 PM, Martin Basti wrote: > On Fri, 2014-07-04 at 12:15 +0200, Petr Viktorin wrote: >> On 07/04/2014 09:52 AM, Martin Basti wrote: >>> Updated patch attached >>> >> >> Almost there. >> There's a missing space in the "addifexist" ACI, quite important as the >> values are checked byte-for-byte on updates. >> >> Also, it turns out dns.ldif (which creates cn=dns) is loaded after >> updates, so a line there is needed as well. Sorry for misinformation >> I've spread offline. >> >> I tested the attached version with working ldapupdater (my patch 0615): >> upgrades and new installs, both with DNS missing and DNS installed. I >> can push if you agree with the changes. >> >> > > I agree with changes > Thanks! Pushed to master: 3461be5c78dcc77a758235dce6f0cc8e370a0310 -- Petr? From pviktori at redhat.com Fri Jul 4 10:51:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 12:51:08 +0200 Subject: [Freeipa-devel] [PATCH 0093] Restore priviledges after forward zone upgrade In-Reply-To: <53B5ADE5.4010703@redhat.com> References: <1404406816.2232.1.camel@unused-4-145.brq.redhat.com> <53B5ADE5.4010703@redhat.com> Message-ID: <53B6871C.8070709@redhat.com> On 07/03/2014 09:24 PM, Petr Spacek wrote: > On 3.7.2014 19:00, Martin Basti wrote: >> Patch attached > > Congratulations! I wasn't able to find any bug in this ;-) > > ACK from functional perspective. > > It can be pushed if there is no problem with Python side of things. > Martin, I see a lot of code like this: zone['idnsname'][0] To get a single-valued attribute, you should use: zone.single_value['idnsname'] which does a proper check that there is really only a single value. I see the old style used elsewhere in the plugin though; it should be changed everywhere, and I don't think there's immediate benefit to doing that. Just keep this in mind for the future. Pushed 0093 to master: f8b6595f4999740a704bcdae6d4f9b5021f7f61f -- Petr? From mbasti at redhat.com Fri Jul 4 10:56:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 12:56:17 +0200 Subject: [Freeipa-devel] [PATCH 0093] Restore priviledges after forward zone upgrade In-Reply-To: <53B6871C.8070709@redhat.com> References: <1404406816.2232.1.camel@unused-4-145.brq.redhat.com> <53B5ADE5.4010703@redhat.com> <53B6871C.8070709@redhat.com> Message-ID: <1404471377.2304.5.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 12:51 +0200, Petr Viktorin wrote: > On 07/03/2014 09:24 PM, Petr Spacek wrote: > > On 3.7.2014 19:00, Martin Basti wrote: > >> Patch attached > > > > Congratulations! I wasn't able to find any bug in this ;-) > > > > ACK from functional perspective. > > > > It can be pushed if there is no problem with Python side of things. > > > > > > Martin, I see a lot of code like this: > zone['idnsname'][0] > To get a single-valued attribute, you should use: > zone.single_value['idnsname'] > which does a proper check that there is really only a single value. > > I see the old style used elsewhere in the plugin though; it should be > changed everywhere, and I don't think there's immediate benefit to doing > that. Just keep this in mind for the future. > > > Pushed 0093 to master: f8b6595f4999740a704bcdae6d4f9b5021f7f61f > Thank you for the hint. If I have a time I will fix it in dns plugin(s) -- Martin^2 Basti From mbasti at redhat.com Fri Jul 4 11:10:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 13:10:55 +0200 Subject: [Freeipa-devel] [PATCH 0096-0097] Allow '/' in permission name Message-ID: <1404472255.2304.11.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4422 Classless reverse zone contains '/' which disallow to add managed permission. This should be in IPA 4.0 (If ACKed before release) IPA 3.3.5 supports classless reverse zones too. Should be this patch applied to 3.3.x too? Both patches attached (3.3 and 4.0) -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-3.3-mbasti-0097-Allow-to-add-managed-permission-for-reverse-zones.patch Type: text/x-patch Size: 10231 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0096-Allow-to-add-managed-permission-for-reverse-zones.patch Type: text/x-patch Size: 9405 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 4 11:34:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 13:34:48 +0200 Subject: [Freeipa-devel] API version conflict Message-ID: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> Hi list, I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is already used in ipa-master branch (2.66 Add support for managing user auth types). Fortunately it is very minor change so If I don't increase the version nothing happens. How to solve this problem? Don't increase the version number in ipa-3-3 anymore (?) If we will increase the IPA-3 API version to number which hits a IPA-4 capability, it could break communication between ipa3-client and ipa4-server. Should we try increase the major version sometimes? -- Martin^2 Basti From pspacek at redhat.com Fri Jul 4 11:44:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 13:44:10 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6938A.9030402@redhat.com> On 4.7.2014 13:34, Martin Basti wrote: > Hi list, > > I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is > already used in ipa-master branch (2.66 Add support for managing user > auth types). Fortunately it is very minor change so If I don't increase > the version nothing happens. > > How to solve this problem? Don't increase the version number in ipa-3-3 > anymore (?) > > If we will increase the IPA-3 API version to number which hits a IPA-4 > capability, it could break communication between ipa3-client and > ipa4-server. > > Should we try increase the major version sometimes? Or migrate to something better? :-) Linear version numbering in Ovirt/VDSM causes me a lot of pain. -- Petr^2 Spacek From mbasti at redhat.com Fri Jul 4 12:17:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 14:17:05 +0200 Subject: [Freeipa-devel] [PATCH 0096-0097] Allow '/' in permission name In-Reply-To: <1404472255.2304.11.camel@unused-4-145.brq.redhat.com> References: <1404472255.2304.11.camel@unused-4-145.brq.redhat.com> Message-ID: <1404476225.2304.26.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 13:10 +0200, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4422 > Classless reverse zone contains '/' which disallow to add managed > permission. > > This should be in IPA 4.0 (If ACKed before release) > > IPA 3.3.5 supports classless reverse zones too. Should be this patch > applied to 3.3.x too? > > Both patches attached (3.3 and 4.0) > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patches attached (Fix: cleanup permission) -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-3.3-mbasti-0097-2-Allow-to-add-managed-permission-for-reverse-zones.patch Type: text/x-patch Size: 10657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0096-2-Allow-to-add-managed-permission-for-reverse-zones.patch Type: text/x-patch Size: 9833 bytes Desc: not available URL: From pviktori at redhat.com Fri Jul 4 12:49:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 14:49:33 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users Message-ID: <53B6A2DD.8030308@redhat.com> Hello, The dns-is-enabled command, used by the Web UI to determine if DNS pages should be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in cn=masters. However, currently the service entries are not accessible to all users, so the check will fail for non-admins. We talked about this with Martin and agreed that there's no sensitive information in the service entries. This patch grants read access to all authenticated users. Simo, is this OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0616-Allow-read-access-to-services-in-cn-masters-to-auth-.patch Type: text/x-patch Size: 1477 bytes Desc: not available URL: From pspacek at redhat.com Fri Jul 4 12:55:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 14:55:01 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users In-Reply-To: <53B6A2DD.8030308@redhat.com> References: <53B6A2DD.8030308@redhat.com> Message-ID: <53B6A425.1020906@redhat.com> On 4.7.2014 14:49, Petr Viktorin wrote: > Hello, > > The dns-is-enabled command, used by the Web UI to determine if DNS pages > should be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in > cn=masters. However, currently the service entries are not accessible to all > users, so the check will fail for non-admins. > > We talked about this with Martin and agreed that there's no sensitive > information in the service entries. > This patch grants read access to all authenticated users. > > Simo, is this OK? BTW this information has to be available anyway. It will be necessary for automatic NS record management. (After all, it doesn't make sense to require user input for NS records because valid values can be simply enumerated from LDAP.) -- Petr^2 Spacek From jcholast at redhat.com Fri Jul 4 13:13:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 04 Jul 2014 15:13:09 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6A865.1000408@redhat.com> On 4.7.2014 13:34, Martin Basti wrote: > Hi list, > > I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is > already used in ipa-master branch (2.66 Add support for managing user > auth types). Fortunately it is very minor change so If I don't increase > the version nothing happens. > > How to solve this problem? Don't increase the version number in ipa-3-3 > anymore (?) > > If we will increase the IPA-3 API version to number which hits a IPA-4 > capability, it could break communication between ipa3-client and > ipa4-server. > > Should we try increase the major version sometimes? > Would 2.66.1 work? -- Jan Cholasta From mkosek at redhat.com Fri Jul 4 13:18:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 15:18:17 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6A999.1040705@redhat.com> On 07/04/2014 01:34 PM, Martin Basti wrote: > Hi list, > > I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is > already used in ipa-master branch (2.66 Add support for managing user > auth types). Fortunately it is very minor change so If I don't increase > the version nothing happens. > > How to solve this problem? Don't increase the version number in ipa-3-3 > anymore (?) > > If we will increase the IPA-3 API version to number which hits a IPA-4 > capability, it could break communication between ipa3-client and > ipa4-server. > > Should we try increase the major version sometimes? > Hmm, that's a very good question. I think that current model does not count with API changes in bug fix releases (in the branches). It also did not expect that that the Capabilities will depend on it. It seems to me that the least pain is to avoid increasing the API number in ipa-3-3 for now and think about some better scheme how to avoid this problem (I do not have an idea ATM which would not break compatibility). Martin From mbasti at redhat.com Fri Jul 4 13:20:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 15:20:03 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <53B6A865.1000408@redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> <53B6A865.1000408@redhat.com> Message-ID: <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 15:13 +0200, Jan Cholasta wrote: > On 4.7.2014 13:34, Martin Basti wrote: > > Hi list, > > > > I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is > > already used in ipa-master branch (2.66 Add support for managing user > > auth types). Fortunately it is very minor change so If I don't increase > > the version nothing happens. > > > > How to solve this problem? Don't increase the version number in ipa-3-3 > > anymore (?) > > > > If we will increase the IPA-3 API version to number which hits a IPA-4 > > capability, it could break communication between ipa3-client and > > ipa4-server. > > > > Should we try increase the major version sometimes? > > > > Would 2.66.1 work? > IMO 2.65.1, 2.65.2, .. 2.65.x and never reach 2.66, but I dont know is this possible in framework? -- Martin^2 Basti From mkosek at redhat.com Fri Jul 4 13:27:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 15:27:46 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> <53B6A865.1000408@redhat.com> <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6ABD2.10407@redhat.com> On 07/04/2014 03:20 PM, Martin Basti wrote: > On Fri, 2014-07-04 at 15:13 +0200, Jan Cholasta wrote: >> On 4.7.2014 13:34, Martin Basti wrote: >>> Hi list, >>> >>> I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is >>> already used in ipa-master branch (2.66 Add support for managing user >>> auth types). Fortunately it is very minor change so If I don't increase >>> the version nothing happens. >>> >>> How to solve this problem? Don't increase the version number in ipa-3-3 >>> anymore (?) >>> >>> If we will increase the IPA-3 API version to number which hits a IPA-4 >>> capability, it could break communication between ipa3-client and >>> ipa4-server. >>> >>> Should we try increase the major version sometimes? >>> >> >> Would 2.66.1 work? >> > > IMO 2.65.1, 2.65.2, .. 2.65.x and never reach 2.66, but I dont know is > this possible in framework? > I do not think it is. But given that we do not offer backwards compatibility with ipa commands, we can add a support in 4.0.x and support both 2.x and 2.x.y form. Please file a ticket. Thanks, Martin From pviktori at redhat.com Fri Jul 4 13:30:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 15:30:39 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> <53B6A865.1000408@redhat.com> <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6AC7F.10908@redhat.com> On 07/04/2014 03:20 PM, Martin Basti wrote: > On Fri, 2014-07-04 at 15:13 +0200, Jan Cholasta wrote: >> On 4.7.2014 13:34, Martin Basti wrote: >>> Hi list, >>> >>> I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is >>> already used in ipa-master branch (2.66 Add support for managing user >>> auth types). Fortunately it is very minor change so If I don't increase >>> the version nothing happens. >>> >>> How to solve this problem? Don't increase the version number in ipa-3-3 >>> anymore (?) >>> >>> If we will increase the IPA-3 API version to number which hits a IPA-4 >>> capability, it could break communication between ipa3-client and >>> ipa4-server. >>> >>> Should we try increase the major version sometimes? >>> >> >> Would 2.66.1 work? >> > > IMO 2.65.1, 2.65.2, .. 2.65.x and never reach 2.66, but I dont know is > this possible in framework? > The versions are (supposed to be) compared with version.LooseVersion, so this should work. There may be a case where it would break, but if we need this in ipa-3-3 it would be worth it to test. Of course, backporting new capabilities to older versions would still be impossible in this scheme. -- Petr? From pviktori at redhat.com Fri Jul 4 13:33:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 15:33:15 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <53B6AC7F.10908@redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> <53B6A865.1000408@redhat.com> <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> <53B6AC7F.10908@redhat.com> Message-ID: <53B6AD1B.7070000@redhat.com> On 07/04/2014 03:30 PM, Petr Viktorin wrote: > On 07/04/2014 03:20 PM, Martin Basti wrote: >> On Fri, 2014-07-04 at 15:13 +0200, Jan Cholasta wrote: >>> On 4.7.2014 13:34, Martin Basti wrote: >>>> Hi list, >>>> >>>> I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is >>>> already used in ipa-master branch (2.66 Add support for managing user >>>> auth types). Fortunately it is very minor change so If I don't increase >>>> the version nothing happens. >>>> >>>> How to solve this problem? Don't increase the version number in ipa-3-3 >>>> anymore (?) >>>> >>>> If we will increase the IPA-3 API version to number which hits a IPA-4 >>>> capability, it could break communication between ipa3-client and >>>> ipa4-server. >>>> >>>> Should we try increase the major version sometimes? >>>> >>> >>> Would 2.66.1 work? >>> >> >> IMO 2.65.1, 2.65.2, .. 2.65.x and never reach 2.66, but I dont know is >> this possible in framework? >> > > The versions are (supposed to be) compared with version.LooseVersion, so > this should work. > There may be a case where it would break, but if we need this in ipa-3-3 > it would be worth it to test. > > > Of course, backporting new capabilities to older versions would still be > impossible in this scheme. > BTW, the comparison code in Command.verify_client_version looks like it was written with 3+-part versions in mind: > ver = version.LooseVersion(client_version) > if len(ver.version) < 2: > raise VersionError(cver=ver.version, sver=server_ver.version, server= self.env.xmlrpc_uri) > client_major = ver.version[0] > client_minor = ver.version[1] -- Petr? From mkosek at redhat.com Fri Jul 4 13:40:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 15:40:16 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users In-Reply-To: <53B6A2DD.8030308@redhat.com> References: <53B6A2DD.8030308@redhat.com> Message-ID: <53B6AEC0.8040500@redhat.com> On 07/04/2014 02:49 PM, Petr Viktorin wrote: > Hello, > > The dns-is-enabled command, used by the Web UI to determine if DNS pages should > be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in cn=masters. > However, currently the service entries are not accessible to all users, so the > check will fail for non-admins. > > We talked about this with Martin and agreed that there's no sensitive > information in the service entries. > This patch grants read access to all authenticated users. > > Simo, is this OK? > I think this change is OK. We also only expose the service name, we do not expose any additional setting. Would it make sense though that we instead of creating an ACI for cn=masters, we would just update the 'Anonymous read access to containers' ACI and remove the 'target!="ldap:///cn=masters,cn=ipa,cn=etc,$SUFFIX"' part? Given that this ACI is in the DIT root, I would like to keep it as simple as possible for performance reasons. Martin From mbasti at redhat.com Fri Jul 4 13:44:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 15:44:40 +0200 Subject: [Freeipa-devel] API version conflict In-Reply-To: <53B6AC7F.10908@redhat.com> References: <1404473688.2304.24.camel@unused-4-145.brq.redhat.com> <53B6A865.1000408@redhat.com> <1404480003.2304.28.camel@unused-4-145.brq.redhat.com> <53B6AC7F.10908@redhat.com> Message-ID: <1404481480.2304.30.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 15:30 +0200, Petr Viktorin wrote: > On 07/04/2014 03:20 PM, Martin Basti wrote: > > On Fri, 2014-07-04 at 15:13 +0200, Jan Cholasta wrote: > >> On 4.7.2014 13:34, Martin Basti wrote: > >>> Hi list, > >>> > >>> I need increase version number in ipa-3-3 branch to 2.66, but 2.66 is > >>> already used in ipa-master branch (2.66 Add support for managing user > >>> auth types). Fortunately it is very minor change so If I don't increase > >>> the version nothing happens. > >>> > >>> How to solve this problem? Don't increase the version number in ipa-3-3 > >>> anymore (?) > >>> > >>> If we will increase the IPA-3 API version to number which hits a IPA-4 > >>> capability, it could break communication between ipa3-client and > >>> ipa4-server. > >>> > >>> Should we try increase the major version sometimes? > >>> > >> > >> Would 2.66.1 work? > >> > > > > IMO 2.65.1, 2.65.2, .. 2.65.x and never reach 2.66, but I dont know is > > this possible in framework? > > > > The versions are (supposed to be) compared with version.LooseVersion, so > this should work. > There may be a case where it would break, but if we need this in ipa-3-3 > it would be worth it to test. > > > Of course, backporting new capabilities to older versions would still be > impossible in this scheme. > To do this, we need capability to send supported capabilities to server, and it will be pain. -- Martin^2 Basti From mkosek at redhat.com Fri Jul 4 13:52:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 15:52:21 +0200 Subject: [Freeipa-devel] [PATCH] 0615 ldapupdate: Restore 'replace' functionality In-Reply-To: <53B67E7F.8000807@redhat.com> References: <53B67E7F.8000807@redhat.com> Message-ID: <53B6B195.1020808@redhat.com> On 07/04/2014 12:14 PM, Petr Viktorin wrote: > Some months ago, when working on the schema updater, I broke the 'replace' > directive in ldapupdater. Luckily the regression didn't make it to a released > version. > > Here is a fix. Good catch! Oh, the memories when I look at my old enhanced schema updater being removed again :-) The replace OP is back now, works fine. ACK. Pushed to master: 2f99140c92f05c9ff11ff57002cb87784c632091 Martin From pviktori at redhat.com Fri Jul 4 13:55:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 15:55:46 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users In-Reply-To: <53B6AEC0.8040500@redhat.com> References: <53B6A2DD.8030308@redhat.com> <53B6AEC0.8040500@redhat.com> Message-ID: <53B6B262.8070306@redhat.com> On 07/04/2014 03:40 PM, Martin Kosek wrote: > On 07/04/2014 02:49 PM, Petr Viktorin wrote: >> Hello, >> >> The dns-is-enabled command, used by the Web UI to determine if DNS >> pages should >> be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in >> cn=masters. >> However, currently the service entries are not accessible to all >> users, so the >> check will fail for non-admins. >> >> We talked about this with Martin and agreed that there's no sensitive >> information in the service entries. >> This patch grants read access to all authenticated users. >> >> Simo, is this OK? >> > > I think this change is OK. We also only expose the service name, we do > not expose any additional setting. > > Would it make sense though that we instead of creating an ACI for > cn=masters, we would just update the 'Anonymous read access to > containers' ACI and remove the > 'target!="ldap:///cn=masters,cn=ipa,cn=etc,$SUFFIX"' part? That would grant *anonymous* access the masters & services. Do we want that? > Given that this ACI is in the DIT root, I would like to keep it as > simple as possible for performance reasons. -- Petr? From mkosek at redhat.com Fri Jul 4 14:02:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 16:02:10 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users In-Reply-To: <53B6B262.8070306@redhat.com> References: <53B6A2DD.8030308@redhat.com> <53B6AEC0.8040500@redhat.com> <53B6B262.8070306@redhat.com> Message-ID: <53B6B3E2.1010305@redhat.com> On 07/04/2014 03:55 PM, Petr Viktorin wrote: > On 07/04/2014 03:40 PM, Martin Kosek wrote: >> On 07/04/2014 02:49 PM, Petr Viktorin wrote: >>> Hello, >>> >>> The dns-is-enabled command, used by the Web UI to determine if DNS >>> pages should >>> be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in >>> cn=masters. >>> However, currently the service entries are not accessible to all >>> users, so the >>> check will fail for non-admins. >>> >>> We talked about this with Martin and agreed that there's no sensitive >>> information in the service entries. >>> This patch grants read access to all authenticated users. >>> >>> Simo, is this OK? >>> >> >> I think this change is OK. We also only expose the service name, we do >> not expose any additional setting. >> >> Would it make sense though that we instead of creating an ACI for >> cn=masters, we would just update the 'Anonymous read access to >> containers' ACI and remove the >> 'target!="ldap:///cn=masters,cn=ipa,cn=etc,$SUFFIX"' part? > > That would grant *anonymous* access the masters & services. Do we want that? Hmm, no, I do not think this we want to do that. Your change looks good to me then. Besides others, it fixes https://fedorahosted.org/freeipa/ticket/4425 so I added it to patch description. ACK. Pushed to master: 23feb4e0271d6876e2137f301f209a9f3af19084 Martin From pspacek at redhat.com Fri Jul 4 14:03:58 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 16:03:58 +0200 Subject: [Freeipa-devel] [PATCH 0096-0097] Allow '/' in permission name In-Reply-To: <1404476225.2304.26.camel@unused-4-145.brq.redhat.com> References: <1404472255.2304.11.camel@unused-4-145.brq.redhat.com> <1404476225.2304.26.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6B44E.6060007@redhat.com> On 4.7.2014 14:17, Martin Basti wrote: > On Fri, 2014-07-04 at 13:10 +0200, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4422 >> Classless reverse zone contains '/' which disallow to add managed >> permission. >> >> This should be in IPA 4.0 (If ACKed before release) >> >> IPA 3.3.5 supports classless reverse zones too. Should be this patch >> applied to 3.3.x too? >> >> Both patches attached (3.3 and 4.0) >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Updated patches attached (Fix: cleanup permission) ACK from functional perspective. It can be pushed if there is no problem on Python side of things. -- Petr^2 Spacek From mkosek at redhat.com Fri Jul 4 14:07:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 16:07:54 +0200 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure In-Reply-To: <53B55565.5080006@redhat.com> References: <53B413B5.7050503@redhat.com> <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> <53B55565.5080006@redhat.com> Message-ID: <53B6B53A.80902@redhat.com> On 07/03/2014 03:06 PM, Petr Vobornik wrote: > On 3.7.2014 08:13, Fraser Tweedale wrote: >> On Wed, Jul 02, 2014 at 04:14:13PM +0200, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/4418 >>> >>> according to latest >>> proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html >>> -- >>> Petr Vobornik >> >> Haven't run the webui tests but lines up with the proposal and looks >> very nice! >> >> ACK if webui tests pass. > > I've run the complete test suite and discovered that I forgot to modify 2 other > tests. Also there was an existing fail in test_navigation in DNS-less > installation. > > All fixed, updated patch attached. I checked the menu, it looks OK. Now even the DNS page is fixed. So similarly to Fraser - ACK if Web UI tests pass (I cannot run them ATM). Martin From pspacek at redhat.com Fri Jul 4 14:08:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 16:08:36 +0200 Subject: [Freeipa-devel] [PATCH] 0616 Allow read access to services in cn=masters to auth'd users In-Reply-To: <53B6A2DD.8030308@redhat.com> References: <53B6A2DD.8030308@redhat.com> Message-ID: <53B6B564.4070505@redhat.com> On 4.7.2014 14:49, Petr Viktorin wrote: > Hello, > > The dns-is-enabled command, used by the Web UI to determine if DNS pages > should be displayed, queries '(&(objectClass=ipaConfigObject)(cn=DNS))' in > cn=masters. However, currently the service entries are not accessible to all > users, so the check will fail for non-admins. > > We talked about this with Martin and agreed that there's no sensitive > information in the service entries. > This patch grants read access to all authenticated users. > > Simo, is this OK? This patch fixes https://fedorahosted.org/freeipa/ticket/4425 for me. -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 4 14:10:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 16:10:31 +0200 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure In-Reply-To: <53B6B53A.80902@redhat.com> References: <53B413B5.7050503@redhat.com> <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> <53B55565.5080006@redhat.com> <53B6B53A.80902@redhat.com> Message-ID: <53B6B5D7.1030707@redhat.com> On 4.7.2014 16:07, Martin Kosek wrote: > On 07/03/2014 03:06 PM, Petr Vobornik wrote: >> On 3.7.2014 08:13, Fraser Tweedale wrote: >>> On Wed, Jul 02, 2014 at 04:14:13PM +0200, Petr Vobornik wrote: >>>> https://fedorahosted.org/freeipa/ticket/4418 >>>> >>>> according to latest >>>> proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html >>>> -- >>>> Petr Vobornik >>> >>> Haven't run the webui tests but lines up with the proposal and looks >>> very nice! >>> >>> ACK if webui tests pass. >> >> I've run the complete test suite and discovered that I forgot to modify 2 other >> tests. Also there was an existing fail in test_navigation in DNS-less >> installation. >> >> All fixed, updated patch attached. > > I checked the menu, it looks OK. Now even the DNS page is fixed. So similarly > to Fraser - ACK if Web UI tests pass (I cannot run them ATM). I works for me too, triple-ACK! :-) -- Petr^2 Spacek From pviktori at redhat.com Fri Jul 4 14:11:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 16:11:20 +0200 Subject: [Freeipa-devel] [PATCH 0096-0097] Allow '/' in permission name In-Reply-To: <53B6B44E.6060007@redhat.com> References: <1404472255.2304.11.camel@unused-4-145.brq.redhat.com> <1404476225.2304.26.camel@unused-4-145.brq.redhat.com> <53B6B44E.6060007@redhat.com> Message-ID: <53B6B608.40003@redhat.com> On 07/04/2014 04:03 PM, Petr Spacek wrote: > On 4.7.2014 14:17, Martin Basti wrote: >> On Fri, 2014-07-04 at 13:10 +0200, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4422 >>> Classless reverse zone contains '/' which disallow to add managed >>> permission. >>> >>> This should be in IPA 4.0 (If ACKed before release) >>> >>> IPA 3.3.5 supports classless reverse zones too. Should be this patch >>> applied to 3.3.x too? >>> >>> Both patches attached (3.3 and 4.0) >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Updated patches attached (Fix: cleanup permission) > > ACK from functional perspective. > > It can be pushed if there is no problem on Python side of things. > I've just finished testing this as well. Full ACK to the 4.0 version. For the 3.3 one there's a discussion about branching API_VERSION in another thread. Pushed to master: 2637116eab51be16c33745d51f284aaee0c57ae1 -- Petr? From pspacek at redhat.com Fri Jul 4 14:12:22 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 16:12:22 +0200 Subject: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses In-Reply-To: <53B55AFF.2040905@redhat.com> References: <53B55AFF.2040905@redhat.com> Message-ID: <53B6B646.6080601@redhat.com> On 3.7.2014 15:30, Petr Vobornik wrote: > API responses can contain warnings in "messages" array. This patch > also adds support for displaying multiple notifications at the same > time in order to show the message and a status of finished operation. > > Notes: > - was implemented because of > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 > --> test by modifying Master DNS Zone which has a Zone forwarder set. > - I'd like to move the notification code to separate module in a future and > then extend it according to PatternFly pattern which is currently under > developemnt (should contain history, ...). ACK from functional perspective. It properly displays warnings about DNS zones and DNSSEC. It can be pushed if there is no problem in the code, I can't really check that. -- Petr^2 Spacek From mbasti at redhat.com Fri Jul 4 14:14:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 16:14:54 +0200 Subject: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses In-Reply-To: <53B6B646.6080601@redhat.com> References: <53B55AFF.2040905@redhat.com> <53B6B646.6080601@redhat.com> Message-ID: <1404483294.2304.31.camel@unused-4-145.brq.redhat.com> On Fri, 2014-07-04 at 16:12 +0200, Petr Spacek wrote: > On 3.7.2014 15:30, Petr Vobornik wrote: > > API responses can contain warnings in "messages" array. This patch > > also adds support for displaying multiple notifications at the same > > time in order to show the message and a status of finished operation. > > > > Notes: > > - was implemented because of > > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 > > --> test by modifying Master DNS Zone which has a Zone forwarder set. > > - I'd like to move the notification code to separate module in a future and > > then extend it according to PatternFly pattern which is currently under > > developemnt (should contain history, ...). > > ACK from functional perspective. It properly displays warnings about DNS zones > and DNSSEC. > > It can be pushed if there is no problem in the code, I can't really check that. > Was there any problem with hardcoded '/n' in warning message text? -- Martin^2 Basti From pspacek at redhat.com Fri Jul 4 14:18:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 16:18:09 +0200 Subject: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses In-Reply-To: <1404483294.2304.31.camel@unused-4-145.brq.redhat.com> References: <53B55AFF.2040905@redhat.com> <53B6B646.6080601@redhat.com> <1404483294.2304.31.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6B7A1.7060009@redhat.com> On 4.7.2014 16:14, Martin Basti wrote: > On Fri, 2014-07-04 at 16:12 +0200, Petr Spacek wrote: >> On 3.7.2014 15:30, Petr Vobornik wrote: >>> API responses can contain warnings in "messages" array. This patch >>> also adds support for displaying multiple notifications at the same >>> time in order to show the message and a status of finished operation. >>> >>> Notes: >>> - was implemented because of >>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 >>> --> test by modifying Master DNS Zone which has a Zone forwarder set. >>> - I'd like to move the notification code to separate module in a future and >>> then extend it according to PatternFly pattern which is currently under >>> developemnt (should contain history, ...). >> >> ACK from functional perspective. It properly displays warnings about DNS zones >> and DNSSEC. >> >> It can be pushed if there is no problem in the code, I can't really check that. >> > > Was there any problem with hardcoded '/n' in warning message text? It works for me - the text is wrapped, I don't see any glitch. -- Petr^2 Spacek From pvoborni at redhat.com Fri Jul 4 14:34:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Jul 2014 16:34:15 +0200 Subject: [Freeipa-devel] [PATCH] 694 webui: new navigation structure In-Reply-To: <53B6B5D7.1030707@redhat.com> References: <53B413B5.7050503@redhat.com> <20140703061317.GU2417@dhcp-40-8.bne.redhat.com> <53B55565.5080006@redhat.com> <53B6B53A.80902@redhat.com> <53B6B5D7.1030707@redhat.com> Message-ID: <53B6BB67.3030303@redhat.com> On 4.7.2014 16:10, Petr Spacek wrote: > On 4.7.2014 16:07, Martin Kosek wrote: >> On 07/03/2014 03:06 PM, Petr Vobornik wrote: >>> On 3.7.2014 08:13, Fraser Tweedale wrote: >>>> On Wed, Jul 02, 2014 at 04:14:13PM +0200, Petr Vobornik wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4418 >>>>> >>>>> according to latest >>>>> proposal:http://www.redhat.com/archives/freeipa-devel/2014-June/msg00839.html >>>>> >>>>> -- >>>>> Petr Vobornik >>>> >>>> Haven't run the webui tests but lines up with the proposal and looks >>>> very nice! >>>> >>>> ACK if webui tests pass. >>> >>> I've run the complete test suite and discovered that I forgot to >>> modify 2 other >>> tests. Also there was an existing fail in test_navigation in DNS-less >>> installation. >>> >>> All fixed, updated patch attached. >> >> I checked the menu, it looks OK. Now even the DNS page is fixed. So >> similarly >> to Fraser - ACK if Web UI tests pass (I cannot run them ATM). > > I works for me too, triple-ACK! :-) > Tests pass for me. Pushed to master: 0b0e77cf99b38cfd958a82caad715511c91f9ee3 -- Petr Vobornik From mbasti at redhat.com Fri Jul 4 14:34:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Jul 2014 16:34:18 +0200 Subject: [Freeipa-devel] [PATCH 0098-0100] DNS tests Message-ID: <1404484458.2304.33.camel@unused-4-145.brq.redhat.com> Just tests to avoid regressions in future. Patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0098-Test-DNS-test-zone-normalization.patch Type: text/x-patch Size: 3350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0099-Test-DNS-TLSA-record.patch Type: text/x-patch Size: 3412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0100-Test-DNS-add-zone-with-consecutive-dash-characters.patch Type: text/x-patch Size: 3437 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 4 14:43:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 16:43:23 +0200 Subject: [Freeipa-devel] [PATCH] 478 Prepare spec for 4.0 release Message-ID: <53B6BD8B.8090202@redhat.com> - Bump 389-ds-base requires to fix the deref call with new ACIs: https://fedorahosted.org/freeipa/ticket/4389 - Bump bind-dyndb-ldap Conflicts to fetch the DNSSEC capability - Bump selinux-policy to fix the CRL retrieval: https://fedorahosted.org/freeipa/ticket/4369 - Remove conditionals for Fedora < 20 as FreeIPA 4.0 is not planned to be released on these platforms. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-478-prepare-spec-for-4.0-release.patch Type: text/x-patch Size: 5108 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 4 14:57:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 16:57:18 +0200 Subject: [Freeipa-devel] Ready to release? Message-ID: <53B6C0CE.5000008@redhat.com> Hello developers! I would like to thank everyone for the hard work during the last weeks, when finishing the FreeIPA 4.0 release, I saw many last stabilization fixes in DNS, OTP, ACIs, upgrade and Web UI areas. The last major work that is still not pushed is the CA management tool. Unfortunately, the final development and review did not go so well and we still do not have final patches. Given that this is a major piece of work (>50 patches) and given that the reviewer is on a leave, I am considering moving the feature to next release - FreeIPA 4.1 which is short and would still make it to Fedora 21. I would not like to stall 4.0 any more, I would like to offer all the work we have done for wider testing as soon as possible. Thoughts? Any other last patches you would like to add to add to 4.0 GA? There is still little time, but remember, git tag hammer is ready to fire. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Fri Jul 4 15:13:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 17:13:35 +0200 Subject: [Freeipa-devel] Release platforms for 4.0 Message-ID: <53B6C49F.5020500@redhat.com> Given that Fedora 20 is now in stable phase and FreeIPA 4.0 adds a lot of functionality, we agreed that we will not publish FreeIPA 4.0 in stable Fedora 20 updates now. When releasing 4.0, we need to: 1) Prepare a COPR build for Fedora 20 with all dependencies that are not in Fedora 20 yet. AFAIK, it should be just FreeIPA as new bind-dyndb-ldap and 389-ds-base are in updates-testing. 2) Prepare Fedora 21 build. It may not be so simple, there may be issues with other software or dependencies - we may need to patch FreeIPA or file bugs right away. Petr3, as you plan to do the release, please drive these 2 efforts. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Fri Jul 4 15:20:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 17:20:13 +0200 Subject: [Freeipa-devel] Ready to release? In-Reply-To: <53B6C0CE.5000008@redhat.com> References: <53B6C0CE.5000008@redhat.com> Message-ID: <53B6C62D.30201@redhat.com> On 07/04/2014 04:57 PM, Martin Kosek wrote: > Hello developers! > > I would like to thank everyone for the hard work during the last weeks, > when finishing the FreeIPA 4.0 release, I saw many last stabilization > fixes in DNS, OTP, ACIs, upgrade and Web UI areas. > > The last major work that is still not pushed is the CA management tool. > Unfortunately, the final development and review did not go so well and > we still do not have final patches. > > Given that this is a major piece of work (>50 patches) and given that > the reviewer is on a leave, I am considering moving the feature to next > release - FreeIPA 4.1 which is short and would still make it to Fedora > 21. I would not like to stall 4.0 any more, I would like to offer all > the work we have done for wider testing as soon as possible. > > Thoughts? Any other last patches you would like to add to add to 4.0 GA? > There is still little time, but remember, git tag hammer is ready to fire. I'm testing these two: - mbasti-0098-100, DNS tests - mkosek-478, Spec bump Then there's pvoborni-695 with only a functional ACK The CA management is still up for discussion, but it's more and more likely that it'll slip. If you have an opinion, let it be heard. Finally, I'd like to update translations one more time, since we made quite a large change very late. That should be it. If you'd like to include a patch that you don't see here, shout now. -- Petr? From jhrozek at redhat.com Fri Jul 4 15:21:56 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Jul 2014 17:21:56 +0200 Subject: [Freeipa-devel] Release platforms for 4.0 In-Reply-To: <53B6C49F.5020500@redhat.com> References: <53B6C49F.5020500@redhat.com> Message-ID: <20140704152156.GF23169@hendrix.brq.redhat.com> On Fri, Jul 04, 2014 at 05:13:35PM +0200, Martin Kosek wrote: > Given that Fedora 20 is now in stable phase and FreeIPA 4.0 adds a lot of > functionality, we agreed that we will not publish FreeIPA 4.0 in stable > Fedora 20 updates now. > > When releasing 4.0, we need to: > 1) Prepare a COPR build for Fedora 20 with all dependencies that are not in > Fedora 20 yet. AFAIK, it should be just FreeIPA as new bind-dyndb-ldap and > 389-ds-base are in updates-testing. Note: I assume we'll want to include SSSD 1.12 to this repo as well. We need to remember to add the latest ding-libs release, too, as stock F-20 ding-libs don't provide all the functionality the latest SSSD requires. From mkosek at redhat.com Fri Jul 4 15:26:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 17:26:37 +0200 Subject: [Freeipa-devel] git branching after 4.0 Message-ID: <53B6C7AD.4010803@redhat.com> When 4.0 releases, there will be several development trains that we will need to manage in our git: 1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to ipa-4-0 branch 2) FreeIPA 4.1 "small" development - 4.1 will be just a short release for the summer focused on Views, full support of DNSSEC, OTP local high watermark, Backup and Restore and other small features (and possibly also CA management tool). 3) FreeIPA 4.2 big development - this is a longer, more in the future (read Fedora 22 time frame) development with major features going in - Vault, User provisioning, publishing CA certs to clients and many others stuff still being scoped. It will include for example big updates to installers which should not go to more stable 4.1/4.0.x releases. How to handle that in git repo? Given that we do not do merge commits, I think the easiest way would be to: - When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will leave us with master, ipa-4-1, ipa-4-0 active branches - 4.2 team will commit their work to master only - 4.1 team will commit their work to master, ipa-4-1 - 4.0.x bugfixing team will commit their work to master, ipa-4-1 and ipa-4-0 This may sound complicated, but with Petr's ipatool pushing to multiple branches should be easy. Our CI should guard at least ipa-4-0 and ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to report failures early. If there is a better idea, please propose it. But this plan seemed to me as the most straightforward. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pspacek at redhat.com Fri Jul 4 15:34:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Jul 2014 17:34:07 +0200 Subject: [Freeipa-devel] Ready to release? In-Reply-To: <53B6C62D.30201@redhat.com> References: <53B6C0CE.5000008@redhat.com> <53B6C62D.30201@redhat.com> Message-ID: <53B6C96F.6050905@redhat.com> On 4.7.2014 17:20, Petr Viktorin wrote: > On 07/04/2014 04:57 PM, Martin Kosek wrote: >> Hello developers! >> >> I would like to thank everyone for the hard work during the last weeks, >> when finishing the FreeIPA 4.0 release, I saw many last stabilization >> fixes in DNS, OTP, ACIs, upgrade and Web UI areas. >> >> The last major work that is still not pushed is the CA management tool. >> Unfortunately, the final development and review did not go so well and >> we still do not have final patches. >> >> Given that this is a major piece of work (>50 patches) and given that >> the reviewer is on a leave, I am considering moving the feature to next >> release - FreeIPA 4.1 which is short and would still make it to Fedora >> 21. I would not like to stall 4.0 any more, I would like to offer all >> the work we have done for wider testing as soon as possible. >> >> Thoughts? Any other last patches you would like to add to add to 4.0 GA? >> There is still little time, but remember, git tag hammer is ready to fire. > > I'm testing these two: > - mbasti-0098-100, DNS tests > - mkosek-478, Spec bump > > Then there's pvoborni-695 with only a functional ACK > > The CA management is still up for discussion, but it's more and more likely We have deferred 'full' DNSSEC support already so it is not unprecedented. I have one proposal (valid only if we decide to defer CA management): Maybe we could release 4.1 in few weeks when DNSSEC and CA management are done & properly reviewed. That would allow us to follow 'release early, release often' lore. In my opinion, smaller release = safer. Of course, it would mean shifting current version numbers from 4.x to 4.(x+1), sorry Martin! :-) -- Petr^2 Spacek From pviktori at redhat.com Fri Jul 4 16:37:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 18:37:41 +0200 Subject: [Freeipa-devel] git branching after 4.0 In-Reply-To: <53B6C7AD.4010803@redhat.com> References: <53B6C7AD.4010803@redhat.com> Message-ID: <53B6D855.2090102@redhat.com> I'm afraid this mail is not very clear for people who didn't participate in discussions behind these plans. The planning of future work is of course Red Hat specific -- we can't dictate how others spend their time. Read our plans as "here's roughly what we want to do, does it fit in with your plans?" Let me provide a few links and clarifications so everyone can follow along or join in! On 07/04/2014 05:26 PM, Martin Kosek wrote: > When 4.0 releases, there will be several development trains that we will > need to manage in our git: > > 1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to > ipa-4-0 branch Milestones are here: https://fedorahosted.org/freeipa/report/3 > 2) FreeIPA 4.1 "small" development - 4.1 will be just a short release > for the summer focused on Views, full support of DNSSEC, OTP local high > watermark, Backup and Restore and other small features (and possibly > also CA management tool). > > 3) FreeIPA 4.2 big development - this is a longer, more in the future > (read Fedora 22 time frame) development with major features going in - > Vault, User provisioning, publishing CA certs to clients and many others > stuff still being scoped. It will include for example big updates to > installers which should not go to more stable 4.1/4.0.x releases. > > How to handle that in git repo? Given that we do not do merge commits, I > think the easiest way would be to: > > - When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will > leave us with master, ipa-4-1, ipa-4-0 active branches > - 4.2 team will commit their work to master only > - 4.1 team will commit their work to master, ipa-4-1 > - 4.0.x bugfixing team will commit their work to master, ipa-4-1 and > ipa-4-0 +1 We just need to make sure the work won't overlap too much. > This may sound complicated, but with Petr's ipatool pushing to multiple > branches should be easy. Our CI should guard at least ipa-4-0 and > ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to > report failures early. My ipatool is available here: https://github.com/encukou/ipa-tools/ -- it's automation for some of the processes described at and around http://www.freeipa.org/page/Contribute "Our CI" here means a Jenkins instance in Red Hat's internal lab. We're sorry it's not visible yet -- too much other work to do :( The configuration is available, though (https://github.com/encukou/freeipa-ci), and I'd be happy to help if you'd like to set up a CI machine. > If there is a better idea, please propose it. But this plan seemed to me > as the most straightforward. -- Petr? From pviktori at redhat.com Fri Jul 4 16:39:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 18:39:34 +0200 Subject: [Freeipa-devel] [PATCH] 478 Prepare spec for 4.0 release In-Reply-To: <53B6BD8B.8090202@redhat.com> References: <53B6BD8B.8090202@redhat.com> Message-ID: <53B6D8C6.50403@redhat.com> On 07/04/2014 04:43 PM, Martin Kosek wrote: > - Bump 389-ds-base requires to fix the deref call with new ACIs: > https://fedorahosted.org/freeipa/ticket/4389 > - Bump bind-dyndb-ldap Conflicts to fetch the DNSSEC capability > - Bump selinux-policy to fix the CRL retrieval: > https://fedorahosted.org/freeipa/ticket/4369 > - Remove conditionals for Fedora < 20 as FreeIPA 4.0 is not planned > to be released on these platforms. [...] > -%if 0%{?fedora} == 18 > Requires: nss >= 3.14.3-2 > Requires: nss-tools >= 3.14.3-2 > -%else > -Requires: nss >= 3.14.3-12.0 > -Requires: nss-tools >= 3.14.3-12.0 > -%endif NACK, you left the "== 18" block in. Attaching fix, I can push if you agree. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-478+pviktori-prepare-spec-for-4.0-release.patch Type: text/x-patch Size: 5108 bytes Desc: not available URL: From pviktori at redhat.com Fri Jul 4 16:46:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 18:46:19 +0200 Subject: [Freeipa-devel] [PATCH 0098-0100] DNS tests In-Reply-To: <1404484458.2304.33.camel@unused-4-145.brq.redhat.com> References: <1404484458.2304.33.camel@unused-4-145.brq.redhat.com> Message-ID: <53B6DA5B.3090702@redhat.com> On 07/04/2014 04:34 PM, Martin Basti wrote: > Just tests to avoid regressions in future. > > Patches attached ACK, pushed to master: 80cb95da36215a4d0132d943536a3c6f399c18a7 -- Petr? From mkosek at redhat.com Fri Jul 4 16:57:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Jul 2014 18:57:00 +0200 Subject: [Freeipa-devel] [PATCH] 478 Prepare spec for 4.0 release In-Reply-To: <53B6D8C6.50403@redhat.com> References: <53B6BD8B.8090202@redhat.com> <53B6D8C6.50403@redhat.com> Message-ID: <53B6DCDC.2000507@redhat.com> On 07/04/2014 06:39 PM, Petr Viktorin wrote: > On 07/04/2014 04:43 PM, Martin Kosek wrote: >> - Bump 389-ds-base requires to fix the deref call with new ACIs: >> https://fedorahosted.org/freeipa/ticket/4389 >> - Bump bind-dyndb-ldap Conflicts to fetch the DNSSEC capability >> - Bump selinux-policy to fix the CRL retrieval: >> https://fedorahosted.org/freeipa/ticket/4369 >> - Remove conditionals for Fedora < 20 as FreeIPA 4.0 is not planned >> to be released on these platforms. > > > [...] >> -%if 0%{?fedora} == 18 >> Requires: nss >= 3.14.3-2 >> Requires: nss-tools >= 3.14.3-2 >> -%else >> -Requires: nss >= 3.14.3-12.0 >> -Requires: nss-tools >= 3.14.3-12.0 >> -%endif > > NACK, you left the "== 18" block in. > > Attaching fix, I can push if you agree. Sure, agreed. Martin From pviktori at redhat.com Fri Jul 4 16:57:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Jul 2014 18:57:58 +0200 Subject: [Freeipa-devel] [PATCH] 478 Prepare spec for 4.0 release In-Reply-To: <53B6DCDC.2000507@redhat.com> References: <53B6BD8B.8090202@redhat.com> <53B6D8C6.50403@redhat.com> <53B6DCDC.2000507@redhat.com> Message-ID: <53B6DD16.2020002@redhat.com> On 07/04/2014 06:57 PM, Martin Kosek wrote: > On 07/04/2014 06:39 PM, Petr Viktorin wrote: >> On 07/04/2014 04:43 PM, Martin Kosek wrote: >>> - Bump 389-ds-base requires to fix the deref call with new ACIs: >>> https://fedorahosted.org/freeipa/ticket/4389 >>> - Bump bind-dyndb-ldap Conflicts to fetch the DNSSEC capability >>> - Bump selinux-policy to fix the CRL retrieval: >>> https://fedorahosted.org/freeipa/ticket/4369 >>> - Remove conditionals for Fedora < 20 as FreeIPA 4.0 is not planned >>> to be released on these platforms. >> >> >> [...] >>> -%if 0%{?fedora} == 18 >>> Requires: nss >= 3.14.3-2 >>> Requires: nss-tools >= 3.14.3-2 >>> -%else >>> -Requires: nss >= 3.14.3-12.0 >>> -Requires: nss-tools >= 3.14.3-12.0 >>> -%endif >> >> NACK, you left the "== 18" block in. >> >> Attaching fix, I can push if you agree. > > Sure, agreed. > > Martin Pushed to master: 5434851efd394c27ab6445a4b7544767452e20a5 -- Petr? From pspacek at redhat.com Mon Jul 7 07:13:25 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 07 Jul 2014 09:13:25 +0200 Subject: [Freeipa-devel] Release platforms for 4.0 In-Reply-To: <53B6C49F.5020500@redhat.com> References: <53B6C49F.5020500@redhat.com> Message-ID: <53BA4895.5010402@redhat.com> On 4.7.2014 17:13, Martin Kosek wrote: > Given that Fedora 20 is now in stable phase and FreeIPA 4.0 adds a lot of > functionality, we agreed that we will not publish FreeIPA 4.0 in stable Fedora > 20 updates now. > > When releasing 4.0, we need to: > 1) Prepare a COPR build for Fedora 20 with all dependencies that are not in > Fedora 20 yet. AFAIK, it should be just FreeIPA as new bind-dyndb-ldap and > 389-ds-base are in updates-testing. > > 2) Prepare Fedora 21 build. It may not be so simple, there may be issues with > other software or dependencies - we may need to patch FreeIPA or file bugs > right away. I did some very basic testing on Rawhide: Build & installation worked for me without any change to code. Very basic functionality (installation, WebUI, DNS) is working. I didn't test neither OTP nor Trusts. -- Petr^2 Spacek From pviktori at redhat.com Mon Jul 7 07:42:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 09:42:43 +0200 Subject: [Freeipa-devel] [PATCH] 0617 makeaci: Use the DN where the ACI is stored, not the permission's DN Message-ID: <53BA4F73.3030406@redhat.com> Hello, One last patch I'd like to get in before the fork. I noticed ACI.txt file is not as helpful as it could be because it lists the permission's DN, not the DN where the ACI is. Here's the fix. One-liner (if you don't count ACI.txt), and doesn't touch installed code. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0617-makeaci-Use-the-DN-where-the-ACI-is-stored-not-the-p.patch Type: text/x-patch Size: 58572 bytes Desc: not available URL: From mbasti at redhat.com Mon Jul 7 09:55:45 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 07 Jul 2014 11:55:45 +0200 Subject: [Freeipa-devel] [PATCH] 0617 makeaci: Use the DN where the ACI is stored, not the permission's DN In-Reply-To: <53BA4F73.3030406@redhat.com> References: <53BA4F73.3030406@redhat.com> Message-ID: <1404726945.2296.0.camel@unused-4-145.brq.redhat.com> On Mon, 2014-07-07 at 09:42 +0200, Petr Viktorin wrote: > Hello, > > One last patch I'd like to get in before the fork. > I noticed ACI.txt file is not as helpful as it could be because it lists > the permission's DN, not the DN where the ACI is. > Here's the fix. One-liner (if you don't count ACI.txt), and doesn't > touch installed code. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, it works for me -- Martin^2 Basti From pviktori at redhat.com Mon Jul 7 12:43:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 14:43:17 +0200 Subject: [Freeipa-devel] [PATCH] 0617 makeaci: Use the DN where the ACI is stored, not the permission's DN In-Reply-To: <1404726945.2296.0.camel@unused-4-145.brq.redhat.com> References: <53BA4F73.3030406@redhat.com> <1404726945.2296.0.camel@unused-4-145.brq.redhat.com> Message-ID: <53BA95E5.9020106@redhat.com> On 07/07/2014 11:55 AM, Martin Basti wrote: > On Mon, 2014-07-07 at 09:42 +0200, Petr Viktorin wrote: >> Hello, >> >> One last patch I'd like to get in before the fork. >> I noticed ACI.txt file is not as helpful as it could be because it lists >> the permission's DN, not the DN where the ACI is. >> Here's the fix. One-liner (if you don't count ACI.txt), and doesn't >> touch installed code. > ACK, it works for me > Thanks! Pushed to master: afe067b1ab9b224080ca05b906e9dfd50c40c59b -- Petr? From jcholast at redhat.com Mon Jul 7 13:23:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 07 Jul 2014 15:23:07 +0200 Subject: [Freeipa-devel] Ready to release? In-Reply-To: <53B6C96F.6050905@redhat.com> References: <53B6C0CE.5000008@redhat.com> <53B6C62D.30201@redhat.com> <53B6C96F.6050905@redhat.com> Message-ID: <53BA9F3B.2040500@redhat.com> Hi, On 4.7.2014 17:34, Petr Spacek wrote: > On 4.7.2014 17:20, Petr Viktorin wrote: >> On 07/04/2014 04:57 PM, Martin Kosek wrote: >>> Hello developers! >>> >>> I would like to thank everyone for the hard work during the last weeks, >>> when finishing the FreeIPA 4.0 release, I saw many last stabilization >>> fixes in DNS, OTP, ACIs, upgrade and Web UI areas. >>> >>> The last major work that is still not pushed is the CA management tool. >>> Unfortunately, the final development and review did not go so well and >>> we still do not have final patches. >>> >>> Given that this is a major piece of work (>50 patches) and given that >>> the reviewer is on a leave, I am considering moving the feature to next >>> release - FreeIPA 4.1 which is short and would still make it to Fedora >>> 21. I would not like to stall 4.0 any more, I would like to offer all >>> the work we have done for wider testing as soon as possible. >>> >>> Thoughts? Any other last patches you would like to add to add to 4.0 GA? >>> There is still little time, but remember, git tag hammer is ready to >>> fire. >> >> I'm testing these two: >> - mbasti-0098-100, DNS tests >> - mkosek-478, Spec bump >> >> Then there's pvoborni-695 with only a functional ACK >> >> The CA management is still up for discussion, but it's more and more >> likely > > We have deferred 'full' DNSSEC support already so it is not unprecedented. > > I have one proposal (valid only if we decide to defer CA management): > > Maybe we could release 4.1 in few weeks when DNSSEC and CA management > are done & properly reviewed. > > That would allow us to follow 'release early, release often' lore. In my > opinion, smaller release = safer. > > Of course, it would mean shifting current version numbers from 4.x to > 4.(x+1), sorry Martin! :-) > I'm fine with deferring CA management. I could fix the remaining issues in time, but Rob, who is reviewing the patches, is on PTO and IMO the code could use some more testing before releasing it into the wild. Honza -- Jan Cholasta From pviktori at redhat.com Mon Jul 7 13:30:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 15:30:55 +0200 Subject: [Freeipa-devel] [PATCH] 695 webui: display messages contained in API responses In-Reply-To: <53B6B7A1.7060009@redhat.com> References: <53B55AFF.2040905@redhat.com> <53B6B646.6080601@redhat.com> <1404483294.2304.31.camel@unused-4-145.brq.redhat.com> <53B6B7A1.7060009@redhat.com> Message-ID: <53BAA10F.3040507@redhat.com> On 07/04/2014 04:18 PM, Petr Spacek wrote: > On 4.7.2014 16:14, Martin Basti wrote: >> On Fri, 2014-07-04 at 16:12 +0200, Petr Spacek wrote: >>> On 3.7.2014 15:30, Petr Vobornik wrote: >>>> API responses can contain warnings in "messages" array. This patch >>>> also adds support for displaying multiple notifications at the same >>>> time in order to show the message and a status of finished operation. >>>> >>>> Notes: >>>> - was implemented because of >>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=33cf958b98dc2d80d17b3de1c145d403df4a3ba3 >>>> >>>> --> test by modifying Master DNS Zone which has a Zone forwarder set. >>>> - I'd like to move the notification code to separate module in a >>>> future and >>>> then extend it according to PatternFly pattern which is currently under >>>> developemnt (should contain history, ...). >>> >>> ACK from functional perspective. It properly displays warnings about >>> DNS zones >>> and DNSSEC. >>> >>> It can be pushed if there is no problem in the code, I can't really >>> check that. >>> >> >> Was there any problem with hardcoded '/n' in warning message text? > > It works for me - the text is wrapped, I don't see any glitch. > Pushed to master: d0c12fb0c0a892f61a5a6127069737fdab2c107d -- Petr? From pviktori at redhat.com Mon Jul 7 14:08:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 16:08:16 +0200 Subject: [Freeipa-devel] [PATCH] 0618 Update translations Message-ID: <53BAA9D0.80809@redhat.com> Once again, I have pushed updated translations from Transifex to master. The patch is huge, so I've not attached it. Use your Git client to get it. It's commit 518c8a5f9da906483d63f57908f7a47be9902ea5 Thanks to all translators! install/po/LINGUAS | 2 + install/po/bn_IN.po | 4 +- install/po/ca.po | 4 +- install/po/cs.po | 4 +- install/po/de.po | 4 +- install/po/es.po | 7 +- install/po/eu.po | 4 +- install/po/fr.po | 462 +----------- install/po/hi.po | 81 +++ install/po/hu.po | 167 +++++ install/po/id.po | 4 +- install/po/ipa.pot | 1620 ++++++++++++++++++++++++----------------- install/po/ja.po | 4 +- install/po/kn.po | 4 +- install/po/nl.po | 4 +- install/po/pl.po | 7 +- install/po/ru.po | 4 +- install/po/tg.po | 4 +- install/po/uk.po | 986 ++++++++++++++++++------- install/po/zh_CN.po | 4 +- 20 files changed, 1975 insertions(+), 1405 deletions(-) -- Petr? From pspacek at redhat.com Mon Jul 7 14:10:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 07 Jul 2014 16:10:08 +0200 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <1404142709.6436.50.camel@willson.usersys.redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> <53A94997.1050103@redhat.com> <1404141191.2332.24.camel@unused-4-145.brq.redhat.com> <1404142709.6436.50.camel@willson.usersys.redhat.com> Message-ID: <53BAAA40.4080300@redhat.com> On 30.6.2014 17:38, Simo Sorce wrote: > On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: >> On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: >>> On 23.6.2014 17:49, Martin Basti wrote: >>>> On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: >>>>> Hello, >>>>> I have following issues: >>>>> >>>>> #1 Upgrading existing replicas to support DNSSEC won't work for current >>>>> design (replica-file as storage for temporal replica key). >>>>> Temporal private key needs to be copied to replica, and no encrypted >>>>> master-key for replica is prepared in LDAP, because user doesn't need to >>>>> run ipa-replica-prepare. >>>>> >>>>> After discussion with Petr2, the solution is: >>>>> a) Each replica (except first - which generates master-key) generates >>>>> replica public and private keys. >>>>> b) Replica uploads public key to LDAP >>>>> c) Replica with generated master key, use the public key (b) to encrypt >>>>> master-key and store it to LDAP. Replica with master-key must detect, if >>>>> there is any new public replica key. >>>>> d) Replica (b) is now able to get master-key using own private replica >>>>> key >>>>> >>>>> >>>>> #2 We need to choose only one replica which will generate, (rotate, ...) >>>>> DNSSEC keys. >>>> and generate master key too >>>> >>>>> My proposal is to test during installation/upgrade if any dnssec/master >>>>> keys are in LDAP. If no key was found, the first server is >>>>> installed/upgraded and DNSSEC key generator is required. >>>>> >>>>> But there is issue with parallel upgrade multiple replicas (or if >>>>> replication temporarily doesn't work). There is no guarantee if replicas >>>>> will be able to detect if any replica became DNSSEC key generator. >>> >>> Let me add that we are going to use syncrepl anyway so the overall latency >>> should be minimal (if replication works). >>> >> >> Simo what do you think about it, could you tell us your opinion? > > I think DNSSEC should not be enabled by default, so on upgrade no action > should be taken. Activation/upgrade of DNSSEC feature should be manual > so that no conflict can arise. I think we can do a compromise. First of all, DNSSEC will not be enabled until admin explicitly decides to do so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see any change if the "DNSSEC checkbox" is not enabled for at least one DNS zone. IMHO it is reasonable to automatically install dependencies we need during upgrade. I.e. to install softhsm package to every replica by default and also generate replica keys (wrapping keys) by default. I agree that key-master-server election (used in IPA 4.1) can be done manually. I.e. all replica keys will be generated automatically but admin has to run something like ipa-dns-install --dnssec-master on one replica to explicitly mark one replica as key generator. This replica will run OpenDNSSEC daemon responsible for key maintenance. This approach will save us terrible headache from manual dependency installation and situations where DNSSEC-feature-dependencies were installed on some replicas but are not present on all of them etc. Do you agree? -- Petr^2 Spacek From pviktori at redhat.com Mon Jul 7 15:14:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 17:14:38 +0200 Subject: [Freeipa-devel] [PATCH] 0619 Become IPA 4.0.0 Message-ID: <53BAB95E.5030506@redhat.com> Pushed as 1e58588ec274d5da0f020b2c6af2824313ea0ea7 Tagged as release-4-0-0 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0619-Become-IPA-4.0.0.patch Type: text/x-patch Size: 800 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 7 16:37:05 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2014 12:37:05 -0400 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <53BAAA40.4080300@redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> <53A94997.1050103@redhat.com> <1404141191.2332.24.camel@unused-4-145.brq.redhat.com> <1404142709.6436.50.camel@willson.usersys.redhat.com> <53BAAA40.4080300@redhat.com> Message-ID: <1404751025.14455.42.camel@willson.usersys.redhat.com> On Mon, 2014-07-07 at 16:10 +0200, Petr Spacek wrote: > On 30.6.2014 17:38, Simo Sorce wrote: > > On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: > >> On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: > >>> On 23.6.2014 17:49, Martin Basti wrote: > >>>> On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: > >>>>> Hello, > >>>>> I have following issues: > >>>>> > >>>>> #1 Upgrading existing replicas to support DNSSEC won't work for current > >>>>> design (replica-file as storage for temporal replica key). > >>>>> Temporal private key needs to be copied to replica, and no encrypted > >>>>> master-key for replica is prepared in LDAP, because user doesn't need to > >>>>> run ipa-replica-prepare. > >>>>> > >>>>> After discussion with Petr2, the solution is: > >>>>> a) Each replica (except first - which generates master-key) generates > >>>>> replica public and private keys. > >>>>> b) Replica uploads public key to LDAP > >>>>> c) Replica with generated master key, use the public key (b) to encrypt > >>>>> master-key and store it to LDAP. Replica with master-key must detect, if > >>>>> there is any new public replica key. > >>>>> d) Replica (b) is now able to get master-key using own private replica > >>>>> key > >>>>> > >>>>> > >>>>> #2 We need to choose only one replica which will generate, (rotate, ...) > >>>>> DNSSEC keys. > >>>> and generate master key too > >>>> > >>>>> My proposal is to test during installation/upgrade if any dnssec/master > >>>>> keys are in LDAP. If no key was found, the first server is > >>>>> installed/upgraded and DNSSEC key generator is required. > >>>>> > >>>>> But there is issue with parallel upgrade multiple replicas (or if > >>>>> replication temporarily doesn't work). There is no guarantee if replicas > >>>>> will be able to detect if any replica became DNSSEC key generator. > >>> > >>> Let me add that we are going to use syncrepl anyway so the overall latency > >>> should be minimal (if replication works). > >>> > >> > >> Simo what do you think about it, could you tell us your opinion? > > > > I think DNSSEC should not be enabled by default, so on upgrade no action > > should be taken. Activation/upgrade of DNSSEC feature should be manual > > so that no conflict can arise. > > I think we can do a compromise. > > First of all, DNSSEC will not be enabled until admin explicitly decides to do > so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see any > change if the "DNSSEC checkbox" is not enabled for at least one DNS zone. > > IMHO it is reasonable to automatically install dependencies we need during > upgrade. I.e. to install softhsm package to every replica by default and also > generate replica keys (wrapping keys) by default. > > I agree that key-master-server election (used in IPA 4.1) can be done > manually. I.e. all replica keys will be generated automatically but admin has > to run something like ipa-dns-install --dnssec-master on one replica to > explicitly mark one replica as key generator. This replica will run OpenDNSSEC > daemon responsible for key maintenance. > > This approach will save us terrible headache from manual dependency > installation and situations where DNSSEC-feature-dependencies were installed > on some replicas but are not present on all of them etc. > > Do you agree? Sounds reasonable. Simo. From pviktori at redhat.com Mon Jul 7 16:47:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 18:47:39 +0200 Subject: [Freeipa-devel] git branching after 4.0 In-Reply-To: <53B6C7AD.4010803@redhat.com> References: <53B6C7AD.4010803@redhat.com> Message-ID: <53BACF2B.1060502@redhat.com> On 07/04/2014 05:26 PM, Martin Kosek wrote: > When 4.0 releases, there will be several development trains that we will > need to manage in our git: > > 1) FreeIPA 4.0 bugfixing - tickets in 4.0.1 milestone, will go to > ipa-4-0 branch ipa-4-0 branched > 2) FreeIPA 4.1 "small" development - 4.1 will be just a short release > for the summer focused on Views, full support of DNSSEC, OTP local high > watermark, Backup and Restore and other small features (and possibly > also CA management tool). ipa-4-1 branched > 3) FreeIPA 4.2 big development - this is a longer, more in the future > (read Fedora 22 time frame) development with major features going in - > Vault, User provisioning, publishing CA certs to clients and many others > stuff still being scoped. It will include for example big updates to > installers which should not go to more stable 4.1/4.0.x releases. this will be master > How to handle that in git repo? Given that we do not do merge commits, I > think the easiest way would be to: > > - When 4.0 releases, create ipa-4-0 and ipa-4-1 branches. This will > leave us with master, ipa-4-1, ipa-4-0 active branches > - 4.2 team will commit their work to master only > - 4.1 team will commit their work to master, ipa-4-1 > - 4.0.x bugfixing team will commit their work to master, ipa-4-1 and > ipa-4-0 > > This may sound complicated, but with Petr's ipatool pushing to multiple > branches should be easy. Our CI should guard at least ipa-4-0 and > ipa-4-1 branches for the summer (instead of ipa-3-3 and master) to > report failures early. I've update the tool to take new milestones into account. If you use the tool, please pull the changes. > If there is a better idea, please propose it. But this plan seemed to me > as the most straightforward. -- Petr? From npmccallum at redhat.com Mon Jul 7 16:54:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 07 Jul 2014 12:54:17 -0400 Subject: [Freeipa-devel] Ready to release? In-Reply-To: <53B6C96F.6050905@redhat.com> References: <53B6C0CE.5000008@redhat.com> <53B6C62D.30201@redhat.com> <53B6C96F.6050905@redhat.com> Message-ID: <1404752057.3033.4.camel@ipa.example.com> On Fri, 2014-07-04 at 17:34 +0200, Petr Spacek wrote: > On 4.7.2014 17:20, Petr Viktorin wrote: > > On 07/04/2014 04:57 PM, Martin Kosek wrote: > >> Hello developers! > >> > >> I would like to thank everyone for the hard work during the last weeks, > >> when finishing the FreeIPA 4.0 release, I saw many last stabilization > >> fixes in DNS, OTP, ACIs, upgrade and Web UI areas. > >> > >> The last major work that is still not pushed is the CA management tool. > >> Unfortunately, the final development and review did not go so well and > >> we still do not have final patches. > >> > >> Given that this is a major piece of work (>50 patches) and given that > >> the reviewer is on a leave, I am considering moving the feature to next > >> release - FreeIPA 4.1 which is short and would still make it to Fedora > >> 21. I would not like to stall 4.0 any more, I would like to offer all > >> the work we have done for wider testing as soon as possible. > >> > >> Thoughts? Any other last patches you would like to add to add to 4.0 GA? > >> There is still little time, but remember, git tag hammer is ready to fire. > > > > I'm testing these two: > > - mbasti-0098-100, DNS tests > > - mkosek-478, Spec bump > > > > Then there's pvoborni-695 with only a functional ACK > > > > The CA management is still up for discussion, but it's more and more likely > > We have deferred 'full' DNSSEC support already so it is not unprecedented. > > I have one proposal (valid only if we decide to defer CA management): > > Maybe we could release 4.1 in few weeks when DNSSEC and CA management are done > & properly reviewed. > > That would allow us to follow 'release early, release often' lore. In my > opinion, smaller release = safer. > > Of course, it would mean shifting current version numbers from 4.x to 4.(x+1), > sorry Martin! :-) I like this plan. 4.1 could cover just DNSSEC, CA management and 4.0 fixes. The original plan for 4.1 could become 4.2. I don't think the change in version numbers would imply a change in overall timing. I completely agree that smaller releases are better. :) Nathaniel From pviktori at redhat.com Mon Jul 7 19:02:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Jul 2014 21:02:04 +0200 Subject: [Freeipa-devel] Ready to release In-Reply-To: <53B6C0CE.5000008@redhat.com> References: <53B6C0CE.5000008@redhat.com> Message-ID: <53BAEEAC.3040405@redhat.com> On 07/04/2014 04:57 PM, Martin Kosek wrote: > Hello developers! > > I would like to thank everyone for the hard work during the last weeks, > when finishing the FreeIPA 4.0 release, I saw many last stabilization > fixes in DNS, OTP, ACIs, upgrade and Web UI areas. > [...] > > Thoughts? Any other last patches you would like to add to add to 4.0 GA? > There is still little time, but remember, git tag hammer is ready to fire. The tag hammer came down, FreeIPA 4.0.0 is ready to be released. It's getting late today, and the ARM build looks like it'll need another few hours, so I'll send the announcement and update the remaining Wiki pages tomorrow morning (CET). But you can already go ahead and try 4.0 out or check the release notes. Release notes: http://www.freeipa.org/page/Releases/4.0.0 Download page: http://www.freeipa.org/page/Downloads SHA1: 0021d15a0ec38276916014c85acc0009f3b0e279 MD5: 84ee2352f153074e2ace1d04ba4c2efb Packages for Fedora Rawhide (f21) are waiting for the ARM build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7113930 Fedora 20 COPR repository: https://copr.fedoraproject.org/coprs/pviktori/freeipa/ This is under my name, since COPR is tied to Fedora accounts. If you have git commit rights, I'll be glad to give you build/admin rights for the COPR -- you "just" need to request them in the Permissions tab. -- Petr? From dkupka at redhat.com Tue Jul 8 05:59:14 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 08 Jul 2014 07:59:14 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Fix ipa-client-install --uninstall crash In-Reply-To: <53BAF1BF.8050008@redhat.com> References: <53B64DE5.5030202@redhat.com> <53BAF1BF.8050008@redhat.com> Message-ID: <53BB88B2.8000300@redhat.com> On 07/07/2014 09:15 PM, Petr Viktorin wrote: > On 07/04/2014 08:47 AM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4273 >> >> David Kupka > > Hi, > This works fine. Just two nitpicks in the log message: > - "%s" means "convert to string", so the str() is redundant > - the logger methods take items to interpolate as arguments, instead > of one string built with %. > > So you'll want: > root_logger.error('Failed to start chronyd: %s', e) > > Hi, thanks for comments. I've fixed the patch accordingly. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0001-2-Fix-ipa-client-install-uninstall-crash.patch Type: text/x-patch Size: 1199 bytes Desc: not available URL: From pviktori at redhat.com Tue Jul 8 08:31:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 10:31:45 +0200 Subject: [Freeipa-devel] [PATCH] 0001 Fix ipa-client-install --uninstall crash In-Reply-To: <53BB88B2.8000300@redhat.com> References: <53B64DE5.5030202@redhat.com> <53BAF1BF.8050008@redhat.com> <53BB88B2.8000300@redhat.com> Message-ID: <53BBAC71.7090401@redhat.com> On 07/08/2014 07:59 AM, David Kupka wrote: > > On 07/07/2014 09:15 PM, Petr Viktorin wrote: >> On 07/04/2014 08:47 AM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4273 >>> >>> David Kupka >> >> Hi, >> This works fine. Just two nitpicks in the log message: >> - "%s" means "convert to string", so the str() is redundant >> - the logger methods take items to interpolate as arguments, instead >> of one string built with %. >> >> So you'll want: >> root_logger.error('Failed to start chronyd: %s', e) Sorry for not replying to list. > Hi, > thanks for comments. I've fixed the patch accordingly. Thanks! ACK, pushed to: master: 2ff14607b170c86ccd93cff60f5a34d64cd1e419 ipa-4-1: 2ff14607b170c86ccd93cff60f5a34d64cd1e419 ipa-4-0: 2ff14607b170c86ccd93cff60f5a34d64cd1e419 -- Petr? From pviktori at redhat.com Tue Jul 8 09:53:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 11:53:37 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.0 Message-ID: <53BBBFA1.1050707@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.0.0! It can be downloaded from http://www.freeipa.org/page/Downloads. As this is a major release, we did not add it to any stable Fedora release (yet), but we want to first give you a chance to test that yourself with a COPR repository: https://copr.fedoraproject.org/coprs/pviktori/freeipa/. FreeIPA 4.0.0 will be available in Fedora 21 repositories. These release notes can be read at: http://www.freeipa.org/page/Releases/4.0.0 == Highlights in 4.0.0 == === Enhancements === * Support *Kerberos-based OTP authentication* both natively with tokens managed by FreeIPA server and via Radius proxy (3rd party 2FA authentication server). * *Access control* in FreeIPA server was reworked and a concept of permissions/ACIs managed by FreeIPA plugin was introduced. The plugins have now a way to control which objects and attributes should be visible and to whom. The administrators can now change the default settings and whitelist or blacklist additional attributes or change the entire visibility of a specific FreeIPA function (users, groups, SUDO, ...) to anonymous, authenticated users or just a group of privileged users. * Web UI adopted the *Patternfly* (https://www.patternfly.org/) open interface project to promote design commonality and improved user experience. Web UI is now responsive and adapts to different screen sizes like mobile or tablets. Additionally, many usability or minor Web UI issues were fixed. * Experimental *DNSSEC inline-signing support* * DNS management plugin now allows *internationalized domain names*. Administrators can now enter the DNS records in unicode and have the management plugin do the conversion to IDN encoding (punycode). The DNS plugin supports the IDNA 2003 standard. * FreeIPA DNS plugin did not distinguish between master and *forward zones* and both were merged in one type of object. To remove the inconsistency, DNS plugin now distinguishes between these 2 types and separate commands were added for managing forward zones. * Support the *SubjectAltNames certificate extension* in FreeIPA service certificates. Certificates with SAN names are useful for load balancing when a node needs to present itself both with its FQDN and the balanced address. * ipa-client-install now automatically configures *SUDO* support on client machines, thus making FreeIPA SUDO integration very easy to use. * ipa-getkeytab can now *fetch* an existent Kerberos keytab for a chosen service. This allows fetching the same keytab on multiple hosts which is useful in cluster deployments. The operation is authorized via the allowedToPerform;read_keys attribute, stored on the target entry, which contains a DN of a user or a group allowed to get the keys without resetting them. * ipa-client-install now uploads the FreeIPA CA certificate in a *system-wide certificate store*, thus making it trusted by all other services on the OS. * Add automember-rebuild command allowing to apply all automember rules to existing objects (users, hosts). * ... and many other minor enhancements === Bug fixes === * User and group operations no longer raise internal error when working with large user bases * ipa-client-install no longer distributes non-working Firefox configuration for the Web UI. Admin can use the new --configure-firefox option to install a fixed configuration file to chosen directory. * XMLRPC system commands were not implemented. FreeIPA now supports system.listMethods, system.methodSignature and system.methodHelp * ipa-kdb loaded global configuration only on startup and never changed it until restart. Now, it checks the new configuration every 60 seconds. * sudo plugin runAsUser option now accepts external group * sudo plugin runAsGroup option was not generated in the sudoers compat tree correctly * sudo plugin did not allow host IP address masks * DNS plugin had a too restrictive zone/record name validator, it is much more relaxed now. * ipa-backup recursively backed up old backups fron /var/lib/ipa/backup * /etc/ssh/sshd_config is no longer garbled in case it did not contain a trailing new line * Server/replica installer now does not crash on systems with low entropy. Warnings are issued when entropy is too low and long installation times are expected * ... and many other minor bug fixes or bug fixes related to major enhancements in this release === 2FA Kerberos Authenication === FreeIPA now provides support for two-factor authentication (2FA) via Kerberos. FreeIPA can integrate into exising OTP systems by proxying requests over RADIUS. FreeIPA also provides integrated support for the open-standard TOTP (RFC 6238) and HOTP (RFC 4226) tokens, including YubiKey (http://www.yubico.com/) and FreeOTP (iOS: https://itunes.apple.com/us/app/freeotp/id872559395 or Android: https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp). Administrators can configure individual users for RADIUS proxy or HOTP/TOTP. In the latter case, once enabled for HOTP/TOTP, users can provision, manage and synchronize their own tokens via the CLI or UI. Administrators can also create tokens on behalf of users, with the option to grant management permissions to the user. If the user does not have management permissions, the token is read only (except synchronization). When dealing with hardware tokens, administrators can bulk-import the token metadata using the industry standard Portable Symmetric Key Container XML (RFC 6030) files. ==== Limitations ==== As this is our first release, it comes with some limitations. HOTP has concerns about scalability in large replication environments due to the frequent need to replicate the token counter across the cluster. For this reason, FreeIPA defaults to TOTP tokens. TOTP has a known issue where tokens can be re-used within a short window. This is due to lacking high-watermark support. Implementing this restriction without careful consideration for the impact on replication could result in similar problems to HOTP (above). The workflow for changing passwords causes problems with HOTP tokens. This is most noticable when passwords expire. In the case of the Web UI, logins will simply fail. As a workaround for this, the password can simply be changed using the CLI. In the case of SSSD logins, the login will succeed but the password change will appear to fail while actually succeeding. Currently there is no workflow for lost tokens. === Reworked Control Access === Permissions can be set to apply to ''anonymous'' or ''all'' authenticated users, or use the existing privilege/role system of assigning rights to specific users. (design: http://www.freeipa.org/page/V4/Anonymous_and_All_permissions) Previously, all of the directory, except a few security-sensitive attributes, was readable by anyone that could connect to the directory server, even anonymous users. Instead, FreeIPA 4.0 uses fine-grained permissions to grant read access. (design: http://www.freeipa.org/page/V4/Managed_Read_permissions) This change may render some information unreadable to unprivileged users. To grant read rights, create or find a permission that governs read access to the offending attribute(s), and either add it to an appropriate role, or set its bind rule to 'all' or 'anonymous'. FreeIPA's existing default add/modify/delete permissions were also reworked. The default permissions have the "System:" name prefix, and do not allow structural modifications. Administrators of deployments where default permissions were customized beyond attribute lists and privilege/role membership should carefully read the ''Documentation draft'' and ''Upgrade considerations'' sections of the design page (http://www.freeipa.org/page/V4/Managed_Read_permissions), and to test before deploying FreeIPA 4.0 to production. Permissions in FreeIPA 4.0 are more flexible, allowing arbitrary combinations of type, subtree and filters. (design: http://www.freeipa.org/page/V4/Multivalued_target_filters_in_permissions) Note that permissions that were created or modified on a FreeIPA 4.0 server, including FreeIPA's default permissions, can ''not'' be modified on older servers. Adding them to privileges is still possible on any server. === DNS Master and Forward Zones === New command `ipa dnsforwardzone` was introduced and *semantics of `--forwarder` option for `ipa dnszone` command was changed* to match BIND semantics. Functionality previously provided by command `ipa dnszone-* --forwarder` is from FreeIPA 4.0 provided by command `ipa dnsforwardzone-* --forwarder`. Sematics of the old command `ipa dnszone` now matches BIND semantics for *master* zone type. I.e. local BIND replies authoritatively to queries for data in given zone (including authoritative NXDOMAIN answers for non-existent names) and forwarding affects only queries made by BIND to answer recursive queries which cannot be answered locally. I.e. forwarding affects only queries for names below zone cuts (NS records) of locally served zones. For further explanation please see: * https://lists.isc.org/pipermail/bind-users/2006-January/060810.html * https://lists.isc.org/pipermail/bind-users/2011-March/083244.html The new command `ipa dnsforwardzone` offers semantics equivalent to BIND `forward` zone type. Forward zone does not contain any authoritative data and forward queries which cannot be answered from local cache to configured servers. Forwarding policy is documented in section "Forwarding" in BIND 9 Configuration Reference (http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#id2583370). === Experimental DNSSEC Support === DNS zones served by FreeIPA can be secured with DNSSEC (http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions). The signing process is fully automatic but *signing keys have to be provided by user manually* and all keys need to be copied to all FreeIPA DNS servers. On the first FreeIPA server you can generate signing keys with following commands (please replace "$ZONE" with zone name without trailing period, e.g. "example.com"): cd "/var/named/dyndb-ldap/ipa/$ZONE/keys" dnssec-keygen -3 -b 2048 -f KSK "$ZONE" dnssec-keygen -3 -b 2048 "$ZONE" At this point you need to *securely* copy all files in directory `/var/named/dyndb-ldap/ipa/$ZONE/keys` from the first server to all other FreeIPA DNS servers. On all servers you have to fix filesystem permissions and inform `named` that keys are in place: cd "/var/named/dyndb-ldap/ipa/$ZONE/keys" chown named: * chmod u=rw,go= * rndc sign "$ZONE" Now is your zone signed with given keys. As a last step, it is necessary to add DS records to your parent zone. See `man dnssec-dsfromkey` and `man dnssec-checkds` or ask parent zone operator for guidance. To enable NSEC3 for given zone you have to specify NSEC3PARAM record (http://tools.ietf.org/html/rfc5155#section-4). For example: ipa dnszone-mod "$ZONE" --nsec3param-rec="1 0 8 1B3140F28A1C" For security reasons (https://eprint.iacr.org/2010/115.pdf) it is recommended *not to use* NSEC3 opt-out feature (http://tools.ietf.org/html/rfc5155#section-6). == 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-upgradeconfig # ipa-ldap-updater --upgrade 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. === Transformation Master to Forward zones === Zones with specified forwarders, with policy different than ''none'', are transformed to forward zones. All master zones data are backed up in /var/lib/ipa/backup/dns-forward-zones-backup-%Y-%m-%d-%H-%M-%S.ldif. Transformation to forward zones, is executed only once, by one replica only, and only if ipa version is lower than 4.0. Since this upgrade, you should use forward zones to forwarding queries. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.0 == Adam Misnyovszki (17): ipactl can not restart ipa services if current status is stopped Add --force option to ipactl Certificate search max_serial_number problem fixed Extending user plugin with inetOrgPerson fields CA-less tests generate failure automember rebuild nowait feature added plugin registration refactoring for automembership CI - test_forced_client_reenrollment stability fix webui doc: typo fixes in guides webui: select all checkbox remains selected after operation plugin registration refactoring for pwpolicy Trust add datetime fix webui OTP token test data added webui static site delete command fixed webui tests: callback, assert_disabled feature added webui tests: range test extended Call generate-rndc-key.sh during ipa-server-install Alexander Bokovoy (39): Remove systemd upgrader as it is not used anymore ipa-sam: do not modify objectclass when trust object already created ipa-sam: do not leak LDAPMessage on ipa-sam initialization ipa-sam: report supported enctypes based on Kerberos realm configuration ipaserver/dcerpc.py: populate forest trust information using realmdomains trusts: support subdomains in a forest frontend: report arguments errors with better detail ipaserver/dcerpc: remove use of trust account authentication trust: integrate subdomains support into trust-add ipasam: for subdomains pick up defaults for missing values KDC: implement transition check for trusted domains ipa-kdb: Handle parent-child relationship for subdomains Guard import of adtrustinstance for case without trusts Map NT_STATUS_INVALID_PARAMETER to most likely error cause: clock skew subdomains: Use AD admin credentials when trust is being established trust: fix get_dn() to distinguish creating and re-adding trusts trust-fetch-domains: create ranges for new child domains trustdomain-find: report status of the (sub)domain ipaserver/install/installutils: clean up properly after yield group-show: resolve external members of the groups ipa-adtrust-install: configure host netbios name by default ipasam: delete trusted child domains before removing the trust libotp: do not call internal search for NULL dn bindinstance: make sure zone manager is initialized in add_master_dns_records ipa-kdb: in case of delegation use original client's database entry, not the proxy ipa-kdb: make sure we don't produce MS-PAC in case of authdata flag cleared by admin trustdomain_find: make sure we skip short entries when --pkey-only is specified trust: make sure we always discover topology of the forest trust ipaserver/dcerpc: catch the case of insuffient permissions when establishing trust adtrustinstance: make sure to stop and disable winbind in uninstall() fix filtering of subdomain-based trust users ipa-kdb: do not fetch client principal if it is the same as existing entry ipaserver/dcerpc: make sure to always return unicode SID of the trust domain trust: do not fetch subdomains in case shared secret was used to set up the trust schema-compat: set precedence to 49 to allow OTP binds over compat tree freeipa.spec.in: update dependencies to 389-ds and selinux-policy Fix packaging issue with doubly specified directories Add missing ipa-otptoken-import.1.gz to spec file ipa-ldap-updater: make possible to use LDAPI with autobind in case of hardened LDAP configuration Ana Krivokapi? (33): Handle --subject option in ipa-server-install Fix handling of CSS files in sync.sh script Fix broken replica installation Add integration tests for Kerberos Flags Fix tests which fail after ipa-adtrust-install Add integration tests for forced client re-enrollment Create DS user and group during ipa-restore Add warning when uninstalling active replica Add option to ipa-client-install to configure automount Replace ntpdate calls with ntpd Fix invocations of FileError in ipa-client-install Do not crash if DS is down during server uninstall Do not show unexpected error in ipa-ldap-updater Follow tmpfiles.d packaging guidelines Add ipa-advise plugins for nss-pam-ldapd legacy clients Do not roll back failed client installation on server Make sure nsds5ReplicaStripAttrs is set on agreements Add test for external CA installation Fix regression which prevents creating a winsync agreement Use EXTERNAL auth mechanism in ldapmodify Add automember rebuild command Add a privilege and a permission needed for automember rebuild command Add unit tests for automember rebuild command Fix error message when adding duplicate automember rule Add automember rebuild command to the web UI Web UI integration test driver enhancement Add web UI integration tests for automember rebuild Add userClass attribute for users WebUI: Add userClass attribute to user and host pages Make Expression field required when adding automember condition Make sure state of services is preserved after client uninstall Enable Retro Changelog and Content Synchronization DS plugins Improve error message on failed Kerberos authentication Gabe (8): ipa-join usage instructions are incorrect Typo in warning message where IPA realm and domain name differ Fix order of synchronizing time when running ipa-client-install fix typo in ipa -v migrate-ds ipa-client-automount should not configure nsswitch.conf manually ipa recursively adds old backups ipautil.run args log message is confusing Add version and API version Jakub Hrozek (2): EXTDOM: Do not overwrite domain_name for INP_SID trusts: combine filters with AND to make sure only the intended domain matches Jan Cholasta (105): Make PKCS#12 handling in ipa-server-certinstall closer to what other tools do. Port ipa-server-certinstall to the admintool framework. Remove unused NSSDatabase and CertDB method find_root_cert_from_pkcs12. Ignore empty mod error when updating DS SSL config in ipa-server-certinstall. Replace only the cert instead of the whole NSS DB in ipa-server-certinstall. Untrack old and track new cert with certmonger in ipa-server-certinstall. Add --pin option to ipa-server-certinstall. Ask for PKCS#12 password interactively in ipa-server-certinstall. Fix nsSaslMapping object class before configuring SASL mappings. Add --dirman-password option to ipa-server-certinstall. Fix ipa-server-certinstall usage string. Fix service-disable in CA-less install. Fix nsslapdPlugin object class after initial replication. Read passwords from stdin when importing PKCS#12 files with pk12util. Allow PKCS#12 files with empty password in install tools. Track DS certificate with certmonger on replicas. Make LDAPEntry a wrapper around dict rather than a dict subclass. Introduce IPASimpleLDAPObject.decode method for decoding LDAP values. Always use lists for values in LDAPEntry internally. Decode and encode attribute values in LDAPEntry on demand. Make sure attributeTypes updates are done before objectClasses updates. Remove legacy toDict and origDataDict methods of LDAPEntry. Store encoded attribute values from search results directly in entry objects. Use encoded values from entry objects directly when generating modlists. Use encoded values from entry objects directly when adding new entries. Turn LDAPEntry.single_value into a dictionary-like property. Remove mod_ssl port workaround. Move IPA specific code from LDAPClient to the ldap2 plugin. Add wrapper for result3 to IPASimpleLDAPObject. Support searches with paged results control in LDAPClient. Refactor indirect membership processing. Remove unused method get_api of the ldap2 plugin. Use hardening flags for ipa-optd. Own /usr/share/ipa/ui/js/ in the spec file. Prefer user CFLAGS/CPPFLAGS over those provided by rpmbuild in the spec file. Include LDFLAGS provided by rpmbuild in global LDFLAGS in the spec file. Add stricter default CFLAGS to Makefile. Fix compilation error in ipa-cldap. Remove CFLAGS duplication. Fix internal error in the user-status command. Convert remaining backend code to LDAPEntry API. Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent. PKI service restart after CA renewal failed Rename LDAPEntry method commit to reset_modlist. Use old entry state in LDAPClient.update_entry. Move LDAPClient method get_single_value to IPASimpleLDAPObject. Make IPASimpleLDAPObject.get_single_value result overridable. Use LDAPClient.update_entry for LDAP mods in ldapupdate. Reduce amount of LDAPEntry.reset_modlist calls in ldapupdate. Add LDAPEntry method generate_modlist. Remove unused LDAPClient methods get_syntax and get_single_value. Remove legacy LDAPEntry properties data and orig_data. Store old entry state in dict rather than LDAPEntry. Do not crash on bad LDAP data when formatting decode error message. Use raw LDAP data in ldapupdate. Fix ipa-client-automount uninstall when fstore is empty. Do not start the service in stopped_service if it was not running before. Increase service startup timeout default. Fix ntpd config on clients. Get original entry state from LDAP in LDAPUpdate. Convert remaining installer code to LDAPEntry API. Convert remaining update code to LDAPEntry API. Convert remaining test code to LDAPEntry API. Raise an exception when legacy LDAP API is used. Convert remaining frontend code to LDAPEntry API. Remove sourcehostcategory from the default HBAC rule. Always use real entry DNs for memberOf in ldap2. Fix modlist generation code not to generate empty replace mods. Log unhandled exceptions in certificate renewal scripts. Fix certificate renewal scripts to work with separate CA DS instance. Move CACERT definition to a single place. Do not create CA certificate files in CA-less server install. Use LDAP API to upload CA certificate instead of ldapmodify command. Upload CA certificate from DS NSS database in CA-less server install. Remove unused method export_ca_cert of dsinstance. Show progress when enabling SSL in DS in ipa-server-install output. Use certmonger D-Bus API to configure certmonger in CA install. Add new certmonger CA helper dogtag-ipa-ca-renew-agent. Update pkcs10 module functions to always load CSRs and allow selecting format. Remove unused function get_subjectaltname from the cert plugin. Add function for parsing friendly name from certificate requests. Support retrieving renewed certificates from LDAP in dogtag-ipa-ca-renew-agent. Use dogtag-ipa-ca-renew-agent to retrieve renewed certificates from LDAP. Remove dogtag-ipa-retrieve-agent-submit. Support storing renewed certificates to LDAP in dogtag-ipa-ca-renew-agent. Use dogtag-ipa-ca-renew-agent to track certificates on master CA. Store information about which CA server is master for renewals in LDAP. Make the default dogtag-ipa-ca-renew-agent behavior depend on CA setup. Merge restart_pkicad functionality to renew_ca_cert and remove restart_pkicad. Merge restart_httpd functionality to renew_ra_cert. Use the same certmonger configuration for both CA masters and clones. Update certmonger configuration in ipa-upgradeconfig. Support exporting CSRs in dogtag-ipa-ca-renew-agent. Remove unused method is_master of CAInstance. Fix upload of CA certificate to LDAP in CA-less install. Fix update_ca_renewal_master plugin on CA-less installs. Allow primary keys to use different type than unicode. Support API version-specific RPC marshalling. Replace get_syntax method of IPASimpleObject with new get_type method. Use raw attribute values in command result when --raw is specified. Keep original name when setting attribute in LDAPEntry. Allow SAN in IPA certificate profile. Support requests with SAN in cert-request. Remove GetEffectiveRights control when ldap2.get_effective_rights fails. Do not corrupt sshd_config in client install when trailing newline is missing. Jan Pazdziora (1): Adding verb to error message to make it less confusing. Jason Woods (1): ipa-sam: cache gid to sid and uid to sid requests in idmap cache Krzysztof Klimonda (1): Fix -Wformat-security warnings Luk?? Slebodn?k (1): BUILD: Fix portability of NSS in file ipa_pwd.c Martin Ba?ti (72): Added warning if cert '/etc/ipa/ca.crt' exists ipa-client-install: Added options to configure firefox Removed old firefox configuration scripts Changed CLI to allow to use FILE as optional param migrate-ds added --ca-cert-file=FILE option PTR records can be added without specify FQDN zone name DNS classless support for reverse domains DNS tests for classless reverse domains Fix test_host_plugin for DNS Classless Reverse zones Allows to sort non text entries DNSName type DNSNameParam parameter dns_name_values capability added get_ancestors_primary_keys clone CLI conversion of DNSName type DNSName conversion in ipaldap Modified has_output attributes Modified dns related global functions Modified records and zone parameters to use DNSNameParam Modified record and zone class to support IDN _domain_name_validatord moved from DNS to realmdomains move hostname validation from DNS to hosts DNS modified tests DNS new tests PTR record target can be relative Test DNS: wildcard in RR owner Fix indentation Test DNS: dnsrecord-* zone.test. zone.test. should work Make zonenames absolute in host plugin Python-kerberos update in freeipa.spec.in Separate master and forward DNS zones Prevent commands to modify different type of a zone Create BASE zone class Tests DNS: forward zones Fix handle python-dns UnicodeError DNSSEC: remove unsuported records DNSSEC: added NSEC3PARAM record type DNSSEC: webui update DNSSEC attributes Tests: remove unused records from tests Tests: tests for NSEC3PARAM records DNSSEC: DLVRecord type added DNSSEC: Test: DLV record Digest part in DLV/DS records allows only heaxadecimal characters DNSSEC: WebUI add DLV record type Fix ipa.service restart Fix incompatible DNS permission Added upgrade step executed before schmema is upgraded Upgrade special master zones to forward zones Check normalization only for IDNA domains DNSSEC: add TLSA record type DNSSEC: WebUI: add TLSA record Fix ACI in DNS Remove NSEC3PARAM record Add NSEC3PARAM to zone settings NSEC3PARAM tests Allow to add non string values to named conf DNSSEC: Add experimental support for DNSSEC Add warning about semantic change for zones Add DNSSEC experimental support warning message Use documentation addresses in dns help Help for forward zones Split dns docstring Fix upgrade to forward zones Fix incompatible permission name *zone-del Non IDNA zonename should be normalized to lowercase Fix tests dns_realmdomains_integration Fix: Missing ACI for records in 40-dns.update Restore privileges after forward zones update Allow to add managed permission for reverse zones Test DNS: test zone normalization Test DNS: TLSA record Test DNS: add zone with consecutive dash characters Martin Ko?ek (58): Bump 3.4 development version to 3.3.90 Prevent *.pyo and *.pyc multilib problems Remove rpmlint warnings in spec file Fix selected minor issues in the spec file and license Use FQDN when creating MSDCS SRV records Do not set DNS discovery domain in server mode Require new SSSD to pull required AD subdomain fixes Remove faulty DNS memberOf Task Do not allow '%' in DM password Remove --no-serial-autoincrement PKI installation on replica failing due to missing proxy conf Use consistent realm name in cainstance and dsinstance Winsync re-initialize should not run memberOf fixup task Installer should always wait until CA starts up Administrative password change does not respect password policy Do not add kadmin/changepw ACIs on new installs Make set_directive and get_directive more strict Remove mod_ssl conflict Add nsswitch.conf to FILES section of ipa-client-install man page Remove ipa-pwd-extop and ipa-enrollment duplicate error strings Remove deprecated AllowLMhash config Server does not detect different server and IPA domain Allow kernel keyring CCACHE when supported Consolidate .gitignore entries Increase Java stack size on PPC platforms Increase Java stack size on s390 platforms Revert restart scripts file permissions change hbactest does not work for external users sudoOrder missing in sudoers Add missing example to sudorule Remove missing VERSION warning in dnsrecord-mod Hide trust-resolve command Add runas option to run function Switch httpd to use default CCACHE httpd should destroy all CCACHEs ntpconf: remove redundant comment Fallback to global policy in ipa-lockout plugin ipa-lockout: do not fail when default realm cannot be read Migration does not add users to default group .mailmap: use correct name format for Adam Avoid passing non-terminated string to is_master_host ipa-replica-install never checks for 7389 port Fix idrange unit test failure Update Dogtag 9 database during replica installation Proxy PKI clone /ca/ee/ca/profileSubmit URI Add missing dependencies to freeipa-python package Add requires for pki-core-10.1.1-1.fc20 Make ipa-client-automount backwards compatible Make trust objects available to regular users Revert "Check for password expiration in pre-bind" Add python-yubico to BuildRequires Fix objectClass casing in LDIF to prevent schema update error Let Host Administrators use host-disable command Remove python-cherrypy BuildRequires Update X-ORIGIN for 4.0 Clear NSS session cache when socket is closed Add Modify Realm Domains permission Prepare spec for 4.0 release Nalin Dahyabhai (3): Add missing dependency Accept any alias, not just the last value Restore krbCanonicalName handling Nathaniel McCallum (41): Bypass ipa-replica-conncheck ssh tests when ssh is not installed Ensure credentials structure is initialized Document no_search in Param flags Don't special case the Password class in Param.__init__() Add optional_create flag Allow multiple types in Param type validation Add IntEnum parameter to ipalib Add support for managing user auth types Add RADIUS proxy support to ipalib CLI Add OTP support to ipalib CLI Add rpmbuild/ to .gitignore Move ipa-otpd socket directory Fix OTP token names/labels Fix generation of invalid OTP URIs Update ACIs to permit users to add/delete their own tokens ipa-kdb: validate that an OTP user has tokens Enable building in C99 mode Add libotp internal library for slapi plugins Add support to ipa-kdb for keyless principals Add HOTP support Add OTP last token plugin Add OTP sync support to ipa-pwd-extop Teach ipa-pwd-extop to respect global ipaUserAuthType settings Use super() properly to avoid an exception Make all ipatokenTOTP attributes mandatory Remove NULLS from constants.py Rework how otptoken defaults are handled Fix token secret length RFC compliance Fix a typo in the otptoken doc string kdb: Don't provide password expiration when using only RADIUS Only specify the ipatokenuniqueid default in the add operation Default the token owner to the person adding the token Update all remaining plugins to the new Registry API Add support for managedBy to tokens Periodically refresh global ipa-kdb configuration Make otptoken use os.urandom() for random data Implement OTP token importing Change OTPSyncRequest structure to use OctetString Add /session/token_sync POST support Add the otptoken-add-yubikey command Add otptoken-sync command Nick Hatch (1): Don't exclude symlinks when loading plugins Petr Viktorin (258): Allow freeipa-tests to work with older paramiko versions Allow API plugin registration via a decorator Add missing license header to ipa-test-config Add CA-less install tests Add man pages for testing tools Remove __all__ specifications in ipaclient and ipaserver.install Make make-lint compatible with Pylint 1.0 Move tests to test directories Convert test_ipautil from unittest to nose Add missing dict methods to CIDict Raise an error when updating CIDict with duplicate keys Use correct super-calls in get_args() methods test_integration.host: Move transport-related functionality to a new module test_integration: Add OpenSSHTransport, used if paramiko is not available ipatests.test_integration.test_caless: Fix mkdir_recursive call ipatests.beakerlib_plugin: Warn instead of failing when some logs are missing ipatests.order_plugin: Exclude test generators from the order ipatests.beakerlib_plugin: Add argument of generated tests to test captions ipatests.test_cmdline.test_help: Re-raise unexpected exceptions on failure Add tests for installing with empty PKCS#12 password Update translations from Transifex ipa-client-install: Use direct RPC instead of api.Command ipa-client-install: Verify RPC connection with a ping Do not fail upgrade if the global anonymous read ACI is not found ipapython.nsslib: Name arguments to NSPRError test_ipalib.test_crud: Don't use a string in takes_options Add tests for the IntEnum class test_caless.TestCertInstall: Fix 'test_no_ds_password' test case Use new CLI options in certinstall tests Use a user result template in tests test_simple_replication: Fix waiting for replication Fix date in last changelog entry Update Permission and ACI plugins to decorator registration API Fix indentation in permission plugin tests Fix invalid assumption NSS initialization check in SSLTransport Help plugin: don't fail if a topic's module is not found Use new ipaldap entry API in aci and permission plugin Improve permission plugin test cleanup Tests: mkdir_recursive: Don't fail when top-level directory doesn't exist beakerlib plugin: Don't try to submit logs if they are missing Fix debug output in integration test Add tests for user auth type management Remove unused utf8_encode_value functions ldapupdate: Factor out connection code dsinstance: Move the list of schema filenames to a constant Add schema updater based on IPA schema files Update the man page for ipa-ldap-updater Remove schema modifications from update files Remove schema special-casing from the LDAP updater Make schema files conform to new updater Add formerly update-only schema Unify capitalization of attribute names in schema files Update translations from Transifex Add ConcatenatedLazyText object Break long doc string in the Host plugin Improve LDAPEntry.__repr__ for freshly created entries Remove changelog from the spec Switch client to JSON-RPC Make jsonserver_kerb start a cookie-based session Add server/protocol type to rpcserver logs Add tests for the radiusproxy plugin test_integration: Support external names for hosts test_integration: Log external hostname in Host.ldap_connect Regression test for user_status crash test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts Allow sets for initialization of frozenset-typed Param keywords Allow Declarative test classes to specify the API version Add tests for permission plugin with older clients Add new permission schema Rewrite the Permission plugin Verify ACIs are added correctly in tests Roll back ACI changes on failed permission updates permission plugin: Ensure ipapermlocation (subtree) always exists Make sure SYSTEM permissions can be retreived with --all --raw Test adding noaci/system permissions to privileges Remove default from the ipapermlocation option permission_find: Do not fail for ipasearchrecordslimit=-1 cli.print_attribute: Convert values to strings Use new registration API in the privilege plugin Allow anonymous and all permissions rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb Implement XML introspection ipa-replica-install: Move check for existing host before DNS resolution check integration tests OpenSSHTransport: Expand tilde to home in root_ssh_key_filename ipa tool: Print the name of the server we are connecting to with -v Add a .mailmap file Correct Jenny Severance's last name Update README and BUILD Remove the TODO file Permission plugin fixes permission plugin: Convert options in execute, not args_options_2_params permission plugin: Generate ACIs in the plugin Make it possible to call custom functions in Declarative tests Add support for managed permissions .mailmap: Remove spurious Kyle Baker line permission-mod: Do not copy member attributes to new entry permissions: Use multivalued targetfilter Add permission_filter_objectclasses for explicit type filters Add tests for multivalued filters Remove the unused ipalib.frontend.Property class permission plugin: Do not assume attribute-level rights for new attributes are present Update API.txt ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata Test fixed modlist generation code test_integration.config: Fix crash in to_env when no replica is defined test_integration.config: Do not save the input environment test_integration.config: Use a more declarative approach to test-wide settings test_integration.config: Do not store the index in Domain and Host objects test_integration.config: Load/store from/to dicts test_integration.config: Add environment variables for JSON/YAML ipa-test-config: Add --json and --yaml output options test_integration.config: Convert some text values to str Add tests for integration test configuration ipalib.plugable: Always set the parser in bootstrap() tests: Create the testing service certificate on demand permission-mod: Remove attributelevelrights before reverting entry permission plugin: Allow multiple values for memberof permissions plugin: Don't crash with empty targetfilter permission-find: Cache the root entry for legacy permissions permission_add: Remove permission entry if adding the ACI fails Do not hardcode path to ipa-getkeytab in tests ipaserver.install.service: Fix estimated time display permission plugin: Output the extratargetfilter virtual attribute permission plugin: Write support for extratargetfilter permission CLI: Rename filter to rawfilter, extratargetfilter to filter permission plugin: Add tests for extratargetfilter permission plugin: Support searching by extratargetfilter permission plugin: Do not fail on non-DN memberof filters permission plugin: Do not change extra target filters by "views" Add Nathaniel McCallum to .mailmap test_integration.tasks: Do not fail cleanup if backup directory does not exist cli: Clean up imports cli: Show list of values in --help for all Enums cli: Add mechanism for deprecated option name aliases permission CLI: rename --permissions to --right permission plugin: Do not add the ipapermissionv2 for output Allow indexing API object types by class permission-find: Fix handling of the search term for legacy permissions test_permission_plugin: Fix tests that make too broad assumptions Allow modifying permissions with ":" in the name Add Object metadata and update plugin for managed permissions permission plugin: Add 'top' to the list of object classes Allow anonymous read access to containers Add managed read permissions to HBAC objects Document the managed permission updater operation Allow overriding all attributes of default permissions ipalib.errors: Fix TaskTimeout doctest Add managed read permissions to Sudo objects Add managed read permissions to group Add managed read permission to hostgroup CA-less tests: Use sequential certificate serial numbers Add mechanism for adding default permissions to privileges Add managed read permissions to RBAC objects Add managed read permissions to realmdomains Add managed read permission for SELinux user map test_realmdomains_plugin: Add default ACI to expected output Add managed read permissions to host Add managed read permissions to pwpolicy and cosentry Fix expected output in permission tests Add managed read permission to config Add managed read permissions to krbtpolicy Allow anonymous read access to Kerberos containers Add managed read permission to idrange Add managed read permission to automount Do not ask for memberindirect when updating managed permissions Add managed read permissions to automember test_integration.host: Export the hostname to dict as string Add a new ipaVirtualOperation objectClass to virtual operations Extend anonymous read ACI for containers Add managed read permission to service Add support for non-plugin default permissions Add several managed read permissions under cn=etc test_ldap: Read a publicly accessible attribute when testing anonymous bind aci-update: Trim the admin write blacklist aci-update: Add ACI for read-only admin attributes trust plugin: Remove ipatrustauth{incoming,outgoing} from default attrs Add managed read permissions to trust ipalib.aci: Add support for == and != operators to ACI Move ACI tests to the testsuite ipalib.aci: Allow alternate "aci" keyword in ACIs ipa-client-automount: Use rpcclient, not xmlclient, for automountlocation_show Replace "replica admins read access" ACI with a permission ipalib.cli: Add filename argument to ipa console Add managed read permissions to user update_managed_permissions: Pass around anonymous ACI rather than its blacklist Set user addressbook/IPA attribute read ACI to anonymous on upgrades from 3.x Remove the global anonymous read ACI ldap2.find_entries: Do not modify attrs_list in-place ipalib.version: Add VENDOR_VERSION admin tools: Log IPA version dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone pwpolicy-mod: Fix crash when priority is changed aci plugin: Fix internal error when ACIs are not readable Add managed read permission for the UPG Definition ldap2.has_upg: Raise an error if the UPG definition is not found krbtpolicy plugin: Code cleanup krbtpolicy plugin: Fix internal error when global policy is not readable Add read permissions for automember tasks ipalib.aci: Fix bugs in comparison test_permission_plugin: limit results in targetfilter find test Add mechanism for updating permissions to managed Convert Sudo rule default permissions to managed Add missing attributes to 'Modify Sudo rule' permission Split long docstrings that were recently modified managed perm updater: Handle case where we changed default ACIs in the past Convert User default permissions to managed Add missing attributes to User managed permissions permission plugin: Sort rights when writing the ACI Add method to enumerate managed permission templates Add ACI.txt Make 'permission' the default bind type for managed permissions Make sure member* attrs are always granted together in read permissions ipalib.frontend: Do API version check before converting arguments ipalib.config: Only convert basedn to DN ipalib.config: Don't autoconvert values to float Fix self argument in tasks managed permission updater: Add mechanism to replace SYSTEM permissions Convert DNS default permissions to managed Remove the update_dns_permissions plugin Add $REALM to variables supported by the managed permission updater Convert COSTemplate default permissions to managed Convert Password Policy default permissions to managed Allow read access to masters, but not their services, to auth'd users Fix: Allow read access to masters, but not their services, to auth'd users Allow anonymous read access to virtual operation entries Test and docstring fixes permission plugin: Join --type objectclass filters with OR Add posixgroup to groups' permission object filter Convert Host default permissions to managed host permissions: Allow writing attributes needed for automatic enrollment netgroup: Add objectclass attribute to read permissions Convert Automount default permissions to managed Convert Group default permissions to managed Convert HBAC Rule default permissions to managed Convert HBAC Service default permissions to managed Convert HBAC Service Group default permissions to managed Convert Hostgroup default permissions to managed Convert Netgroup default permissions to managed Convert the Modify privilege membership permission to managed Convert Role default permissions to managed Convert SELinux User Map default permissions to managed Convert Service default permissions to managed Convert Sudo Command default permissions to managed Convert Sudo Command Group default permissions to managed Add several CRUD default permissions test_permission_plugin: Fix permission_find test for legacy permissions Update translations install/ui/build: Build core.js permission plugin: Ignore unparseable ACIs Allow admins to write krbLoginFailedCount Do not fail if there are multiple nsDS5ReplicaId values in cn=replication,cn=etc test_ipagetkeytab: Fix expected error message test_ipaserver: Add OTP token test data to ipatests package ldapupdate: Restore 'replace' functionality Allow read access to services in cn=masters to auth'd users makeaci: Use the DN where the ACI is stored, not the permission's DN Update translations Become IPA 4.0.0 Petr Voborn?k (264): Make ssh_widget not-editable if attr is readonly Hide delete button in multivalued widget if attr is not writable Removal of deprecated selenium tests Add base-id, range-size and range-type options to trust-add dialog Hide 'New Certificate' action on CA-less install Web UI integration tests: CA-less Web UI Integration tests: Kerberos Flags Web UI integration tests: ID range types Show human-readable error name in error dialog title Update idrange search facet after trust creation Fix RUV search scope in ipa-replica-manage Fix redirection on deletion of last dns record entry Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown Fix enablement of automount map type selector ipatests.test_integration.host: Add logging to ldap_connect() Load updated Web UI files after server upgrade Removal of unused code Web UI source code annotation Configuration for JSDuck documentation generator Phases Guide Debugging Web UI guide Plugin Infrastructure Guide Navigation Guide Registries and Build Guide Fix password expiration notification Fix license in some Web UI files Increase stack size for Web UI builder Remove SID resolve call from Web UI Fix disabled logic of menu item RCUE initial commit Move RCUE styles to its own directory Delete Overpass fonts in UI root Use RCUE fonts Updated sync.sh Change menu rendering to match RCUE structure Allow RCUE Prefer Open Sans Regular font Remove background Remove width limit Remove jquery UI RCUE Navigation RCUE Header New header logo Adapt password expiration notification to new navigation Fix breadcrumb Fix search facet table styling - bug in chrome Fix action panel list styles Remove jquery button usage and unify button code Change undo to regular button Change undo-all to regular button New checkboxes and radio styles Always create radio and checkbox with label New Fluid form layout Use Fluid layout be default Do not display tooltip everywhere RCUE dialog implementation RCUE dialog close icon Dialog keyboard behavior Fluid layout in DNS Zone adder dialog Fix Association adder dialog styling CSS: make hostname in host adder dialog wider Do not open dialog in a container Remove left-margin from details-section Fix h1 style in dialog Fix radios behavior in automount map adder dialog CSS: fix network activity indicator position in control panel Fix padding of link buttons and labels in forms CSS: fix footer padding Fix hbac test styling Fix search input styling Combobox styles Action list styling Dojo event support in widgets Display required, enabled and error widget states in fluid layout Focus input on label click in fluid layout Do not show section header in unauthorized dialog username_r in password reset part of unauthorized dialog should be enabled as well Fix notification area Add style to dialog message area Update Dojo to 1.9.1 Remove last usage of jQuery UI Update jQuery to version 2.0.3 Add Font Awesome Change font-awesome to be compilable by lesscpy Font Awesome icons in header Replace icons with the ones from Font Awesome Status widgets icons Facet title status icons Use font awesome glyph for dialog close button Font awesome glyphs as checkboxes and radios Increase margin between facet control buttons Fix association adder dialog table-body position New header spinner Increase distance between control buttons and facet-tabs About dialog Use fluid layout in host adder dialog fqdn widget Web UI integration tests: maximize browser window by default Use only system fonts Trust domains Web UI webui: Focus expand/collapse link in batch_error dialog webui: Don't act on keyboard events which originated in different dialog Added empty value meaning to boolean formatter Declarative replacement of array item in specification object Fixed doc examples in Spec_mod Password Dialog Use general password dialog for host OTP Fix handling of action visibility change in action panel UI for OTP tokens UI for radius proxy UI for managing user-auth types Added QRcode generation to Web UI Support OTP in form based auth webui: use unique ids for checkboxes webui: Datetime parsing and formatting webui: remove hover effect from disabled action button webui-css: improve radio,checkbox keyboard support and color webui: do not use dom for getting selected automount keys webui-static: update metadata files webui: fix unit tests webui: better check for existing options in attributes_widgets webui: do not create ?hr? delimiter between sections webui: reflect enabled state in child widgets of a multivalued widget webui: change permissions UI to v2 webui: update license information of used third party code webui-ci: fix test_rebuild_membership_hosts on server without DNS webui: rename domNode to dom_node webui: make navigation module independent on app module webui: move RPC code from IPA module to its own module webui: replace IPA.command usage with rpc.command webui: field and widget binding refactoring webui: replace widget's hidden property with visible webui: change widget updated event into value change event webui-tests: binding test suite webui: facet container webui: FormMixin webui: ContainerMixin webui: standalone facet webui: activity widget webui: publish network activity topics webui: load page webui: validation summary widget webui: login screen widget webui: login page webui: authentication module webui: use asynchronous call for authentication webui: fix combobox styles to work with selenium testing webui-ci: adapt to new login screen webui: remove IPA.unauthorized_dialog webui: fix OTP Token add regression webui: regression - enable fields on idrange type change (add) webui-ci: adjust id range tests to new validator webui: fix switching between multiple_choice_section choices webui: otptoken-adder dialog - remove obsolete comment migration: fix import of wsgiref.util webui-ci: save screenshot on test failure webui-ci: decorate all webui tests with screenshot decorator rpcserver: login_password datetime fix in expiration check Increase Java stack size for Web UI build on aarch64 webui: remove logout.html webui: remove login.html webui: add PaternFly css webui: apply PatternFly login theme on reset_password.html webui: apply PatternFly theme on config pages webui: styles for alert icons webui: apply PatternFly theme on migration pages webui: remove remnants of jquery-ui webui: remove unused icons webui: remove unused collapsible feature from section webui: remove unused images webui: change absolutely positioned layout to fluid webui: remove column sizing in tables, use PF styles webui: change navigation from RCUE to PatternFly webui: adjust styles to PatternFly webui: display undo and multivalued delete buttons in input-group webui: allow multiple base section layouts webui: change breadcrumb to PatternFly webui: use h1 in facet title instead of h3 webui: remove action list widget webui: add action dropdown webui: add space between action buttons's icon and text webui: remove select action webui: add confirmation to action dropdown actions webui: move certificate actions to action dropdown webui: move user reset password action to action dropdown webui: patternFly dialog webui: adjust association adder dialog to PatternFly webui: activity indicators webui: improve pagination webui: do not show empty table footer webui: restyle automember default group webui: preload automember default group select list webui: adjust login page to PatternFly webui: use BS alerts in validation_summary_widget webui-ci: select search table item - chrome issue webui: remove old css for standalone pages webui: adjust header controls alignment webui: add search box placeholder text webui: change control buttons to normal buttons webui: certificate search - select search attribute only when defined webui: association adder dialog - change find label to filter webui: use dark color for facet titles without pkey webui-ci: assert_action_list_action webui: move host action panel actions to action dropdown webui: move service action panel actions to action dropdown webui: use normal buttons instead of link buttons in multivalued widget webui: move radius proxy action panel commands to header actions webui: proper alerts in dialogs webui: use propert alerts in header notification area webui: fix search box overlap in mobile mode webui: fix layout of QR code on wide screens webui: break long text in a code element in a modal webui: fix regression: enabled gid field on group add webui: add idnsSecInlineSigning option to DNS zone details facet webui: simplify self-service menu webui: display only dialogs which belong to current facet webui: handle back button when unauthenticated webui: fix SSH Key widget update webui: handle "unknown" result of automember-default-group-show webui: control sudo rule deny command tables by category switch webui: add sudoorder field to sudo rule page webui: move RPC result extraction logic to Adapter webui: expose krbprincipalexpiration webui: fix excessive registration of state change event listeners webui: support standalone facets in navigation module webui: generic routing webui: add parent link to widgets in ContainerMixin webui: plugin API webui-ci: adjust tests to dns changes webui: fix field's default value webui: don't limit permission search in privileges ldap2: add otp support to modify_password rpcserver: add otp support to change_password handler ipa-passwd: add OTP support webui: support password change with OTP in login screen webui: placeholder attribute support in textbox and textarea webui: add placeholders to login screen webui: rebase user password dialog on password dialog and add otp support webui: support otp in reset_password.html rpcserver: fix local vs utc time comparison webui: add confirmation for dns zone permission actions webui: dns forward zones webui-ci: dns forward zone tests webui-test: static metadata update webui-test: dns forward zone json data webui: fix detection of RPC command webui: send API version in RPC requests webui: extract rpc value from object envelope webui: base class for LoginScreen-like facets webui: add OTP token synchronization webui: add link pointing to OTP sync page to login webui: support global notifications in all containers webui: bind Login facet and OTP sync facet webui: fix confirmation mixin origin check webui: layer for standalone pages which use WebUI framework webui: add sync_otp.html webui-ci: fix action list action visibility and enablement assertion webui: support unlock user command webui: show notification instead of modal dialog on validation error webui: fix required error notification in multivalued widget webui: focus invalid widget on validation error webui-build: use /usr/share/java/js.jar instead of rhino.jar webui: change ipatokennotbefore and ipatokennotafter types to datetime webui: new navigation structure webui: display messages contained in API responses Petr ?pa?ek (15): Add timestamps to named debug logs in /var/named/data/named.run Clarify error message about IPv6 socket creation in ipa-cldap plugin Treat error during write to /etc/resolv.conf as non-fatal. Limit memberOf and refInt DS plugins to main IPA suffix. Remove working directory for bind-dyndb-ldap plugin. Use private IPv4 addresses for tests Rename variables in test xmlrpc/dns_plugin Use reserved domain names for tests tests: Move zone enable/disable tests to end of test_dns_plugin.py Fix regular expression for LOC records in DNS. Modify DNS tests with LOC records to workaround bug in python-dns. Clarify error message about missing DNS component in ipa-replica-prepare. Add wait_for_dns option to default.conf. Fix --ttl description for DNS zones Clarify LDAPClient docstrings about get_entry, get_entries and find_entries Rob Crittenden (5): Re-order NULL check in ipa_lockout. Change the way we determine if the host has a password set. Implement an IPA Foreman smartproxy server Clean up Smartproxy support, drop unused code Remove IPA Foreman Smart Proxy Simo Sorce (16): pwd-plugin: Fix ignored return error kdb-mspac: Fix out of bounds memset kdb-princ: Fix memory leak Add Delegation Info to MS-PAC Add krbticketPolicyAux objectclass if needed Fix license tag in python setup files Harmonize policy discovery to kdb driver Stop adding a default password policy reference Check for password expiration in pre-bind keytabs: Modularize setkeytab operation keytabs: Expose and modify key encoding function keytab: Add new extended operation to get a keytab. ipa-getkeytab: Modularize ldap_set_keytab function ipa-getkeytab: Add support for get_keytab extop man: Add -r option to ipa-getkeytab.1 Fix getkeytab code to always use implicit tagging. Sumit Bose (9): CLDAP: make sure an empty reply is returned on any error CLDAP: do not read IPA domain from hostname Use the right attribute with ipapwd_entry_checks for MagicRegen Remove AllowLMhash from the allowed IPA config strings Remove generation and handling of LM hashes CLDAP: do not prepend \\ CLDAP: generate NetBIOS name like ipa-adtrust-install does CLDAP: add unit tests for make_netbios_name extdom: do not return results from the wrong domain Thorsten Scherf (4): Fixed typo how to create an example gpg key Fixed typo in ipa-test-task man page Fixed various typos in ipa-client-install man page Fixed typo in ipa-replica-manage man page Timo Aaltonen (2): Use /usr/bin/python as fallback python path Don't search platform path Tom?? Babej (139): Remove support for IPA deployments with no persistent search Remove redundant shebangs Perform dirsrv tuning at platform level Make CS.cfg edits with CA instance stopped Fix incorrect error message occurence when re-adding the trust Log proper error message when defaultNamingContext not found Use getent admin at domain for nss check in ipa-client-install Do not add trust to AD in case of IPA realm-domain mismatch Warn user about realm-domain mismatch in install scripts trusts: Do not create ranges for subdomains in case of POSIX trust ipa-upgradeconfig: Remove backed up smb.conf ipa-adtrust-install: Add warning that we will break existing samba configuration adtrustinstance: Properly handle uninstall of AD trust instance adtrustinstance: Move attribute definitions from setup to init method ipatests: Extend the order plugin to properly handle inheritance Get the created range type in case of re-establishing trust ipatests: Add Active Directory support to configuration ipatests: Extend domain object with 'ad' role support and WinHosts ipatests: Extend IntegrationTest with multiple AD domain support ipatests: Create util module for ipatests ipatests: Add WinHost class ipatests: Add AD-integration related tasks ipatests: Add AD integration test case trusts: Fix typo in error message for realm-domain mismatch advice: Add legacy client configuration script using nss-ldap ipatests: Extend clear_sssd_cache to support non-systemd platforms ipatests: Restore SELinux context after restoring files from backup ipatests: Do not use /usr/bin hardcoded paths ipatests: Add support for extra roles referenced by a keyword ipatests: Use command -v instead of which in legacy client advice ipatests: Add integration tests for legacy clients ipatests: test_trust: use domain name instead of realm for user lookups platform: Add Fedora 19 platform file ipa-client-install: Publish CA certificate to systemwide store trusts: Do not pass base-id to the subdomain ranges trusts: Always stop and disable smb service on uninstall ipa-client-install: Always pass hostname to the ipa-join ipa-cldap: Cut NetBIOS name after 15 characters Fix incorrect path in error message on sysrestore failure acl: Remove krbPrincipalExpiration from list of admin's excluded attrs ipatests: Remove sudo calls from tasks ipatests: Check for legacy_client attribute presence if unapplying fixes ipatests: test_legacy_clients: Change "test group" to "testgroup" ipatests: Add records for all hosts in master's domain ipatests: Run restoring backup files and restoring their context in one session ipatests: legacy_clients: Test legacy clients with non-posix trust ipatests: Perform a connection test before preparing the client ipatests: Make sure we re-kinit as admin before adding the disabledipauser ipatests: Stop sssd service before deleting the cache ipatests: Add test cases for subdomain users on legacy clients ipatests: Change expected home directories returned by getent ipatests: Do not require group name resolution for the non-posix tests ipatests: Fix incorrect order of operations when restoring backup trusts: Remove usage of deprecated LDAP API man: sshd should be run at least once before client enrollment Prohibit deletion of active subdomain range ipatests: test_trust: Change expected home directories for posix users ipatests: Do not depend on the case of the attributes when testing ID ranges ipatests: Make sure that remnants of PKI are removed ipatests: legacy_clients: Use hostname instead of external hostname for AD subdomain ipatests: legacy_clients: Relax regex checks ipatests: tasks: Wait 2 seconds after restart of SSSD when clearing the cache ipa-pwd-extop: Fix memory leak in ipapwd_pre_bind ipa-range-check: Fix memory leaks when freeing range object Extend ipa-range-check DS plugin to handle range types ipatests: Fix apache semaphores prior to installing IPA server ipatests: tasks: Accept extra arguments when installing client ipatests: Allow using FQDN with trailing dot as final hostname ipatests: Fix incorrect UID/GID reference for subdomain users and groups ipa_range_check: Use special attributes to determine presence of RID bases ipa_range_check: Connect the new node of the linked list ipa_range_check: Make a new copy of forest_root_id attribute for range_info struct ipa_range_check: Do not fail when no trusted domain is available ipa_range_check: Fix typo when comparing strings using strcasecmp ipa_range_check: Change range_check return values from int to range_check_result_t enum ipatests: Extend test suite for ID ranges ipa-pwd-extop: Deny LDAP binds for accounts with expired principals ipalib: Add DateTime parameter ipatests: Cover DateTime in test_parameters.py ipalib: Expose krbPrincipalExpiration in CLI ipatests: Fix formatting errors in test_user_plugin.py ipatests: Add coverage for setting krbPrincipalExpiration ipatests: Add test for denying expired principals ipa-client: Set NIS domain name in the installer ipa-client-install: Configure sudo to use SSSD as data source ipatests: Add Sudo integration test ipatests: legacy clients: Do not use external hostnames for testing login to legacy clients from master ipatests: Setup SSSD debugging mode by default ipatests: Enable SSSD debugging on legacy clients with SSSD ipaplatform: Create separate module for platform files ipaplatform: Move service base platfrom related functionality to ipaplatform/base/service.py ipaplatform: Move default implementations of tasks from service.py.in ipaplatform: Create default implementations for tasks that were missing them ipaplatform: Add base fedora platform module ipaplatform: Moved Fedora 16 service implementations and refactored them as base Fedora module service implementations ipaplatform: Move restore_context and check_selinux_status implementations to base fedora platform tasks ipaplatform: Do not require custom Authconfig implementations from platform modules ipaplatform: Remove legacy redhat platform module ipaplatform: Move Fedora-specific implementations of tasks to fedora base platform file ipaplatform: Change platform dependant code in freeipa to use ipaplatform tasks ipaplatform: Change service code in freeipa to use ipaplatform services ipaplatform: Change paths dependant on ipaservices to use ipaplatform.paths ipaplatform: Remove redundant imports of ipaservices ipaplatform: Move all filesystem paths to ipaplatform.paths module ipaplatform: Remove remnants of the ipapython/platform ipaplatform: Change makefiles to accomodate for new platform package ipaplatform: Let fedora path module use PathNamespace class ipaplatform: Link to platform module during build time ipaplatform: Pylint fixes ipaplatform: Contain all the tasks in the TaskNamespace ipaplatform: Move hardcoded paths from Fedora platform files to path namespace sudorule: Allow unsetting sudoorder trusts: Allow reading ipaNTSecurityIdentifier in user and group objects trusts: Add more read attributes trusts: Allow reading system trust accounts by adtrust agents sudorule: PEP8 fixes in sudorule.py sudorule: Allow using hostmasks for setting allowed hosts sudorule: Allow using external groups as groups of runAsUsers sudorule: Make sure sudoRunAsGroup is dereferencing the correct attribute sudorule: Include externalhost and ipasudorunasextgroup in the list of default attributes sudorule: Allow adding deny commands when command category set to ALL sudorule: Make sure all the relevant attributes are checked when setting category to ALL sudorule: Fix the order of the parameters to have less chaotic output sudorule: Enforce category ALL checks on dirsrv level ipatests: test_sudo: Add tests for allowing hosts via hostmasks ipatests: test_sudo: Add coverage for external entries ipatests: test_sudo: Add coverage for category ALL validation ipatests: test_sudo: Fix assertions not assuming runasgroupcat set to ALL ipatests: test_sudo: Do not expect enumeration of runasuser groups ipatests: test_sudo: Expect root listed out if no RunAsUser available sudorule: Refactor add and remove external_post_callback ipaplatform: Document the platform tasks API ipaplatform: Drop the base authconfig class ipaplatform: Fix build warnings ipaplatform: Fix misspelled path constant ipaplatform: Move paths from installers to paths module ipa-client-install: Restart nisdomain service instead of starting ipaldap: Override conversion of nsds5replicalast{update,init}{start,end} ipalib: Use DateTime parameter class for OTP token timestamp attributes Xiao-Long Chen (1): Use /usr/bin/python2 From pviktori at redhat.com Tue Jul 8 10:01:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 12:01:29 +0200 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <53B3B806.1020807@redhat.com> References: <53AD5F83.5040003@redhat.com> <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> <53B125C4.9000708@redhat.com> <20140702051144.GR2417@dhcp-40-8.bne.redhat.com> <53B3AC27.1060909@redhat.com> <53B3B806.1020807@redhat.com> Message-ID: <53BBC179.50401@redhat.com> On 07/02/2014 09:43 AM, Petr Viktorin wrote: > On 07/02/2014 08:52 AM, Martin Kosek wrote: >> On 07/02/2014 07:11 AM, Fraser Tweedale wrote: [...] >>> Translations are lost as a result of this change, due to case >>> sensitive translation lookup by msgid. I guess our translation >>> workflow takes care of this - in which case, ACK. Pushed to: master: 03c25bd98e7fb16574a8bc0c4a9c9de851ae9bed ipa-4-0: 03c25bd98e7fb16574a8bc0c4a9c9de851ae9bed ipa-4-1: 03c25bd98e7fb16574a8bc0c4a9c9de851ae9bed -- Petr? From pviktori at redhat.com Tue Jul 8 13:12:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 15:12:55 +0200 Subject: [Freeipa-devel] [PATCH] 0620 ldap2 indirect membership processing: Use global limits if greater than per-query ones Message-ID: <53BBEE57.70002@redhat.com> Fix for https://fedorahosted.org/freeipa/ticket/4398 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0620-ldap2-indirect-membership-processing-Use-global-limi.patch Type: text/x-patch Size: 3322 bytes Desc: not available URL: From pviktori at redhat.com Tue Jul 8 13:13:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 15:13:48 +0200 Subject: [Freeipa-devel] [PATCH] 0621 test_xmlrpc: Update tests Message-ID: <53BBEE8C.6040604@redhat.com> Two test fixes for recent permission changes -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0621-test_xmlrpc-Update-tests.patch Type: text/x-patch Size: 2526 bytes Desc: not available URL: From pviktori at redhat.com Tue Jul 8 14:08:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Jul 2014 16:08:23 +0200 Subject: [Freeipa-devel] [PATCH] 0622 baseldap: Return empty string when no effective rights are found Message-ID: <53BBFB57.3020207@redhat.com> A fix for https://fedorahosted.org/freeipa/ticket/4359 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0622-baseldap-Return-empty-string-when-no-effective-right.patch Type: text/x-patch Size: 1171 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 8 14:17:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Jul 2014 16:17:44 +0200 Subject: [Freeipa-devel] [PATCH] 0622 baseldap: Return empty string when no effective rights are found In-Reply-To: <53BBFB57.3020207@redhat.com> References: <53BBFB57.3020207@redhat.com> Message-ID: <53BBFD88.5020204@redhat.com> On 8.7.2014 16:08, Petr Viktorin wrote: > A fix for https://fedorahosted.org/freeipa/ticket/4359 ACK. -- Jan Cholasta From npmccallum at redhat.com Tue Jul 8 17:08:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 08 Jul 2014 13:08:04 -0400 Subject: [Freeipa-devel] [SECURITY] Analysis of OTP Attack Vectors Message-ID: <1404839284.15830.1.camel@ipa.example.com> Dmitri, Ludwig and I had a meeting today to discuss the details of OTP attack vectors. This is the results of that meeting. We would love review as far and as wide as possible. === Rewind Attack === This attack is entirely theoretical. It works based on the premise that simultaneous writes to multiple servers in a replication set might, via delayed replication, cause a counter/watermark to go backwards. This attack is limited by the fact that the attack requires two successful authentications of the same token to occur on different replicas before the state from the first authentication is replicated to the second. As the attacker cannot control replication ordering or speed, the ability to perform this attack is also non-deterministic. This attack can be entirely eliminated by ensuring that counters/watermarks never move backwards via custom replication strategies. Implementing these would be rather difficult. Lacking custom replication strategies, the ratio of attack success is essentially the maximum replication time divided by the total authentication timing variance. Hence, mitigation of the attack can be achieved by either ensuring timely replication or by introducing random delays of sufficient duration to the login process. This attack can take two forms. In both forms, the attacker has managed to compromise a block of tokens of size N which, without a rewind attack, permits at most N authentications. Hence, the purpose of this attack is to expand an existing compromise into a worse compromise. In the first form of the attack, X simultaneous logins are executed against distinct replicas in order to obtain more than N authentications. If every attack was successful, the maximum number of authentications would be XN-1. If attacking Kerberos, there is no advantage to obtaining multiple simultaneous authentications. Hence, the effective attack rate of a Kerberos attack is (XN-1) / X, or, after rounding, N. In the case of logging into discrete, non-ticketed services, such as an HTTP authentication via LDAP, there may be some value to simultaneous logins, placing the expansion at XN-1. However, in this case, the authentication timing variance will generally increase, limiting the effectiveness of the attack. In the second form of the attack, the attacker will attempt to time his authentication with the user's authentication. Where the first form of the attack is "offensive" in attempting to expand the usable size of the compromised block, the second form is "defensive" in attempting to prevent the user's legitimate login from shrinking the usable size of the block. This attack is extremely difficult to perform. Not only is it extremely difficult to time an authentication with another user on top of infrastructure timing variances, the usable state of the block is also generally unknown. This creates a situation where there is an inverse relationship between the success rate of the used code and the value of of the resulting success. In other words, the more likely the attack is to succeed, the less valuable the successful attack is. In short, we concluded that a rewind attack while theoretically possible is both extremely difficult to implement and of limited value to an attacker. Hence, aside from an earnest attempt to ensure timely replication, we do not plan to implement specific countermeasures. === Replay Attack === Currently, this attack is somewhat practical and a known limitation of the FreeIPA TOTP implementation due to a lack of high watermark support. This attack has similar characteristics to the rewind attack in that it permits the expansion of a single OTP code into X authentications where X is the number of nodes in the replication set. Four options exist for mitigation. 1. Move the counter/watermark to an external solution. This could implement local storage at the cost of a single point of failure/bottleneck. It could also implement a more complex locking or replication solution. 2. Restrict reads/writes of the counter/watermark to a single 389DS master. In this case, replay would be limited to the case where failover has occurred before the writes could complete. The main cost of this option is a performance bottleneck. 3. Add a mechanism for priority replication to 389DS. While this wouldn't eliminate the replay attack, it could greatly reduce its probability. This option trades absolute certainty against the replay attack for authentication throughput. 4. Add a mechanism for synchronous replication to 389DS. This option would guarantee that any modification involving the counter would be replicated to all nodes before succeeding. This provides absolute certainty at an extreme performance penalty. It is also possible that some research into academic articles may reveal some better strategies for counter replication. In order to adequately assess the current situation, some replication performance testing is required. This would ideally measure the replication throughput of a single integer value across at least three nodes under load. === Action Items === Nathaniel will develop a patch implementing TOTP High Watermark support. This will only presume the current replication infrastructure. This will close the current TOTP replay hole. We will address the performance considerations as a second step. Ludwig will devise and publish some replication scalability testing using the above parameters. This should at least give us a good assessment of where we are in terms of replication performance and the size replay attack window size. Anyone familiar with the current state of research regarding counter replication should feel free to provide additional suggestions. From pviktori at redhat.com Wed Jul 9 09:40:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Jul 2014 11:40:07 +0200 Subject: [Freeipa-devel] [PATCH] 0622 baseldap: Return empty string when no effective rights are found In-Reply-To: <53BBFD88.5020204@redhat.com> References: <53BBFB57.3020207@redhat.com> <53BBFD88.5020204@redhat.com> Message-ID: <53BD0DF7.3000909@redhat.com> On 07/08/2014 04:17 PM, Jan Cholasta wrote: > On 8.7.2014 16:08, Petr Viktorin wrote: >> A fix for https://fedorahosted.org/freeipa/ticket/4359 > > ACK. > Thanks! Pushed to: master: fcd2922d86b523c0fe002b515fd91f00c97b6c5b ipa-4-1: fcd2922d86b523c0fe002b515fd91f00c97b6c5b ipa-4-0: fcd2922d86b523c0fe002b515fd91f00c97b6c5b -- Petr? From mbasti at redhat.com Wed Jul 9 16:29:08 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 09 Jul 2014 18:29:08 +0200 Subject: [Freeipa-devel] [PATCH 0101] Allow to add host if AAAA record exists Message-ID: <53BD6DD4.8060903@redhat.com> Patch attached. Ticket: https://fedorahosted.org/freeipa/ticket/4164 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0101-Allow-to-add-host-if-AAAA-record-exists.patch Type: text/x-patch Size: 3464 bytes Desc: not available URL: From tbabej at redhat.com Thu Jul 10 08:56:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 10 Jul 2014 10:56:41 +0200 Subject: [Freeipa-devel] [PATCH 0239] trusts: Validate missing trust secret properly Message-ID: <53BE5549.9060900@redhat.com> Hi, Detect the situation if the user passes empty trust secret and error out properly. https://fedorahosted.org/freeipa/ticket/4266 -- 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-0239-trusts-Validate-missing-trust-secret-properly.patch Type: text/x-patch Size: 1815 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 10 12:23:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Jul 2014 14:23:56 +0200 Subject: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights Message-ID: <53BE85DC.5070207@redhat.com> Reproduction: * add 'extensibleObject' object class to target object https://fedorahosted.org/freeipa/ticket/4380 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0696-webui-support-wildcard-attribute-level-rights.patch Type: text/x-patch Size: 2501 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 10 12:29:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Jul 2014 14:29:08 +0200 Subject: [Freeipa-devel] [PATCH] 697-702 webui: usability improvements in attribute widget Message-ID: <53BE8714.2090303@redhat.com> ticket: https://fedorahosted.org/freeipa/ticket/4253 == [PATCH] 697 webui: improve usability of attributes widget == Attributes widget layour was changed from tiny table which allowed to display only few options to a checkbox list with multiple columns (depends on container). Check all attributes option was removed to force the user to read through the attributes which he selects. Initial version authored by: Adam Misnyovszki == [PATCH] 698 webui: add filter to attributes widget == Adds filter field to attribute box in permissions for better user experience. User can then quickly find the desired attribute. Initial version of the patch authored by: Adam Misnyovszki == [PATCH] 699 webui: optimize (re)creation of option widget == There is a case where attributes widget can contain > 1000 items. It's about 3000 nodes. It's slow in jQuery. Simple move to dojo speeds it up (is closer to native calls) while maintaining developer friendliness. Now the biggest lag is in browser's render. It's probably not worth developer time to optimize that. == [PATCH] 700 webui: custom attr in attributes widget == Web UI doesn't always know what are the possible attributes for target object. This will allow to add custom attributes if necessary. == [PATCH] 701 webui: attr widget: get list of possible attrs from ipapermdefaultattr == Very useful for managed permissions since the list of attrs in metadata might be smaller that default attributes. This smooths behavior if one removes an attr from effective attrs which is not in metadata. Without this it will disappear from the list and one has to add it manually through 'Add'. [PATCH] 702 webui: option_widget_base: sort options -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0702-webui-option_widget_base-sort-options.patch Type: text/x-patch Size: 2593 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0701-webui-attr-widget-get-list-of-possible-attrs-from-ip.patch Type: text/x-patch Size: 1836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0700-webui-custom-attr-in-attributes-widget.patch Type: text/x-patch Size: 6945 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0699-webui-optimize-re-creation-of-option-widget.patch Type: text/x-patch Size: 3555 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0698-webui-add-filter-to-attributes-widget.patch Type: text/x-patch Size: 3753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0697-webui-improve-usability-of-attributes-widget.patch Type: text/x-patch Size: 8388 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 10 12:38:11 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Jul 2014 14:38:11 +0200 Subject: [Freeipa-devel] [PATCH] 703-707 webui: improvements in permission details page Message-ID: <53BE8933.80506@redhat.com> mostly: https://fedorahosted.org/freeipa/ticket/4254 but also some fixes for little regressions == [PATCH] 703 webui: reflect readonly state == Separate update of read-only state from update of value. It should be possible to switch from read-only UI to editable UI without value change. https://fedorahosted.org/freeipa/ticket/4254 == [PATCH] 704 webui: fix add of input group class == The input-group class was added based on visibility of child elements. This failed when it had to be determined *before* displaying the widget. Now it's added if the buttons are not hidden by `display: none` CSS rule. == [PATCH] 705 webui: show managed fields as readonly and not disabled == Visible read-only fields are no longer displayed as disabled in permission details facet. https://fedorahosted.org/freeipa/ticket/4254 == [PATCH] 706 webui: fix selection of empty value in a select widget == Little regression - select widget could not handle empty or no array as an input value. It broke 'undo' operation in Permissions' 'Type' attribute while switching between '' and some value. == [PATCH] 707 webui: disable ipapermbindruletype if permission in a privilege == User is not able to change Bind Rule Type if permission is already member of a privilege. Let's disable it and don't confuse user. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0707-webui-disable-ipapermbindruletype-if-permission-in-a.patch Type: text/x-patch Size: 1836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0706-webui-fix-selection-of-empty-value-in-a-select-widge.patch Type: text/x-patch Size: 1118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0705-webui-show-managed-fields-as-readonly-and-not-disabl.patch Type: text/x-patch Size: 1750 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0704-webui-fix-add-of-input-group-class.patch Type: text/x-patch Size: 1263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0703-webui-reflect-readonly-state.patch Type: text/x-patch Size: 9238 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 10 12:38:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Jul 2014 14:38:54 +0200 Subject: [Freeipa-devel] [PATCH] 708 webui: fix disabled state of service's PAC type Message-ID: <53BE895E.4090306@redhat.com> Nested options (MS-PAC and PAD) of service's PAC type should be disabled if no value is supplied (default value is "Inherited from server configuration"). That was not the case - regression. This patch fixes it and along with it simplifies the update method of option_widget_base to be more comprehensible. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0708-webui-fix-disabled-state-of-service-s-PAC-type.patch Type: text/x-patch Size: 5804 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 10 13:02:23 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Jul 2014 15:02:23 +0200 Subject: [Freeipa-devel] [PATCH] 697-702 webui: usability improvements in attribute widget In-Reply-To: <53BE8714.2090303@redhat.com> References: <53BE8714.2090303@redhat.com> Message-ID: <53BE8EDF.8000606@redhat.com> There is an issue in patch #701, new version attached. On 10.7.2014 14:29, Petr Vobornik wrote: > ticket: https://fedorahosted.org/freeipa/ticket/4253 > > == [PATCH] 697 webui: improve usability of attributes widget == > > Attributes widget layour was changed from tiny table which allowed > to display only few options to a checkbox list with multiple > columns (depends on container). > > Check all attributes option was removed to force the user > to read through the attributes which he selects. > > Initial version authored by: Adam Misnyovszki > > > == [PATCH] 698 webui: add filter to attributes widget == > > Adds filter field to attribute box in permissions for better user > experience. User can then quickly find the desired attribute. > > Initial version of the patch authored by: Adam Misnyovszki > > > == [PATCH] 699 webui: optimize (re)creation of option widget == > > There is a case where attributes widget can contain > 1000 items. > It's about 3000 nodes. It's slow in jQuery. Simple move to dojo > speeds it up (is closer to native calls) while maintaining developer > friendliness. > > Now the biggest lag is in browser's render. It's probably not worth > developer time to optimize that. > > > == [PATCH] 700 webui: custom attr in attributes widget == > > Web UI doesn't always know what are the possible attributes > for target object. This will allow to add custom attributes > if necessary. > > == [PATCH] 701 webui: attr widget: get list of possible attrs from > ipapermdefaultattr == > > Very useful for managed permissions since the list of attrs in metadata > might be smaller that default attributes. This smooths behavior if one > removes an attr from effective attrs which is not in metadata. Without > this it will disappear from the list and one has to add it manually > through 'Add'. > > > [PATCH] 702 webui: option_widget_base: sort options > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0701-1-webui-attr-widget-get-list-of-possible-attrs-from-ip.patch Type: text/x-patch Size: 1853 bytes Desc: not available URL: From purpleidea at gmail.com Fri Jul 11 06:17:10 2014 From: purpleidea at gmail.com (James) Date: Fri, 11 Jul 2014 02:17:10 -0400 Subject: [Freeipa-devel] Running ipa-replica-prepare on a replica Message-ID: I installed IPA on host A, did a replica prepare, and then installed it on host B. Running ipa-replica-prepare on B yield this error: > A selfsign CA backend can only prepare on the original master This error doesn't seem to be in the current git master anymore. Has this limitation been removed? Can someone explain if you can "ipa-replica-prepare" from any new master, and starting at what version please? Assume I installed the first host with --selfsign. I'm particularly interested in understanding why or why not you can do this (or couldn't do this). I'm currently using ipa-server v 3.0.0 Thanks, James From purpleidea at gmail.com Fri Jul 11 06:40:28 2014 From: purpleidea at gmail.com (James) Date: Fri, 11 Jul 2014 02:40:28 -0400 Subject: [Freeipa-devel] RPM's of different ipa versions Message-ID: This page seems to suggest that there are continuous builds available: http://www.freeipa.org/page/Downloads#Bleeding_Edge It seems this hasn't been updated since 2013, except the .repo files have recently? Does this still exist? Are there archives for each point release somewhere? In particular, I'm interested in knowing if there are repos with rpm's for each version/os. (>=v.3.0.0 and Fedora/CentOS6+/RHEL6+) Thanks, James From npmccallum at redhat.com Fri Jul 11 16:43:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 11 Jul 2014 12:43:53 -0400 Subject: [Freeipa-devel] [PATCH 0057] Add TOTP watermark support Message-ID: <1405097033.3032.5.camel@ipa.example.com> This prevents the reuse of TOTP tokens by recording the last token interval that was used. This will be replicated as normal. However, this patch does not increase the number of writes to the database in the standard authentication case. This is because it also eliminates an unnecessary write during authentication. Hence, this patch should be write-load neutral with the existing code. Further performance enhancement is desired, but is outside the scope of this patch. https://fedorahosted.org/freeipa/ticket/4410 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0057-Add-TOTP-watermark-support.patch Type: text/x-patch Size: 10636 bytes Desc: not available URL: From purpleidea at gmail.com Sat Jul 12 06:40:49 2014 From: purpleidea at gmail.com (James) Date: Sat, 12 Jul 2014 02:40:49 -0400 Subject: [Freeipa-devel] Correct firewall ports for multi-master replicas Message-ID: <1405147249.8177.29.camel@freed> Hi freeipa-devel, I just added automatic firewalling for puppet-ipa. (Disclaimer it's currently untested...) What I'm missing is an exact and exhaustive list of exactly which ports each replica needs open for each other replica. I'm hoping that this list is symmetrical. If this list changes based on which $args are used to install FreeIPA, let me know too. These will get inserted here (if you're curious): https://github.com/purpleidea/puppet-ipa/commit/31ede1a185f3d4bd5dd9848613e24a19f460f595#diff-e26063ec0e856ceac05cf5b4132f3330R61 Thanks! James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From lslebodn at redhat.com Sat Jul 12 18:22:58 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 12 Jul 2014 20:22:58 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <533A7E49.604@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> <533A7E49.604@redhat.com> Message-ID: <20140712182258.GA18398@mail.corp.redhat.com> On (01/04/14 10:52), Tomas Babej wrote: > >On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: >> On Tue, 01 Apr 2014, Tomas Babej wrote: >>> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>> >>> The ipa-range-check plugin used to determine the range type depending >>> on the value of the attributes such as RID or secondary RID base. This >>> approached caused variety of issues since the portfolio of ID range >>> types expanded. >>> >>> The patch makes sure the following rules are implemented: >>> * No ID range pair can overlap on base ranges, with exception >>> of two ipa-ad-trust-posix ranges belonging to the same forest >>> * For any ID range pair of ranges belonging to the same domain: >>> * Both ID ranges must be of the same type >>> * For ranges of ipa-ad-trust type or ipa-local type: >>> * Primary RID ranges can not overlap >>> * For ranges of ipa-local type: >>> * Primary and secondary RID ranges can not overlap >>> * Secondary RID ranges cannot overlap >>> >>> For the implementation part, the plugin was extended with a domain ID >>> to forest root domain ID mapping derivation capabilities. >>> >>> https://fedorahosted.org/freeipa/ticket/4137 >>> >>> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >>> +struct domain_info { >>> + char *domain_id; >>> + char *forest_root_id; >>> + struct domain_info *next; >>> +}; >>> + >>> +static void free_domain_info(struct domain_info *info) { >>> + if (info != NULL) { >>> + slapi_ch_free_string(&(info->domain_id)); >>> + slapi_ch_free_string(&(info->forest_root_id)); >>> + free_domain_info(info->next); >>> + free(info); >>> + } >>> +} >> Please, don't use recursion in the freeing part, there is really no >> pressing need to do so. Just use while() like you do in >> get_forest_root_id(): >> >>> +/* Searches for the domain_info struct with the specified domain_id >>> + * in the linked list. Returns the forest root domain's ID, or NULL for >>> + * local ranges. */ >>> + >>> +static char* get_forest_root_id(struct domain_info *head, char* >>> domain_id) { >>> + >>> + /* For local ranges there is no forest root domain, >>> + * so consider only ranges with domain_id set */ >>> + if (domain_id != NULL) { >>> + while(head) { >>> + if (strcasecmp(head->domain_id, domain_id) == 0) { >>> + return head->forest_root_id; >>> + } >>> + head = head->next; >>> + } >>> + } >>> + >>> + return NULL; >>> +} >>> + >> >> > >Fixed, updated patch attached. > >-- >Tomas Babej >Associate Software Engineer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > >>From f98082d6cfd902417af94d7cd22d3cc85980a782 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 5 Mar 2014 12:28:18 +0100 >Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types > >The ipa-range-check plugin used to determine the range type depending >on the value of the attributes such as RID or secondary RID base. This >approached caused variety of issues since the portfolio of ID range >types expanded. > >The patch makes sure the following rules are implemented: > * No ID range pair can overlap on base ranges, with exception > of two ipa-ad-trust-posix ranges belonging to the same forest > * For any ID range pair of ranges belonging to the same domain: > * Both ID ranges must be of the same type > * For ranges of ipa-ad-trust type or ipa-local type: > * Primary RID ranges can not overlap > * For ranges of ipa-local type: > * Primary and secondary RID ranges can not overlap > * Secondary RID ranges cannot overlap > >For the implementation part, the plugin was extended with a domain ID >to forest root domain ID mapping derivation capabilities. > >https://fedorahosted.org/freeipa/ticket/4137 >--- //snip > >- no_overlap = ranges_overlap(new_range, old_range); >+ ranges_valid = check_ranges(new_range, old_range); > free_range_info(old_range); > old_range = NULL; >- if (no_overlap != 0) { >+ if (ranges_valid != 0) { > ret = LDAP_CONSTRAINT_VIOLATION; > >- switch (no_overlap){ >+ switch (ranges_valid){ > case 1: > errmsg = "New base range overlaps with existing base range."; > break; >@@ -417,6 +627,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > case 5: > errmsg = "New secondary rid range overlaps with existing primary rid range."; > break; >+ case 6: >+ errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; > default: There is a missing break. Ithink it is a problem, because you do not want to fall through to the defaul and override errmsg. Smple patch is attached. LS -------------- next part -------------- >From 2f9060c011e7dd719887d7935a809887e26ac1e5 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Sat, 12 Jul 2014 18:28:38 +0200 Subject: [PATCH 2/4] Add missing break Wrong error message would be used for in case of RANGE_CHECK_DIFFERENT_TYPE_IN_DOMAIN. Missing break will cause fall through to the default section. --- daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c index d659dc7d8b510cb5719dc9ff1db2ef55e2d237c4..1fd543c185cda0a7b871875f1d4ba969a7bf910c 100644 --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c @@ -660,6 +660,7 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) break; case RANGE_CHECK_DIFFERENT_TYPE_IN_DOMAIN: errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; + break; default: errmsg = "New range overlaps with existing one."; break; -- 1.9.3 From lslebodn at redhat.com Sat Jul 12 18:38:07 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 12 Jul 2014 20:38:07 +0200 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> Message-ID: <20140712183806.GB18398@mail.corp.redhat.com> On (23/06/14 14:35), Simo Sorce wrote: >----- Original Message ----- >> ----- Original Message ----- >> > > Can you check if ipaProtectedOperation is in the aci attribute in the >> > > base tree object ? >> > > It should be there as excluded, and that should cause admin to not be >> > > able to retrieve keytabs. >> > >> > It was not. While running ipa-ldap-updater I got the following: >> > InvalidSyntax: ACL Syntax Error(-5):(targetattr= >> > \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are >> > allowed to rekey any entity\22; allow(write) groupdn = >> > \22ldap:///cn=admins: Invalid syntax. >> >> Uhmm I do not see anything obviously wrong with ACI instruction, it looks >> just like the one I replace, Ideas ? >> Do you have ipaProtectedOperation in the schema ? >> >> (I rebased patch 3 but will wait to send a patchset until we understand (and >> fix) why this is failing to update. > >Ok, apparently it was a quoting issue in the .update files, hopefully that's >the only issue (I am at a conference today and do not have my test env. handy). > >The attached patches are rebased on the latest master. > >Simo. >From af7364cda7f5ef5948ce782bd5eded0b57583029 Mon Sep 17 00:00:00 2001 >From: Simo Sorce >Date: Tue, 17 Sep 2013 00:30:14 -0400 >Subject: [PATCH 3/6] keytab: Add new extended operation to get a keytab. > >This new extended operation allow to create new keys or retrieve >existing ones. The new set of keys is returned as a ASN.1 structure >similar to the one that is passed in by the 'set keytab' extended >operation. > >Access to the operation is regulated through a new special ACI that >allows 'retrieval' only if the user has access to an attribute named >ipaProtectedOperation postfixed by the subtypes 'read_keys' and >'write_keys' to distinguish between creation and retrieval operation. > >For example for allowing retrieval by a specific user the following ACI >is set on cn=accounts: > >(targetattr="ipaProtectedOperation;read_keys") ... > ... userattr=ipaAllowedToPerform;read_keys#USERDN) > >This ACI matches only if the service object hosts a new attribute named >ipaAllowedToPerform that holds the DN of the user attempting the >operation. > >Resolves: >https://fedorahosted.org/freeipa/ticket/3859 >--- > .../ipa-pwd-extop/ipa_pwd_extop.c | 571 +++++++++++++++++++++ > install/share/60basev3.ldif | 3 + > install/share/default-aci.ldif | 7 + > install/updates/20-aci.update | 13 +- > util/ipa_krb5.h | 1 + > 5 files changed, 594 insertions(+), 1 deletion(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >index c0bb9fda26172699e9ae7628f61b763c746188fe..65a5d41f9ea85689952e818fa4e8018c39786db8 100644 >--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >@@ -1268,6 +1268,571 @@ free_and_return: > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; > } > >+/* Format of getkeytab request >+ * >+ * KeytabGetRequest ::= CHOICE { >+ * newkeys [0] Newkeys, >+ * curkeys [1] CurrentKeys, >+ * reply [2] Reply >+ * } >+ * >+ * NewKeys ::= SEQUENCE { >+ * serviceIdentity [0] OCTET STRING, >+ * enctypes [1] SEQUENCE OF Int16 >+ * password [2] OCTET STRING OPTIONAL, >+ * } >+ * >+ * CurrentKeys ::= SEQUENCE { >+ * serviceIdentity [0] OCTET STRING, >+ * } >+ */ >+ >+#define GK_REQUEST_NEWKEYS (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 0) >+#define GK_REQUEST_CURKEYS (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1) >+#define GKREQ_SVCNAME_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1) >+#define GKREQ_ENCTYPES_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 1) >+#define GKREQ_PASSWORD_TAG (LBER_CLASS_CONTEXT | LBER_CONSTRUCTED | 2) >+ >+static int decode_getkeytab_request(struct berval *extop, bool *wantold, >+ char **_svcname, char **_password, >+ krb5_key_salt_tuple **kenctypes, >+ int *num_kenctypes, char **_err_msg) >+{ >+ int rc = LDAP_OPERATIONS_ERROR; >+ char *err_msg = NULL; >+ BerElement *ber = NULL; >+ ber_len_t tlen; >+ ber_tag_t rtag; >+ ber_tag_t ttag; >+ ber_tag_t ctag; >+ char *svcname = NULL; >+ char *password = NULL; >+ ber_int_t enctype; >+ krb5_key_salt_tuple *enctypes = NULL; >+ int num = 0; >+ >+ ber = ber_init(extop); >+ if (ber == NULL) { >+ err_msg = "KeytabGet Request decode failed.\n"; >+ rc = LDAP_PROTOCOL_ERROR; >+ goto done; >+ } >+ >+ /* check this is a request */ >+ rtag = ber_peek_tag(ber, &tlen); >+ if (rtag != GK_REQUEST_NEWKEYS && rtag != GK_REQUEST_CURKEYS) { >+ LOG_FATAL("ber_peek_tag failed, wrong request type\n"); >+ err_msg = "Invalid payload.\n"; >+ rc = LDAP_PROTOCOL_ERROR; >+ goto done; >+ } >+ >+ /* ber parse code */ >+ ttag = ber_scanf(ber, "{t[a]", &ctag, &svcname); >+ if (ttag == LBER_ERROR || ctag != GKREQ_SVCNAME_TAG) { >+ LOG_FATAL("ber_scanf failed to decode service name\n"); >+ err_msg = "Invalid payload.\n"; >+ rc = LDAP_PROTOCOL_ERROR; >+ goto done; >+ } >+ >+ if (rtag == GK_REQUEST_CURKEYS) { >+ rc = LDAP_SUCCESS; >+ goto done; >+ } >+ >+ ttag = ber_peek_tag(ber, &tlen); >+ if (ttag != GKREQ_ENCTYPES_TAG) { >+ LOG_FATAL("ber_peek_tag failed to find enctypes\n"); >+ err_msg = "Invalid payload.\n"; >+ rc = LDAP_PROTOCOL_ERROR; >+ goto done; >+ } >+ ttag = ber_peek_tag(ber, &tlen); >+ for (num = 0; ttag == LBER_INTEGER; num++) { >+ if ((num % 10) == 0) { >+ /* allocate space for at least 10 more enctypes */ >+ enctypes = realloc(enctypes, >+ (num + 10) * sizeof(krb5_key_salt_tuple)); step 1: successful allocation >+ if (!enctypes) { >+ LOG_FATAL("allocation failed\n"); >+ err_msg = "Internal error\n"; >+ rc = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ } >+ >+ ttag = ber_scanf(ber, "i", &enctype); step 2: ber_scanf can return LBER_ERROR >+ if (ttag == LBER_ERROR) { >+ LOG_FATAL("ber_scanf failed to decode enctype\n"); >+ err_msg = "Invalid payload.\n"; >+ rc = LDAP_PROTOCOL_ERROR; step 3: variable rc is set to LDAP_PROTOCOL_ERROR >+ goto done; >+ } >+ >+ enctypes[num].ks_enctype = enctype; >+ enctypes[num].ks_salttype = KRB5_KDB_SALTTYPE_NORMAL; >+ ttag = ber_peek_tag(ber, &tlen); >+ } >+ >+ /* ttag peek done as last step of the previous for loop */ >+ if (ttag == GKREQ_PASSWORD_TAG) { >+ /* optional password present */ >+ ttag = ber_scanf(ber, "[a]", &password); >+ if (ttag == LBER_ERROR) { >+ LOG_FATAL("ber_scanf failed to decode password\n"); >+ err_msg = "Invalid payload.\n"; >+ rc = LDAP_PROTOCOL_ERROR; >+ goto done; >+ } >+ } >+ >+ rc = LDAP_SUCCESS; >+ >+done: >+ if (rc != LDAP_SUCCESS) { step 4: taking true branch beacuse rc is LDAP_PROTOCOL_ERROR >+ free(password); >+ free(svcname); >+ *_err_msg = err_msg; >+ } else { >+ *_password = password; >+ *_svcname = svcname; >+ *wantold = (rtag == GK_REQUEST_CURKEYS); >+ *kenctypes = enctypes; >+ *num_kenctypes = num; >+ } >+ if (ber) ber_free(ber, 1); >+ return rc; step 5: Variable "enctypes" going out of scope leaks the storage it points to. Patch0004 is attached. LS -------------- next part -------------- >From 0f931433707d8a5ddbb9870192a28ce7bbd6a624 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Sat, 12 Jul 2014 18:31:42 +0200 Subject: [PATCH 3/4] Remove unsed local variable ber. --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c index ca021cac71da690a498fe3003fae1babb30456c1..2f9bed4f8559c171e794420aaedd5407e330c2e3 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c @@ -1639,7 +1639,6 @@ static int ipapwd_getkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg) krb5_context krbctx = NULL; krb5_error_code krberr; struct berval *extop_value = NULL; - BerElement *ber = NULL; char *service_name = NULL; char *svcname; Slapi_Entry *target_entry = NULL; @@ -1827,7 +1826,6 @@ free_and_return: } free(svals); } - if (ber) ber_free(ber, 1); if (bvp) ber_bvfree(bvp); return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; -- 1.9.3 -------------- next part -------------- >From 8c1443fd22e60129202818814a485dbcea2fc18f Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Sat, 12 Jul 2014 18:39:11 +0200 Subject: [PATCH 4/4] Fix memory leak in case of failure in decode_getkeytab_re daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c:1355: alloc_fn: Storage is returned from allocation function "realloc". daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c:1355: var_assign: Assigning: "enctypes" = storage returned from "realloc(enctypes, (num + 10) * 8UL)". daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c:1393: Condition rc != LDAP_SUCCESS, taking true branch daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c:1405: leaked_storage: Variable "enctypes" going out of scope leaks the storage it points to. --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c index 2f9bed4f8559c171e794420aaedd5407e330c2e3..f0346a343188930dfc90e19d2e5d38cb30741b90 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c @@ -1393,6 +1393,7 @@ done: if (rc != LDAP_SUCCESS) { free(password); free(svcname); + free(enctypes); *_err_msg = err_msg; } else { *_password = password; -- 1.9.3 From lslebodn at redhat.com Sat Jul 12 18:40:54 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 12 Jul 2014 20:40:54 +0200 Subject: [Freeipa-devel] [PATCH] Fix warning: Using uninitialized value ld. Message-ID: <20140712184054.GC18398@mail.corp.redhat.com> ehlo, If create_getkeytab_control fails variable uninitialized pointer 'ld' will be used in done section. Simple patch is attached. -------------- next part -------------- >From 6d882d2ede4d639dde2883bb147f3921fc46ae1c Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Sat, 12 Jul 2014 18:18:21 +0200 Subject: [PATCH 1/4] Fix warning: Using uninitialized value ld. If create_getkeytab_control fails variable uninitialized pointer 'ld' will be used. --- ipa-client/ipa-getkeytab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipa-client/ipa-getkeytab.c b/ipa-client/ipa-getkeytab.c index d0e975f1a24f15d6b8d109864e5af3548bcba4da..c887cff9bb5e3688cc84b5c28f791eb922f4fe61 100644 --- a/ipa-client/ipa-getkeytab.c +++ b/ipa-client/ipa-getkeytab.c @@ -569,7 +569,7 @@ static int ldap_get_keytab(krb5_context krbctx, bool generate, char *password, struct krb_key_salt *es = NULL; int num_es = 0; struct berval *control = NULL; - LDAP *ld; + LDAP *ld = NULL; LDAPControl **srvctrl = NULL; BerElement *ber = NULL; ber_tag_t rtag; -- 1.9.3 From jcholast at redhat.com Mon Jul 14 05:58:16 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Jul 2014 07:58:16 +0200 Subject: [Freeipa-devel] [PATCH 0239] trusts: Validate missing trust secret properly In-Reply-To: <53BE5549.9060900@redhat.com> References: <53BE5549.9060900@redhat.com> Message-ID: <53C37178.3020005@redhat.com> On 10.7.2014 10:56, Tomas Babej wrote: > Hi, > > Detect the situation if the user passes empty trust secret and > error out properly. > > https://fedorahosted.org/freeipa/ticket/4266 IMO this is less ugly: + raise errors.ValidationError( + name=_('AD Trust setup'), + error=_('Not enough arguments specified to perform trust ' + 'setup')) -- Jan Cholasta From jcholast at redhat.com Mon Jul 14 06:34:18 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Jul 2014 08:34:18 +0200 Subject: [Freeipa-devel] [PATCH] 0620 ldap2 indirect membership processing: Use global limits if greater than per-query ones In-Reply-To: <53BBEE57.70002@redhat.com> References: <53BBEE57.70002@redhat.com> Message-ID: <53C379EA.7000507@redhat.com> On 8.7.2014 15:12, Petr Viktorin wrote: > Fix for https://fedorahosted.org/freeipa/ticket/4398 ACK. -- Jan Cholasta From jcholast at redhat.com Mon Jul 14 08:11:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Jul 2014 10:11:10 +0200 Subject: [Freeipa-devel] [PATCH] Fix warning: Using uninitialized value ld. In-Reply-To: <20140712184054.GC18398@mail.corp.redhat.com> References: <20140712184054.GC18398@mail.corp.redhat.com> Message-ID: <53C3909E.3040207@redhat.com> On 12.7.2014 20:40, Lukas Slebodnik wrote: > ehlo, > > If create_getkeytab_control fails variable uninitialized pointer 'ld' > will be used in done section. > > Simple patch is attached. Obvious ACK (if that's even necessary, since the patch is one-liner). -- Jan Cholasta From pspacek at redhat.com Mon Jul 14 08:19:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Jul 2014 10:19:06 +0200 Subject: [Freeipa-devel] RPM's of different ipa versions In-Reply-To: References: Message-ID: <53C3927A.5070101@redhat.com> On 11.7.2014 08:40, James wrote: > This page seems to suggest that there are continuous builds available: > > http://www.freeipa.org/page/Downloads#Bleeding_Edge > > It seems this hasn't been updated since 2013, except the .repo files > have recently? Does this still exist? Are there archives for each > point release somewhere? > > In particular, I'm interested in knowing if there are repos with rpm's > for each version/os. (>=v.3.0.0 and Fedora/CentOS6+/RHEL6+) John, could you comment on this? -- Petr^2 Spacek From pspacek at redhat.com Mon Jul 14 08:20:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Jul 2014 10:20:36 +0200 Subject: [Freeipa-devel] Correct firewall ports for multi-master replicas In-Reply-To: <1405147249.8177.29.camel@freed> References: <1405147249.8177.29.camel@freed> Message-ID: <53C392D4.701@redhat.com> On 12.7.2014 08:40, James wrote: > Hi freeipa-devel, > > I just added automatic firewalling for puppet-ipa. (Disclaimer it's > currently untested...) > > What I'm missing is an exact and exhaustive list of exactly which ports > each replica needs open for each other replica. I'm hoping that this > list is symmetrical. AFAIK ipa-replica-conncheck utility and ipa-server-install script should show list of required ports. -- Petr^2 Spacek From tbabej at redhat.com Mon Jul 14 09:31:03 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Jul 2014 11:31:03 +0200 Subject: [Freeipa-devel] [PATCH 0240] ipatests: tasks: Fix dns configuration for trusts Message-ID: <53C3A357.5050707@redhat.com> Hi, Properly configure forwarders to the AD zone with respect to newly created ipa dnsforwardzone commands. https://fedorahosted.org/freeipa/ticket/4401 -- 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-0240-ipatests-tasks-Fix-dns-configuration-for-trusts.patch Type: text/x-patch Size: 2399 bytes Desc: not available URL: From tbabej at redhat.com Mon Jul 14 09:41:17 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Jul 2014 11:41:17 +0200 Subject: [Freeipa-devel] [PATCH 0239] trusts: Validate missing trust secret properly In-Reply-To: <53C37178.3020005@redhat.com> References: <53BE5549.9060900@redhat.com> <53C37178.3020005@redhat.com> Message-ID: <53C3A5BD.5080409@redhat.com> On 07/14/2014 07:58 AM, Jan Cholasta wrote: > On 10.7.2014 10:56, Tomas Babej wrote: >> Hi, >> >> Detect the situation if the user passes empty trust secret and >> error out properly. >> >> https://fedorahosted.org/freeipa/ticket/4266 > > IMO this is less ugly: > > + raise errors.ValidationError( > + name=_('AD Trust setup'), > + error=_('Not enough arguments specified to perform > trust ' > + 'setup')) > Sure, fixed. -- 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-0239-2-trusts-Validate-missing-trust-secret-properly.patch Type: text/x-patch Size: 1730 bytes Desc: not available URL: From tbabej at redhat.com Mon Jul 14 09:43:05 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Jul 2014 11:43:05 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <20140712182258.GA18398@mail.corp.redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> <533A7E49.604@redhat.com> <20140712182258.GA18398@mail.corp.redhat.com> Message-ID: <53C3A629.1040906@redhat.com> On 07/12/2014 08:22 PM, Lukas Slebodnik wrote: > On (01/04/14 10:52), Tomas Babej wrote: >> On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: >>> On Tue, 01 Apr 2014, Tomas Babej wrote: >>>> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >>>> From: Tomas Babej >>>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>>> >>>> The ipa-range-check plugin used to determine the range type depending >>>> on the value of the attributes such as RID or secondary RID base. This >>>> approached caused variety of issues since the portfolio of ID range >>>> types expanded. >>>> >>>> The patch makes sure the following rules are implemented: >>>> * No ID range pair can overlap on base ranges, with exception >>>> of two ipa-ad-trust-posix ranges belonging to the same forest >>>> * For any ID range pair of ranges belonging to the same domain: >>>> * Both ID ranges must be of the same type >>>> * For ranges of ipa-ad-trust type or ipa-local type: >>>> * Primary RID ranges can not overlap >>>> * For ranges of ipa-local type: >>>> * Primary and secondary RID ranges can not overlap >>>> * Secondary RID ranges cannot overlap >>>> >>>> For the implementation part, the plugin was extended with a domain ID >>>> to forest root domain ID mapping derivation capabilities. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4137 >>>> >>>> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >>>> +struct domain_info { >>>> + char *domain_id; >>>> + char *forest_root_id; >>>> + struct domain_info *next; >>>> +}; >>>> + >>>> +static void free_domain_info(struct domain_info *info) { >>>> + if (info != NULL) { >>>> + slapi_ch_free_string(&(info->domain_id)); >>>> + slapi_ch_free_string(&(info->forest_root_id)); >>>> + free_domain_info(info->next); >>>> + free(info); >>>> + } >>>> +} >>> Please, don't use recursion in the freeing part, there is really no >>> pressing need to do so. Just use while() like you do in >>> get_forest_root_id(): >>> >>>> +/* Searches for the domain_info struct with the specified domain_id >>>> + * in the linked list. Returns the forest root domain's ID, or NULL for >>>> + * local ranges. */ >>>> + >>>> +static char* get_forest_root_id(struct domain_info *head, char* >>>> domain_id) { >>>> + >>>> + /* For local ranges there is no forest root domain, >>>> + * so consider only ranges with domain_id set */ >>>> + if (domain_id != NULL) { >>>> + while(head) { >>>> + if (strcasecmp(head->domain_id, domain_id) == 0) { >>>> + return head->forest_root_id; >>>> + } >>>> + head = head->next; >>>> + } >>>> + } >>>> + >>>> + return NULL; >>>> +} >>>> + >>> >> Fixed, updated patch attached. >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >From f98082d6cfd902417af94d7cd22d3cc85980a782 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Wed, 5 Mar 2014 12:28:18 +0100 >> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >> >> The ipa-range-check plugin used to determine the range type depending >> on the value of the attributes such as RID or secondary RID base. This >> approached caused variety of issues since the portfolio of ID range >> types expanded. >> >> The patch makes sure the following rules are implemented: >> * No ID range pair can overlap on base ranges, with exception >> of two ipa-ad-trust-posix ranges belonging to the same forest >> * For any ID range pair of ranges belonging to the same domain: >> * Both ID ranges must be of the same type >> * For ranges of ipa-ad-trust type or ipa-local type: >> * Primary RID ranges can not overlap >> * For ranges of ipa-local type: >> * Primary and secondary RID ranges can not overlap >> * Secondary RID ranges cannot overlap >> >> For the implementation part, the plugin was extended with a domain ID >> to forest root domain ID mapping derivation capabilities. >> >> https://fedorahosted.org/freeipa/ticket/4137 >> --- > //snip > >> - no_overlap = ranges_overlap(new_range, old_range); >> + ranges_valid = check_ranges(new_range, old_range); >> free_range_info(old_range); >> old_range = NULL; >> - if (no_overlap != 0) { >> + if (ranges_valid != 0) { >> ret = LDAP_CONSTRAINT_VIOLATION; >> >> - switch (no_overlap){ >> + switch (ranges_valid){ >> case 1: >> errmsg = "New base range overlaps with existing base range."; >> break; >> @@ -417,6 +627,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) >> case 5: >> errmsg = "New secondary rid range overlaps with existing primary rid range."; >> break; >> + case 6: >> + errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; >> default: > There is a missing break. Ithink it is a problem, because you do not > want to fall through to the defaul and override errmsg. > > Smple patch is attached. > > LS ACK, thanks Lukas! -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From jcholast at redhat.com Mon Jul 14 09:47:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Jul 2014 11:47:41 +0200 Subject: [Freeipa-devel] [PATCH 0239] trusts: Validate missing trust secret properly In-Reply-To: <53C3A5BD.5080409@redhat.com> References: <53BE5549.9060900@redhat.com> <53C37178.3020005@redhat.com> <53C3A5BD.5080409@redhat.com> Message-ID: <53C3A73D.2030702@redhat.com> On 14.7.2014 11:41, Tomas Babej wrote: > On 07/14/2014 07:58 AM, Jan Cholasta wrote: >> On 10.7.2014 10:56, Tomas Babej wrote: >>> Hi, >>> >>> Detect the situation if the user passes empty trust secret and >>> error out properly. >>> >>> https://fedorahosted.org/freeipa/ticket/4266 >> >> IMO this is less ugly: >> >> + raise errors.ValidationError( >> + name=_('AD Trust setup'), >> + error=_('Not enough arguments specified to perform >> trust ' >> + 'setup')) >> > > Sure, fixed. > Thanks, ACK! -- Jan Cholasta From alee at redhat.com Mon Jul 14 09:45:52 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 14 Jul 2014 05:45:52 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1100861497.7686981.1405330421267.JavaMail.zimbra@redhat.com> Message-ID: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> Hi all, I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review. The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data. In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ Please review, Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 143139 bytes Desc: not available URL: From tbabej at redhat.com Mon Jul 14 09:50:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Jul 2014 11:50:01 +0200 Subject: [Freeipa-devel] [PATCH 0241] trusts: Make cn=adtrust agents sysaccount nestedgroup Message-ID: <53C3A7C9.6080205@redhat.com> Hi, Since recent permissions work references this entry, we need to be able to have memberOf attributes created on this entry. Hence we need to include the nestedgroup objectclass. https://fedorahosted.org/freeipa/ticket/4433 -- 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-0241-trusts-Make-cn-adtrust-agents-sysaccount-nestedgroup.patch Type: text/x-patch Size: 1023 bytes Desc: not available URL: From pviktori at redhat.com Mon Jul 14 14:11:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jul 2014 16:11:39 +0200 Subject: [Freeipa-devel] [PATCH] Fix warning: Using uninitialized value ld. In-Reply-To: <53C3909E.3040207@redhat.com> References: <20140712184054.GC18398@mail.corp.redhat.com> <53C3909E.3040207@redhat.com> Message-ID: <53C3E51B.5080203@redhat.com> On 07/14/2014 10:11 AM, Jan Cholasta wrote: > On 12.7.2014 20:40, Lukas Slebodnik wrote: >> ehlo, >> >> If create_getkeytab_control fails variable uninitialized pointer 'ld' >> will be used in done section. >> >> Simple patch is attached. > > Obvious ACK Pushed to master, ipa-4-1, ipa-4-0: 277a01589b8d4b62f85cf41b2bf70fbe308909c9 > (if that's even necessary, since the patch is one-liner). Luk?? can't commit directly to fedorahosted, so the patch does need an ACK. -- Petr? From pviktori at redhat.com Mon Jul 14 14:12:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jul 2014 16:12:18 +0200 Subject: [Freeipa-devel] [PATCH] 0620 ldap2 indirect membership processing: Use global limits if greater than per-query ones In-Reply-To: <53C379EA.7000507@redhat.com> References: <53BBEE57.70002@redhat.com> <53C379EA.7000507@redhat.com> Message-ID: <53C3E542.4090201@redhat.com> On 07/14/2014 08:34 AM, Jan Cholasta wrote: > On 8.7.2014 15:12, Petr Viktorin wrote: >> Fix for https://fedorahosted.org/freeipa/ticket/4398 > > ACK. > Thanks! Pushed to master, ipa-4-1, ipa-4-0: 73b2d0a81dc09acbcae0e4388d1043780a171f3b -- Petr? From pviktori at redhat.com Mon Jul 14 14:13:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jul 2014 16:13:12 +0200 Subject: [Freeipa-devel] [PATCH 0239] trusts: Validate missing trust secret properly In-Reply-To: <53C3A73D.2030702@redhat.com> References: <53BE5549.9060900@redhat.com> <53C37178.3020005@redhat.com> <53C3A5BD.5080409@redhat.com> <53C3A73D.2030702@redhat.com> Message-ID: <53C3E578.8040101@redhat.com> On 07/14/2014 11:47 AM, Jan Cholasta wrote: > On 14.7.2014 11:41, Tomas Babej wrote: >> On 07/14/2014 07:58 AM, Jan Cholasta wrote: >>> On 10.7.2014 10:56, Tomas Babej wrote: >>>> Hi, >>>> >>>> Detect the situation if the user passes empty trust secret and >>>> error out properly. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4266 >>> >>> IMO this is less ugly: >>> >>> + raise errors.ValidationError( >>> + name=_('AD Trust setup'), >>> + error=_('Not enough arguments specified to perform >>> trust ' >>> + 'setup')) >>> >> >> Sure, fixed. >> > > Thanks, ACK! > Pushed to master, ipa-4-1, ipa-4-0: e672a396374c05c5a06eb4e816ec6cc0939ad008 -- Petr? From pviktori at redhat.com Mon Jul 14 14:29:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jul 2014 16:29:41 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <53C3A629.1040906@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> <533A7E49.604@redhat.com> <20140712182258.GA18398@mail.corp.redhat.com> <53C3A629.1040906@redhat.com> Message-ID: <53C3E955.6080500@redhat.com> On 07/14/2014 11:43 AM, Tomas Babej wrote: > > On 07/12/2014 08:22 PM, Lukas Slebodnik wrote: >> On (01/04/14 10:52), Tomas Babej wrote: >>> On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: >>>> On Tue, 01 Apr 2014, Tomas Babej wrote: >>>>> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >>>>> From: Tomas Babej >>>>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>>>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>>>> >>>>> The ipa-range-check plugin used to determine the range type depending >>>>> on the value of the attributes such as RID or secondary RID base. This >>>>> approached caused variety of issues since the portfolio of ID range >>>>> types expanded. >>>>> >>>>> The patch makes sure the following rules are implemented: >>>>> * No ID range pair can overlap on base ranges, with exception >>>>> of two ipa-ad-trust-posix ranges belonging to the same forest >>>>> * For any ID range pair of ranges belonging to the same domain: >>>>> * Both ID ranges must be of the same type >>>>> * For ranges of ipa-ad-trust type or ipa-local type: >>>>> * Primary RID ranges can not overlap >>>>> * For ranges of ipa-local type: >>>>> * Primary and secondary RID ranges can not overlap >>>>> * Secondary RID ranges cannot overlap >>>>> >>>>> For the implementation part, the plugin was extended with a domain ID >>>>> to forest root domain ID mapping derivation capabilities. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4137 >>>>> >>>>> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >>>>> +struct domain_info { >>>>> + char *domain_id; >>>>> + char *forest_root_id; >>>>> + struct domain_info *next; >>>>> +}; >>>>> + >>>>> +static void free_domain_info(struct domain_info *info) { >>>>> + if (info != NULL) { >>>>> + slapi_ch_free_string(&(info->domain_id)); >>>>> + slapi_ch_free_string(&(info->forest_root_id)); >>>>> + free_domain_info(info->next); >>>>> + free(info); >>>>> + } >>>>> +} >>>> Please, don't use recursion in the freeing part, there is really no >>>> pressing need to do so. Just use while() like you do in >>>> get_forest_root_id(): >>>> >>>>> +/* Searches for the domain_info struct with the specified domain_id >>>>> + * in the linked list. Returns the forest root domain's ID, or NULL for >>>>> + * local ranges. */ >>>>> + >>>>> +static char* get_forest_root_id(struct domain_info *head, char* >>>>> domain_id) { >>>>> + >>>>> + /* For local ranges there is no forest root domain, >>>>> + * so consider only ranges with domain_id set */ >>>>> + if (domain_id != NULL) { >>>>> + while(head) { >>>>> + if (strcasecmp(head->domain_id, domain_id) == 0) { >>>>> + return head->forest_root_id; >>>>> + } >>>>> + head = head->next; >>>>> + } >>>>> + } >>>>> + >>>>> + return NULL; >>>>> +} >>>>> + >>>> >>> Fixed, updated patch attached. >>> >>> -- >>> Tomas Babej >>> Associate Software Engineer | Red Hat | Identity Management >>> RHCE | Brno Site | IRC: tbabej | freeipa.org >>> >>> >From f98082d6cfd902417af94d7cd22d3cc85980a782 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>> >>> The ipa-range-check plugin used to determine the range type depending >>> on the value of the attributes such as RID or secondary RID base. This >>> approached caused variety of issues since the portfolio of ID range >>> types expanded. >>> >>> The patch makes sure the following rules are implemented: >>> * No ID range pair can overlap on base ranges, with exception >>> of two ipa-ad-trust-posix ranges belonging to the same forest >>> * For any ID range pair of ranges belonging to the same domain: >>> * Both ID ranges must be of the same type >>> * For ranges of ipa-ad-trust type or ipa-local type: >>> * Primary RID ranges can not overlap >>> * For ranges of ipa-local type: >>> * Primary and secondary RID ranges can not overlap >>> * Secondary RID ranges cannot overlap >>> >>> For the implementation part, the plugin was extended with a domain ID >>> to forest root domain ID mapping derivation capabilities. >>> >>> https://fedorahosted.org/freeipa/ticket/4137 >>> --- >> //snip >> >>> - no_overlap = ranges_overlap(new_range, old_range); >>> + ranges_valid = check_ranges(new_range, old_range); >>> free_range_info(old_range); >>> old_range = NULL; >>> - if (no_overlap != 0) { >>> + if (ranges_valid != 0) { >>> ret = LDAP_CONSTRAINT_VIOLATION; >>> >>> - switch (no_overlap){ >>> + switch (ranges_valid){ >>> case 1: >>> errmsg = "New base range overlaps with existing base range."; >>> break; >>> @@ -417,6 +627,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) >>> case 5: >>> errmsg = "New secondary rid range overlaps with existing primary rid range."; >>> break; >>> + case 6: >>> + errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; >>> default: >> There is a missing break. Ithink it is a problem, because you do not >> want to fall through to the defaul and override errmsg. >> >> Smple patch is attached. >> >> LS > > ACK, thanks Lukas! > Pushed to master, ipa-4-1, ipa-4-0: d1d253637535017fdf82aa833df742bb418bbf65 -- Petr? From jcholast at redhat.com Mon Jul 14 15:00:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Jul 2014 17:00:07 +0200 Subject: [Freeipa-devel] [PATCH 0241] trusts: Make cn=adtrust agents sysaccount nestedgroup In-Reply-To: <53C3A7C9.6080205@redhat.com> References: <53C3A7C9.6080205@redhat.com> Message-ID: <53C3F077.8000704@redhat.com> Hi, On 14.7.2014 11:50, Tomas Babej wrote: > Hi, > > Since recent permissions work references this entry, we need to be > able to have memberOf attributes created on this entry. Hence we > need to include the nestedgroup objectclass. > > https://fedorahosted.org/freeipa/ticket/4433 NACK, "default" will not work for IPA upgrades, you have to use "add". -- Jan Cholasta From pviktori at redhat.com Mon Jul 14 15:22:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Jul 2014 17:22:54 +0200 Subject: [Freeipa-devel] Running ipa-replica-prepare on a replica In-Reply-To: References: Message-ID: <53C3F5CE.2010308@redhat.com> Hello, On 07/11/2014 08:17 AM, James wrote: > I installed IPA on host A, did a replica prepare, and then installed > it on host B. > > Running ipa-replica-prepare on B yield this error: > >> A selfsign CA backend can only prepare on the original master > > This error doesn't seem to be in the current git master anymore. Has > this limitation been removed? Not really: the selfsign functionality itself was removed. See: http://www.freeipa.org/page/V3/Drop_selfsign_functionality > Can someone explain if you can "ipa-replica-prepare" from any new > master, and starting at what version please? Assume I installed the > first host with --selfsign. Unfortunately, you can't. Self-signed CAs were not capable of replication, and replica files need to be created on a host with CA (unless using the CA-less feature in IPA 3.2+). So, in a selfsign install, only the original master could create replicas. > I'm particularly interested in understanding why or why not you can do > this (or couldn't do this). Selfsign was was never suitable for production. It was useful for developers while Dogtag wasn't ready yet, but it never got beyond being a proof of concept. Unfortunately it had a very tempting name, and we didn't communicate enough that it's something you don't want to use. Apologies for that. -- Petr? From jdennis at redhat.com Mon Jul 14 17:05:24 2014 From: jdennis at redhat.com (John Dennis) Date: Mon, 14 Jul 2014 13:05:24 -0400 Subject: [Freeipa-devel] RPM's of different ipa versions In-Reply-To: <53C3927A.5070101@redhat.com> References: <53C3927A.5070101@redhat.com> Message-ID: <53C40DD4.8000608@redhat.com> On 07/14/2014 04:19 AM, Petr Spacek wrote: > On 11.7.2014 08:40, James wrote: >> This page seems to suggest that there are continuous builds available: >> >> http://www.freeipa.org/page/Downloads#Bleeding_Edge >> >> It seems this hasn't been updated since 2013, except the .repo files >> have recently? Does this still exist? Are there archives for each >> point release somewhere? >> >> In particular, I'm interested in knowing if there are repos with rpm's >> for each version/os. (>=v.3.0.0 and Fedora/CentOS6+/RHEL6+) > John, could you comment on this? > The "bleeding edge" repo mentioned on that page is what we call the "devel repo". Is the devel repo still being updated? Yes. However being an automated process sometimes snafu's occur that we may not catch right away. For instance I see the last update was on 7/2. It looks like builds are failing for some reason. I don't do the builds, Nalin does, I'll ping Nalin and see what the problem is. Are there archives? No! These builds are *not* official, they are intended for developers *only*, they are *ephemeral*. On any given day the builds might me updated multiple times. The repo only has the *latest* devel builds. Once an automated build completes we purge any previous builds from the repo. Is there a build for every version/os? Probably not. Once again, these builds are for developers only, we only build what serves our developers at the moment. The list of what we build changes. Typically we build a current Fedora releases and current RHEL releases. The packages versions *only* the newest based on the source tree (see above). -- John From npmccallum at redhat.com Mon Jul 14 19:01:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 14 Jul 2014 15:01:28 -0400 Subject: [Freeipa-devel] [PATCH 0058] Fix login password expiration detection with OTP Message-ID: <1405364488.3058.4.camel@ipa.example.com> The preexisting code would execute two steps. First, it would perform a kinit. If the kinit failed, it would attempt to bind using the same credentials to determine if the password were expired. While this method is fairly ugly, it mostly worked in the past. However, with OTP this breaks. This is because the OTP code is consumed by the kinit step. But because the password is expired, the kinit step fails. When the bind is executed, the OTP token is already consumed, so bind fails. This causes all password expirations to be reported as invalid credentials. After discussion with MIT, the best way to handle this case with the standard tools is to set LC_ALL=C and check the output from the command. This eliminates the bind step altogether. The end result is that OTP works and all password failures are more performant. https://fedorahosted.org/freeipa/ticket/4412 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058-Fix-login-password-expiration-detection-with-OTP.patch Type: text/x-patch Size: 5664 bytes Desc: not available URL: From knighcl at gmail.com Tue Jul 15 05:29:57 2014 From: knighcl at gmail.com (Curtis L. Knight) Date: Tue, 15 Jul 2014 05:29:57 +0000 (UTC) Subject: [Freeipa-devel] RPM's of different ipa versions References: <53C3927A.5070101@redhat.com> <53C40DD4.8000608@redhat.com> Message-ID: John Dennis writes: > > On 07/14/2014 04:19 AM, Petr Spacek wrote: > > On 11.7.2014 08:40, James wrote: > >> This page seems to suggest that there are continuous builds available: > >> > >> http://www.freeipa.org/page/Downloads#Bleeding_Edge > >> > >> It seems this hasn't been updated since 2013, except the .repo files > >> have recently? Does this still exist? Are there archives for each > >> point release somewhere? > >> > >> In particular, I'm interested in knowing if there are repos with rpm's > >> for each version/os. (>=v.3.0.0 and Fedora/CentOS6+/RHEL6+) > > John, could you comment on this? > > > > The "bleeding edge" repo mentioned on that page is what we call the > "devel repo". > > Is the devel repo still being updated? > > Yes. However being an automated process sometimes snafu's occur that we > may not catch right away. For instance I see the last update was on 7/2. > It looks like builds are failing for some reason. I don't do the builds, > Nalin does, I'll ping Nalin and see what the problem is. > > Are there archives? > > No! These builds are *not* official, they are intended for developers > *only*, they are *ephemeral*. On any given day the builds might me > updated multiple times. The repo only has the *latest* devel builds. > Once an automated build completes we purge any previous builds from the > repo. > > Is there a build for every version/os? > > Probably not. Once again, these builds are for developers only, we only > build what serves our developers at the moment. The list of what we > build changes. Typically we build a current Fedora releases and current > RHEL releases. The packages versions *only* the newest based on the > source tree (see above). > I have been using docker to build rpms for different platforms. It failed on not having a yubico module for the master branch. This worked on master before but 3.3.5 does not build either. I have enclosed my dockerfile such that you can change it and pick up whatever base system and modify which git branch you would like. You should be able to get at the generated rpms through the freeipa volume at least that was my thought the last time I messed with this during version .10 of docker. Anyway, let me know if this gets you somewhere. Enjoy, Curtis # build command: docker build --no-cache=false --rm=true --tag="freeipa- rpms-fedora:20" . FROM fedora:20 MAINTAINER Curtis L. Knight, knighcl at gmail.com # update base image RUN yum -y update; yum clean all # install git and rpm build tools RUN yum -y install git yum-utils make rpmdevtools rpmlint cpp RUN git clone git://git.fedorahosted.org/git/freeipa.git --branch release-3- 3-5 VOLUME ["/freeipa"] WORKDIR freeipa RUN cp freeipa.spec.in freeipa-builddep.spec; yum-builddep -y freeipa- builddep.spec; make rpms; From tbabej at redhat.com Tue Jul 15 07:13:35 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 15 Jul 2014 09:13:35 +0200 Subject: [Freeipa-devel] [PATCH 0242] Set the default attributes for RootDSE Message-ID: <53C4D49F.5010908@redhat.com> Hi, With 389 DS 1.3.3 upwards we can leverage the nsslapd-return-default-opattr attribute to enumerate the list of attributes that should be returned even if not specified explicitly. Use the behaviour to get the same attributes returned from searches on rootDSE as in 1.3.1. https://fedorahosted.org/freeipa/ticket/4288 -- 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-0242-Set-the-default-attributes-for-RootDSE.patch Type: text/x-patch Size: 1861 bytes Desc: not available URL: From pspacek at redhat.com Tue Jul 15 07:36:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 15 Jul 2014 09:36:32 +0200 Subject: [Freeipa-devel] [PATCH 0240] ipatests: tasks: Fix dns configuration for trusts In-Reply-To: <53C3A357.5050707@redhat.com> References: <53C3A357.5050707@redhat.com> Message-ID: <53C4DA00.6000703@redhat.com> On 14.7.2014 11:31, Tomas Babej wrote: > Hi, > > Properly configure forwarders to the AD zone with respect to > newly created ipa dnsforwardzone commands. > > https://fedorahosted.org/freeipa/ticket/4401 Looks reasonable and tests are passing - ACK. -- Petr^2 Spacek From pviktori at redhat.com Tue Jul 15 07:53:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Jul 2014 09:53:59 +0200 Subject: [Freeipa-devel] [PATCH 0240] ipatests: tasks: Fix dns configuration for trusts In-Reply-To: <53C4DA00.6000703@redhat.com> References: <53C3A357.5050707@redhat.com> <53C4DA00.6000703@redhat.com> Message-ID: <53C4DE17.6070604@redhat.com> On 07/15/2014 09:36 AM, Petr Spacek wrote: > On 14.7.2014 11:31, Tomas Babej wrote: >> Hi, >> >> Properly configure forwarders to the AD zone with respect to >> newly created ipa dnsforwardzone commands. >> >> https://fedorahosted.org/freeipa/ticket/4401 > > Looks reasonable and tests are passing - ACK. > Pushed to master, ipa-4-1, ipa-4-0: 4254423f8315ac88b0400b261e3b0e4acf015db6 -- Petr? From tbabej at redhat.com Tue Jul 15 07:57:23 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 15 Jul 2014 09:57:23 +0200 Subject: [Freeipa-devel] [PATCH 0241] trusts: Make cn=adtrust agents sysaccount nestedgroup In-Reply-To: <53C3F077.8000704@redhat.com> References: <53C3A7C9.6080205@redhat.com> <53C3F077.8000704@redhat.com> Message-ID: <53C4DEE3.4060004@redhat.com> On 07/14/2014 05:00 PM, Jan Cholasta wrote: > Hi, > > On 14.7.2014 11:50, Tomas Babej wrote: >> Hi, >> >> Since recent permissions work references this entry, we need to be >> able to have memberOf attributes created on this entry. Hence we >> need to include the nestedgroup objectclass. >> >> https://fedorahosted.org/freeipa/ticket/4433 > > NACK, "default" will not work for IPA upgrades, you have to use "add". > Oops, thanks for the catch, fixed. -- 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-0241-2-trusts-Make-cn-adtrust-agents-sysaccount-nestedgroup.patch Type: text/x-patch Size: 1048 bytes Desc: not available URL: From pviktori at redhat.com Tue Jul 15 08:06:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Jul 2014 10:06:07 +0200 Subject: [Freeipa-devel] RPM's of different ipa versions In-Reply-To: References: <53C3927A.5070101@redhat.com> <53C40DD4.8000608@redhat.com> Message-ID: <53C4E0EF.3020005@redhat.com> On 07/15/2014 07:29 AM, Curtis L. Knight wrote: > John Dennis writes: > >> >> On 07/14/2014 04:19 AM, Petr Spacek wrote: >>> On 11.7.2014 08:40, James wrote: >>>> This page seems to suggest that there are continuous builds available: >>>> >>>> http://www.freeipa.org/page/Downloads#Bleeding_Edge >>>> >>>> It seems this hasn't been updated since 2013, except the .repo files >>>> have recently? Does this still exist? Are there archives for each >>>> point release somewhere? >>>> >>>> In particular, I'm interested in knowing if there are repos with rpm's >>>> for each version/os. (>=v.3.0.0 and Fedora/CentOS6+/RHEL6+) >>> John, could you comment on this? >>> >> >> The "bleeding edge" repo mentioned on that page is what we call the >> "devel repo". >> >> Is the devel repo still being updated? >> >> Yes. However being an automated process sometimes snafu's occur that we >> may not catch right away. For instance I see the last update was on 7/2. >> It looks like builds are failing for some reason. I don't do the builds, >> Nalin does, I'll ping Nalin and see what the problem is. >> >> Are there archives? >> >> No! These builds are *not* official, they are intended for developers >> *only*, they are *ephemeral*. On any given day the builds might me >> updated multiple times. The repo only has the *latest* devel builds. >> Once an automated build completes we purge any previous builds from the >> repo. >> >> Is there a build for every version/os? >> >> Probably not. Once again, these builds are for developers only, we only >> build what serves our developers at the moment. The list of what we >> build changes. Typically we build a current Fedora releases and current >> RHEL releases. The packages versions *only* the newest based on the >> source tree (see above). >> > > I have been using docker to build rpms for different platforms. It failed on > not having a yubico module for the master branch. This worked on master > before but 3.3.5 does not build either. I have enclosed my dockerfile such > that you can change it and pick up whatever base system and modify which git > branch you would like. You should be able to get at the generated rpms > through the freeipa volume at least that was my thought the last time I > messed with this during version .10 of docker. Anyway, let me know if this > gets you somewhere. Hi, For building master you generally want to enable Fedora's updates-testing repository. Sometimes there are other repos/packages needed as well but we try to keep them to a minimum. When someone brings in a dependency outside updates/updates-testing should announce it on the list; if that doesn't happen, feel free to shout at them. -- Petr? From jcholast at redhat.com Tue Jul 15 13:50:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 15 Jul 2014 15:50:45 +0200 Subject: [Freeipa-devel] [PATCH 0241] trusts: Make cn=adtrust agents sysaccount nestedgroup In-Reply-To: <53C4DEE3.4060004@redhat.com> References: <53C3A7C9.6080205@redhat.com> <53C3F077.8000704@redhat.com> <53C4DEE3.4060004@redhat.com> Message-ID: <53C531B5.4050109@redhat.com> On 15.7.2014 09:57, Tomas Babej wrote: > > On 07/14/2014 05:00 PM, Jan Cholasta wrote: >> Hi, >> >> On 14.7.2014 11:50, Tomas Babej wrote: >>> Hi, >>> >>> Since recent permissions work references this entry, we need to be >>> able to have memberOf attributes created on this entry. Hence we >>> need to include the nestedgroup objectclass. >>> >>> https://fedorahosted.org/freeipa/ticket/4433 >> >> NACK, "default" will not work for IPA upgrades, you have to use "add". >> > > Oops, thanks for the catch, fixed. > ACK. -- Jan Cholasta From simo at redhat.com Tue Jul 15 14:27:43 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 15 Jul 2014 10:27:43 -0400 (EDT) Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53C53711.8020307@redhat.com> References: <53C53711.8020307@redhat.com> Message-ID: <209313109.10362612.1405434463761.JavaMail.zimbra@redhat.com> I am curious about this: "Currently there is no NSS backend for Python Cryptography." Yet we use python-nss in some projects already, so what is missing there ? Simo. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "freeipa-devel" , "dpal >> Dmitri Pal" , "Nathan Kinder" > , "Ade Lee" , "Rob Crittenden" , "Simo Sorce" > , "Martin Kosek" , "Fraser Tweedale" > Sent: Tuesday, July 15, 2014 10:13:37 AM > Subject: Password Vault Implementation > > Hi, > > I've been working on the implementation details of password vault: > http://www.freeipa.org/page/V4/Password_Vault_Implementation > > There are some issues (i.e. vault password and vault key) that aren't > specifically defined in the design, so we need to make some decisions. > > Please let me know if you have any comments or questions. Thanks! > > -- > Endi S. Dewata > From edewata at redhat.com Tue Jul 15 14:40:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jul 2014 09:40:02 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <209313109.10362612.1405434463761.JavaMail.zimbra@redhat.com> References: <53C53711.8020307@redhat.com> <209313109.10362612.1405434463761.JavaMail.zimbra@redhat.com> Message-ID: <53C53D42.2090009@redhat.com> On 7/15/2014 9:27 AM, Simo Sorce wrote: > I am curious about this: "Currently there is no NSS backend for Python Cryptography." > Yet we use python-nss in some projects already, so what is missing there ? > > Simo. Does the IPA client currently require python-nss? There's a concern of using python-nss directly on the client as it would create/reinforce the NSS dependency. This wouldn't really matter if IPA client is already depending on python-nss for other things, but I think it would be better if we can use the more abstract interface provided by the Cryptography library. -- Endi S. Dewata From rcritten at redhat.com Tue Jul 15 15:17:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Jul 2014 11:17:40 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53C53D42.2090009@redhat.com> References: <53C53711.8020307@redhat.com> <209313109.10362612.1405434463761.JavaMail.zimbra@redhat.com> <53C53D42.2090009@redhat.com> Message-ID: <53C54614.2020607@redhat.com> Endi Sukma Dewata wrote: > On 7/15/2014 9:27 AM, Simo Sorce wrote: >> I am curious about this: "Currently there is no NSS backend for Python >> Cryptography." >> Yet we use python-nss in some projects already, so what is missing >> there ? >> >> Simo. > > Does the IPA client currently require python-nss? There's a concern of > using python-nss directly on the client as it would create/reinforce the > NSS dependency. The python subpackage has the requirement and the client subpackage requires python, so yes. > This wouldn't really matter if IPA client is already depending on > python-nss for other things, but I think it would be better if we can > use the more abstract interface provided by the Cryptography library. > I don't believe we do any direct crypto beyond generating CSRs and doing SSL/TLS, so it may be overkill for our current purposes, but I believe this library was created after IPA. rob From admin at transifex.com Fri Jul 4 16:10:30 2014 From: admin at transifex.com (Transifex) Date: Fri, 04 Jul 2014 16:10:30 -0000 Subject: [Freeipa-devel] [Transifex] An issue has been created on ipa: FreeIPA by yurchor Message-ID: <20140704161030.855.57227@be01.transifex.com> Hi freeipa, An issue has been created on one of your strings by yurchor. Typos: sematics -> semantics; bellow -> below String: Semantics of forwarding in IPA matches BIND sematics and depends on type of the zone: * Master zone: local BIND replies authoritatively to queries for data in the given zone (including authoritative NXDOMAIN answers) and forwarding affects only queries for names bellow zone cuts (NS records) of locally served zones. * Forward zone: forward zone contains no authoritative data. BIND forwards queries, which cannot be answered from its local cache, to configured forwarders. Language: Ukrainian[1] Resource: ipa[2] Project: FreeIPA[3] View it on Transifex at https://www.transifex.com/projects/p/freeipa/translate/#uk/ipa/c/27511316 [1]: https://www.transifex.com/projects/p/freeipa/language/uk/ [2]: https://www.transifex.com/projects/p/freeipa/resource/ipa/ [3]: https://www.transifex.com/projects/p/freeipa/ -- The Transifex Robot https://www.transifex.com/settings/notices/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Jul 16 03:48:47 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 15 Jul 2014 21:48:47 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive Message-ID: Hello, Adds AD admin and password to interactive commands. https://fedorahosted.org/freeipa/ticket/3034 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0024-ipa-trust-add-command-should-be-interactive.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: From redhatrises at gmail.com Wed Jul 16 03:48:52 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 15 Jul 2014 21:48:52 -0600 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf Message-ID: Hello, Adds debug pid = yes to smb.conf when ipa-adtrust-install command is run. https://fedorahosted.org/freeipa/ticket/3485 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0023-Enable-debug-pid-in-smb.conf.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From redhatrises at gmail.com Wed Jul 16 03:49:02 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 15 Jul 2014 21:49:02 -0600 Subject: [Freeipa-devel] [PATCH] Fix typos in dns.py Message-ID: Hello, Fixes https://fedorahosted.org/freeipa/ticket/4429 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0025-Fix-typos-in-dns.py.patch Type: text/x-patch Size: 1309 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 16 12:05:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 16 Jul 2014 14:05:37 +0200 Subject: [Freeipa-devel] [PATCH 0243] ipalib: idrange: Make non-implemented range types fail the Message-ID: <53C66A91.5030203@redhat.com> Hi, The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to pass the validation tests, however, they are not implemented nor checked by the 389 server plugin. https://fedorahosted.org/freeipa/ticket/4323 -- 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-0243-ipalib-idrange-Make-non-implemented-range-types-fail.patch Type: text/x-patch Size: 1565 bytes Desc: not available URL: From pviktori at redhat.com Wed Jul 16 12:55:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Jul 2014 14:55:11 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> Message-ID: <53C6762F.50107@redhat.com> On 07/14/2014 11:45 AM, Ade Lee wrote: > Hi all, > > I have rebased all the previous patches against master, and have squashed them all into a single patch. > Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it > should be familiar and easier to review. I think it would be nice to have the fixes that aren't related to DRM (e.g. style issues) separate, so the patch can be reverted easily. But, what's done is done. Thanks for the cleanup! > The main difference with what was specified before is that the DRM database is installed as a subtree > to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. > Replication agreements set up for the Dogtag CA will automatically replicate DRM data. > > In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to > allow the ability to install a database as a subtree of an existing tree. At this time, these > changes have not yet been checked into the dogtag source. You can obtain such a build from: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ > > Please review, I've started reading the code; here are my thoughts on the first part: In ipa-ca-install and ipa-replica-install, you only ever set "REPLICA_INFO_TOP_DIR" to None. In Python, "global" has module scope, it's not for the entire process. (And it's bad practice anyway.) You'll need to pass it around explicitly, perhaps store it in ReplicaConfig. It would be nice to use the admintool framework for the new script, instead of copying the old boilerplate code again. See e.g. ipa-server-certinstall for an example. Logging functions interpolate their arguments, so you should use e.g. root_logger.critical("failed to configure %s instance %s", subsystem, e) instead of using the % operator. installutils.create_replica_config: Any time you call sys.exit(), please log a message so we know why the log file ends. In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The information is available in api.env once api is finalized. In ipa-server-install, do we want to display the message about backing up /root/drmcert.p12 even if DRM is not installed? Please use path constants from ipaplatform.base.paths, or add new ones if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}. In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change that back to paths.NAMED_KEYTAB. Same in CAInstance.uninstall with "/usr/bin/pkiremove". In ipa-upgradeconfig.find_subject_base, the docstring should mention to DsInstance.find_subject_base's docstring rather than being a copy; we dont' want them getting out of sync. In DsInstance.find_subject_base, don't use a bare `except:`, at least do `except Exception:`, so you don't e.g. disable Ctrl+C. In CADSInstance.uninstall, you don't need the _running and _user_exists variables at all, just call the functions. Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode. Same in CAInstance.uninstall for _user_exists. In DogtagInstance, stop_tracking_certificates was moved here from cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR. Is that intended? In CAInstance.__init__, when calling DogtagInstance.__init__, consider using super, and naming the arguments for clarity: super(CAInstance, self).__init__( realm=realm, subsystem="CA", service_desc="certificate server", dogtag_constants=dogtag_constants, ) Since CAInstance inherits from DogtagInstance, the `enable`, `start_instance`, `stop_instance`, `http_proxy` methods that just call the superclass are unnecessary. IMO the comment from CAInstance.__enable was important, it should be in DogtagInstance.enable. In DogtagInstance.spawn_instance, it's not nice to modify lists the caller pased in. Take a copy of the nolog first. Ideally combine that with the conversion to tuple, and allow any sequence to be passed in: nolog_list = tuple(nolog_list) + (self.admin_password, self.dm_password) In CAInstance.__create_ca_user, it's better to use functions instead of staticmethods, unless you'll want to override them in subclasses (which you're explicitly discouraging here, by using the double underscore). Anyway I don't get why you want these to be staticmethods. (Note to self: I'm at line 1866 of the patch) -- Petr? From edewata at redhat.com Wed Jul 16 15:12:01 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 16 Jul 2014 10:12:01 -0500 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> Message-ID: <53C69641.2010004@redhat.com> On 7/14/2014 4:45 AM, Ade Lee wrote: > Hi all, > > I have rebased all the previous patches against master, and have squashed them all into a single patch. > Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it > should be familiar and easier to review. > > The main difference with what was specified before is that the DRM database is installed as a subtree > to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. > Replication agreements set up for the Dogtag CA will automatically replicate DRM data. > > In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to > allow the ability to install a database as a subtree of an existing tree. At this time, these > changes have not yet been checked into the dogtag source. You can obtain such a build from: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ > > Please review, > > Thanks, > Ade Some comments/questions: 1. The suffix for the DRM is o=ipadrm,o=ipaca. It's probably better to change it to ou=drm,o=ipaca since another "ipa" under o=ipaca would be redundant. In the future we might want to migrate the current CA entries into ou=ca,o=ipaca subtree so that ou=ca and ou=drm will be at the same level, and keep o=ipaca as the parent tree for Dogtag subsystems. Alternatively, we probably could merge o=ipaca and o=ipadrm since the structure of each tree seems to have been designed to share the user and groups, but still maintain separate structure for CA/KRA-specific storage. The current Dogtag probably doesn't support this, but it's a possibility with additional works. 2. If a clone doesn't have DRM installed but it's getting replicated DRM data, is there any concern? 3. The Dogtag dependency should be updated to 10.2. Also the dogtag_version and DOGTAG_VERSION variables are probably not granular enough to detect the minor version. This message should be updated too: Dogtag must be version 10.1 or above to install DRM 4. It's probably unnecessary to override the following methods in CAInstance since they only call the base methods. * enable() * start_instance() * stop_instance() * restart_instance() * http_proxy() 5. The following code in ipaserver/plugins/dogtag.py will no longer work due to a recent change in Dogtag: transport_cert = kraclient.system_certs.get_transport_cert() tcert = transport_cert[ len(pki.CERT_HEADER): len(transport_cert) - len(pki.CERT_FOOTER)] crypto.import_cert( self.transport_nick, base64.decodestring(tcert), "u,u,u") This is how it's used now in drmtest.py: transport_cert = kraclient.system_certs.get_transport_cert() print "Subject DN: " + transport_cert.subject_dn print transport_cert.encoded crypto.import_cert(transport_nick, transport_cert, "u,u,u") 6. The code in ipaserver/install/drminstance.py creates a file /tmp/drm.p12. How long will this file stay in the /tmp folder? Should it be moved into a more permanent location? If it's a temporary file, can we use the python tempfile module? -- Endi S. Dewata From pspacek at redhat.com Wed Jul 16 15:13:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Jul 2014 17:13:18 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53A91DF6.6050604@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> Message-ID: <53C6968E.8050508@redhat.com> On 24.6.2014 08:43, Jan Cholasta wrote: > On 20.6.2014 20:23, Simo Sorce wrote: >> On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: >>> ipk11Private;privatekey: TRUE >>> ipk11Private;publickey: FALSE >> >> can these two ever hold a different value ? >> ie a privatekey be FALSE and a publickey be TRUE ? >> >> If not I suggest you do not add this attribute at all and assume their >> value ? > > +1, we can use default values for most, if not all of the boolean flag > attributes. Personally, I would try to avoid using ipk11 attributes until the > PKCS#11 module is designed/implemented. I hope that this will not create headache in future... Anyway, I have taken default values used by OpenDNSSEC v1 and modified them a little bit to accommodate our requirements. I'm using [1] as reference. Public keys =========== CKA_CLASS CKO_PUBLIC_KEY CKA_COPYABLE TRUE CKA_DERIVE FALSE CKA_ENCRYPT FALSE CKA_LOCAL TRUE CKA_MODIFIABLE TRUE CKA_PRIVATE TRUE CKA_TRUSTED FALSE CKA_VERIFY TRUE CKA_VERIFY_RECOVER TRUE CKA_WRAP FALSE Private keys ============ CKA_CLASS CKO_PRIVATE_KEY CKA_ALWAYS_AUTHENTICATE FALSE CKA_ALWAYS_SENSITIVE TRUE CKA_COPYABLE TRUE CKA_DECRYPT FALSE CKA_DERIVE FALSE CKA_EXTRACTABLE TRUE # changed by pspacek CKA_LOCAL TRUE CKA_MODIFIABLE TRUE CKA_NEVER_EXTRACTABLE TRUE CKA_PRIVATE TRUE CKA_SENSITIVE TRUE CKA_SIGN TRUE CKA_SIGN_RECOVER TRUE CKA_UNWRAP FALSE CKA_WRAP_WITH_TRUSTED FALSE We can use this set for all DNSSEC key pair objects. Replica keys will require small change, i.e. to change SIGN/VERIFY attributes to FALSE and WRAP/UNWRAP attributes to TRUE. OpenDNSSEC itself doesn't create any secret keys so we have to invent own defaults. I propose to use following values: Secret keys =========== CKA_CLASS CKO_SECRET_KEY CKA_COPYABLE TRUE CKA_DECRYPT FALSE CKA_DERIVE FALSE CKA_ENCRYPT FALSE CKA_EXTRACTABLE TRUE CKA_MODIFIABLE TRUE CKA_PRIVATE TRUE CKA_SENSITIVE FALSE CKA_SIGN FALSE CKA_UNWRAP TRUE CKA_VERIFY FALSE CKA_WRAP TRUE CKA_WRAP_WITH_TRUSTED FALSE >> (btw I forgot what's the point of that attribute) > > When it is true, a user may not access the object until the user has been > authenticated to the token (what PKCS#11 spec says). In practice it means that SoftHSM encrypts values of "PRIVATE" objects before storing them to file system. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf -- Petr^2 Spacek From npmccallum at redhat.com Wed Jul 16 20:16:57 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 16 Jul 2014 16:16:57 -0400 Subject: [Freeipa-devel] OTP Replay Prevention Review Message-ID: <1405541817.3105.13.camel@ipa.example.com> http://www.freeipa.org/page/V4/OTPReplayPrevention The above link contains the design page for our OTP Replay Prevention countermeasures proposal in FreeIPA. Please review. Nathaniel From npmccallum at redhat.com Wed Jul 16 20:18:02 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 16 Jul 2014 16:18:02 -0400 Subject: [Freeipa-devel] [PATCH] Fix typos in dns.py In-Reply-To: References: Message-ID: <1405541882.3105.14.camel@ipa.example.com> On Tue, 2014-07-15 at 21:49 -0600, Gabe Alford wrote: > Hello, > > > Fixes https://fedorahosted.org/freeipa/ticket/4429 ACK From jcholast at redhat.com Thu Jul 17 08:30:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Jul 2014 10:30:09 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53C6968E.8050508@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> Message-ID: <53C78991.1020708@redhat.com> On 16.7.2014 17:13, Petr Spacek wrote: > On 24.6.2014 08:43, Jan Cholasta wrote: >> On 20.6.2014 20:23, Simo Sorce wrote: >>> On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: >>>> ipk11Private;privatekey: TRUE >>>> ipk11Private;publickey: FALSE >>> >>> can these two ever hold a different value ? >>> ie a privatekey be FALSE and a publickey be TRUE ? >>> >>> If not I suggest you do not add this attribute at all and assume their >>> value ? >> >> +1, we can use default values for most, if not all of the boolean flag >> attributes. Personally, I would try to avoid using ipk11 attributes >> until the >> PKCS#11 module is designed/implemented. > > I hope that this will not create headache in future... > > Anyway, I have taken default values used by OpenDNSSEC v1 and modified > them a little bit to accommodate our requirements. > > I'm using [1] as reference. > > Public keys > =========== > CKA_CLASS CKO_PUBLIC_KEY > CKA_COPYABLE TRUE > CKA_DERIVE FALSE > CKA_ENCRYPT FALSE > CKA_LOCAL TRUE > CKA_MODIFIABLE TRUE > CKA_PRIVATE TRUE > CKA_TRUSTED FALSE > CKA_VERIFY TRUE > CKA_VERIFY_RECOVER TRUE > CKA_WRAP FALSE > > > Private keys > ============ > CKA_CLASS CKO_PRIVATE_KEY > CKA_ALWAYS_AUTHENTICATE FALSE > CKA_ALWAYS_SENSITIVE TRUE > CKA_COPYABLE TRUE > CKA_DECRYPT FALSE > CKA_DERIVE FALSE > CKA_EXTRACTABLE TRUE # changed by pspacek > CKA_LOCAL TRUE > CKA_MODIFIABLE TRUE > CKA_NEVER_EXTRACTABLE TRUE > CKA_PRIVATE TRUE > CKA_SENSITIVE TRUE > CKA_SIGN TRUE > CKA_SIGN_RECOVER TRUE > CKA_UNWRAP FALSE > CKA_WRAP_WITH_TRUSTED FALSE If you want the keys to be extractable, you also need to set CKA_SENSITIVE (and CKA_ALWAYS_SENSITIVE) to CK_FALSE. > > We can use this set for all DNSSEC key pair objects. Replica keys will > require small change, i.e. to change SIGN/VERIFY attributes to FALSE and > WRAP/UNWRAP attributes to TRUE. Replica private keys should not be extractable, i.e. should have CKA_EXTRACTABLE = CK_FALSE and CKA_SENSITIVE = CK_TRUE. > > OpenDNSSEC itself doesn't create any secret keys so we have to invent > own defaults. I propose to use following values: > > Secret keys > =========== > CKA_CLASS CKO_SECRET_KEY > CKA_COPYABLE TRUE > CKA_DECRYPT FALSE > CKA_DERIVE FALSE > CKA_ENCRYPT FALSE > CKA_EXTRACTABLE TRUE > CKA_MODIFIABLE TRUE > CKA_PRIVATE TRUE > CKA_SENSITIVE FALSE > CKA_SIGN FALSE > CKA_UNWRAP TRUE > CKA_VERIFY FALSE > CKA_WRAP TRUE > CKA_WRAP_WITH_TRUSTED FALSE When master key is rotated, CKA_WRAP on the old key should be set to CK_FALSE, so that new DNSSEC keys can't be wrapped with it. > > >>> (btw I forgot what's the point of that attribute) >> >> When it is true, a user may not access the object until the user has been >> authenticated to the token (what PKCS#11 spec says). > > In practice it means that SoftHSM encrypts values of "PRIVATE" objects > before storing them to file system. > > [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf > BTW I have noticed at that public key of each replica is stored in a ipk11 entry under cn=DNS. IMO it should be enough to store just the public key blob in ipaPublicKey attribute in cn=DNS itself. -- Jan Cholasta From tbabej at redhat.com Thu Jul 17 11:20:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Jul 2014 13:20:33 +0200 Subject: [Freeipa-devel] [PATCH 0244] ipatests: test_trust: Add test to cover lookup of trusdomains Message-ID: <53C7B181.7080801@redhat.com> Hi, Adds an integration tests that checks that all trustdomains are able to be found by trustdomain-find command right after the trust has been established. Also moves some code to allow easier adding common test cases for both POSIX and non-POSIX test classes. https://fedorahosted.org/freeipa/ticket/4208 -- 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-0244-ipatests-test_trust-Add-test-to-cover-lookup-of-trus.patch Type: text/x-patch Size: 3634 bytes Desc: not available URL: From tbabej at redhat.com Thu Jul 17 11:23:17 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Jul 2014 13:23:17 +0200 Subject: [Freeipa-devel] [PATCH 0244] ipatests: test_trust: Add test to cover lookup of trusdomains In-Reply-To: <53C7B181.7080801@redhat.com> References: <53C7B181.7080801@redhat.com> Message-ID: <53C7B225.1020204@redhat.com> On 07/17/2014 01:20 PM, Tomas Babej wrote: > Hi, > > Adds an integration tests that checks that all trustdomains are > able to be found by trustdomain-find command right after the > trust has been established. > > Also moves some code to allow easier adding common test cases for > both POSIX and non-POSIX test classes. > > https://fedorahosted.org/freeipa/ticket/4208 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Also, attached is a required patch for freeipa-ci. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ci-tbabej-0005-Enable-subdomains-for-basic-trust-tests.patch Type: text/x-patch Size: 1042 bytes Desc: not available URL: From tbabej at redhat.com Thu Jul 17 11:30:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Jul 2014 13:30:32 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: References: Message-ID: <53C7B3D8.6030305@redhat.com> On 07/16/2014 05:48 AM, Gabe Alford wrote: > Hello, > > Adds debug pid = yes to smb.conf when ipa-adtrust-install command is run. > https://fedorahosted.org/freeipa/ticket/3485 > > Thanks, > > Gabe > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Thanks, ACK. -- 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 Thu Jul 17 12:12:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Jul 2014 14:12:41 +0200 Subject: [Freeipa-devel] Correct firewall ports for multi-master replicas In-Reply-To: <53C392D4.701@redhat.com> References: <1405147249.8177.29.camel@freed> <53C392D4.701@redhat.com> Message-ID: <53C7BDB9.8020704@redhat.com> On 07/14/2014 10:20 AM, Petr Spacek wrote: > On 12.7.2014 08:40, James wrote: >> Hi freeipa-devel, >> >> I just added automatic firewalling for puppet-ipa. (Disclaimer it's >> currently untested...) >> >> What I'm missing is an exact and exhaustive list of exactly which ports >> each replica needs open for each other replica. I'm hoping that this >> list is symmetrical. > > AFAIK ipa-replica-conncheck utility and ipa-server-install script should show > list of required ports. > The ipa-replica-conncheck list is a good start, but it does not for example show ports of optional services, like DNS. You need to figure these out based on installed optional services. Martin From pviktori at redhat.com Thu Jul 17 19:08:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Jul 2014 21:08:02 +0200 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <53C6762F.50107@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> <53C6762F.50107@redhat.com> Message-ID: <53C81F12.4020902@redhat.com> On 07/16/2014 02:55 PM, Petr Viktorin wrote: > On 07/14/2014 11:45 AM, Ade Lee wrote: >> Hi all, >> >> I have rebased all the previous patches against master, and have >> squashed them all into a single patch. >> Its a large patch, but as many folks have already reviewed the >> constituent precursor patches, most if it >> should be familiar and easier to review. > > I think it would be nice to have the fixes that aren't related to DRM > (e.g. style issues) separate, so the patch can be reverted easily. But, > what's done is done. Thanks for the cleanup! > >> The main difference with what was specified before is that the DRM >> database is installed as a subtree >> to o=ipaca. This means that no new replication agreements will be >> needed to replicate DRM data. >> Replication agreements set up for the Dogtag CA will automatically >> replicate DRM data. >> >> In order for this patch to work, a new 10.2 build of Dogtag 10.2 is >> needed - with specific changes to >> allow the ability to install a database as a subtree of an existing >> tree. At this time, these >> changes have not yet been checked into the dogtag source. You can >> obtain such a build from: >> >> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ >> >> Please review, > > > I've started reading the code; here are my thoughts on the first part: > > In ipa-ca-install and ipa-replica-install, you only ever set > "REPLICA_INFO_TOP_DIR" to None. In Python, "global" has module scope, > it's not for the entire process. (And it's bad practice anyway.) > You'll need to pass it around explicitly, perhaps store it in > ReplicaConfig. > > It would be nice to use the admintool framework for the new script, > instead of copying the old boilerplate code again. See e.g. > ipa-server-certinstall for an example. > > Logging functions interpolate their arguments, so you should use e.g. > root_logger.critical("failed to configure %s instance %s", > subsystem, e) > instead of using the % operator. Also, in e.g. root_logger.debug( 'Unable to determine PIN for the Dogtag instance: %s' % str(e)) the "s" in "%s" means "convert to string", so explicit str() isn't necessary. > installutils.create_replica_config: Any time you call sys.exit(), please > log a message so we know why the log file ends. > > In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The > information is available in api.env once api is finalized. > > In ipa-server-install, do we want to display the message about backing > up /root/drmcert.p12 even if DRM is not installed? > > Please use path constants from ipaplatform.base.paths, or add new ones > if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}. > In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change > that back to paths.NAMED_KEYTAB. > Same in CAInstance.uninstall with "/usr/bin/pkiremove". > > In ipa-upgradeconfig.find_subject_base, the docstring should mention to > DsInstance.find_subject_base's docstring rather than being a copy; we > dont' want them getting out of sync. > > In DsInstance.find_subject_base, don't use a bare `except:`, at least do > `except Exception:`, so you don't e.g. disable Ctrl+C. > > In CADSInstance.uninstall, you don't need the _running and _user_exists > variables at all, just call the functions. > Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode. > Same in CAInstance.uninstall for _user_exists. > > In DogtagInstance, stop_tracking_certificates was moved here from > cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR. > Is that intended? > > In CAInstance.__init__, when calling DogtagInstance.__init__, consider > using super, and naming the arguments for clarity: > super(CAInstance, self).__init__( > realm=realm, > subsystem="CA", > service_desc="certificate server", > dogtag_constants=dogtag_constants, > ) Same in DogtagInstance, DRMInstance. > Since CAInstance inherits from DogtagInstance, the `enable`, > `start_instance`, `stop_instance`, `http_proxy` methods that just call > the superclass are unnecessary. > IMO the comment from CAInstance.__enable was important, it should be in > DogtagInstance.enable. > > In DogtagInstance.spawn_instance, it's not nice to modify lists the > caller pased in. Take a copy of the nolog first. Ideally combine that > with the conversion to tuple, and allow any sequence to be passed in: > nolog_list = tuple(nolog_list) + (self.admin_password, > self.dm_password) > > In CAInstance.__create_ca_user, it's better to use functions instead of > staticmethods, unless you'll want to override them in subclasses (which > you're explicitly discouraging here, by using the double underscore). > Anyway I don't get why you want these to be staticmethods. > dogtaginstance.py, drminstance.py: Avoid star imports, especially in new code. AFAICS you're only using root_logger from ipapython.ipa_log_manager. Also consider using an class-specific logger: class DogtagInstance(...): def __init__(...): ... self.log = ipa_log_manager.log_mgr.get_logger(self) later: self.log.error("Unable to determine PIN for the Dogtag instance:", e) About the "# noinspection PyBroadException" comments -- we already use pylint, I don't think we want instructions for other linters in the code. In DogtagInstance.get_admin_cert: admin_cert = entry_attrs.get('usercertificate')[0] This relies on the order of values returned by LDAP. If the choice of certificate doesn't matter here, leave a comment. drminstance.py: Please remove the `if __name__ == '__main__':` section at the end. If this needs to be tested, provide a real test; if it's example usage put it in the docs/docstring; if it's a personal tool just keep it to yourself. In DRMInstance.__init__, the docstring is wrong; __init__ doesn't return anything. In dogtag.py, this change breaks the formatting: > - |staus |string |cert_request_status|unicode [1]_ | > + |status |string |cert_request_status|unicode [1]_ | In drm.__init__, use `os.path.join(api.env.dot_ipa, 'alias')` instead of joining manually. There are also hardcoded paths, put them in the platform paths module. -- Petr? From rcritten at redhat.com Thu Jul 17 20:31:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jul 2014 16:31:30 -0400 Subject: [Freeipa-devel] weird data interaction Message-ID: <53C832A2.7020207@redhat.com> Saw something very weird today but my setup was also a bit odd so it may not be worthy of a ticket. Need a second opinion. Ok, so I wanted to test Jan's CA patches. They don't apply to current master due to the churn pre-4.0, so I just rewound the world to July 3 and applied them on the master branch. I don't believe the issues I'm seeing are related to his patches in any way. My environment is two masters, F-20, reasonably updated. Ok, so I started with them with 3.3.5 installs as I wanted to test upgrades. As a goof I ran the ipatests on one of them to simulate a bunch of work. There were some failures but I didn't pay close attention because testing in a replicated environment is a bit of an unknown (there are some timing issues IIRC). Anyway, so then I updated one of the masters to this pre-4.0 CA-patches build. Then I re-ran the tests. These I took more notice of as about half of them failed. Most of them related to adding users and this is due to the user objectclasses test we have. It can't revert a change: On the 4.0-ish master: # ipa config-mod --delattr ipauserobjectclasses=ipahost ipa: ERROR: change collided with another change Ouch. With ipahost in there nothing really adds correctly: # ipa user-add --first=tim --last=user testuser2 ipa: ERROR: missing attribute "fqdn" required by object class "ipaHost" On the 3.3.5 server I get a different, ACI-related error: # ipa user-add --first=tim --last=user testuser ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'member' attribute of entry 'cn=ipausers,cn=groups,cn=accounts,dc=greyoak,dc=com'. The user is actually added, just not to the ipausers group. And how, might you ask, did it get added at all? The config entry is out-of-sync between the masters: 3.3.5: Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser 4.0.0: Default user objectclasses: ipahost, ipaobject, person, top, ipasshuser, inetorgperson, organizationalperson, krbticketpolicyaux, krbprincipalaux, inetuser, posixaccount So yeah, I've got a bit of a Frankenstein install going on here, but has anyone else seen anything remotely similar? rob From edewata at redhat.com Thu Jul 17 22:03:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 17 Jul 2014 17:03:26 -0500 Subject: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights In-Reply-To: <53BE85DC.5070207@redhat.com> References: <53BE85DC.5070207@redhat.com> Message-ID: <53C8482E.6020806@redhat.com> On 7/10/2014 7:23 AM, Petr Vobornik wrote: > Reproduction: > * add 'extensibleObject' object class to target object > > https://fedorahosted.org/freeipa/ticket/4380 This is the original if-condition: (!rights && !(that.flags.indexOf('w_if_no_aci') > -1 && write_oc)) || (rights && rights.indexOf('w') < 0) Here if 'rights' has a value but there's no 'w' in it, the expression will evaluate to true. This is the new code: !can_write && !rights && !(that.flags.indexOf('w_if_no_aci') > -1 && write_oc) Here if 'rights' has any value the expression will evaluate to false. Is this correct? -- Endi S. Dewata From edewata at redhat.com Thu Jul 17 22:06:17 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 17 Jul 2014 17:06:17 -0500 Subject: [Freeipa-devel] [PATCH] 697-702 webui: usability improvements in attribute widget In-Reply-To: <53BE8EDF.8000606@redhat.com> References: <53BE8714.2090303@redhat.com> <53BE8EDF.8000606@redhat.com> Message-ID: <53C848D9.7040400@redhat.com> On 7/10/2014 8:02 AM, Petr Vobornik wrote: ACK. Comments below: >> == [PATCH] 699 webui: optimize (re)creation of option widget == >> >> There is a case where attributes widget can contain > 1000 items. >> It's about 3000 nodes. It's slow in jQuery. Simple move to dojo >> speeds it up (is closer to native calls) while maintaining developer >> friendliness. >> >> Now the biggest lag is in browser's render. It's probably not worth >> developer time to optimize that. Is it common to have many items in this widget (doesn't have to be bigger than 1000, but just large enough)? Maybe the UI should provide some kind of paging interface, not just for performance reason, but also for usability. >> == [PATCH] 700 webui: custom attr in attributes widget == >> >> Web UI doesn't always know what are the possible attributes >> for target object. This will allow to add custom attributes >> if necessary. Right now you can add an undefined attribute, but it will fail when you try to save it. Should the UI perform a schema validation before accepting the new attribute? Or should the UI provide a list of valid attributes? -- Endi S. Dewata From edewata at redhat.com Thu Jul 17 22:08:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 17 Jul 2014 17:08:28 -0500 Subject: [Freeipa-devel] [PATCH] 703-707 webui: improvements in permission details page In-Reply-To: <53BE8933.80506@redhat.com> References: <53BE8933.80506@redhat.com> Message-ID: <53C8495C.2020201@redhat.com> ACK. See comment below: On 7/10/2014 7:38 AM, Petr Vobornik wrote: > == [PATCH] 707 webui: disable ipapermbindruletype if permission in a > privilege == > > User is not able to change Bind Rule Type if permission is already > member of a privilege. Let's disable it and don't confuse user. If you open a permission, go to the Privileges tab, add/remove a privilege, then go back to the Settings tab, the Bind rule type is not updated automatically, you'd have to click Refresh to see the change. -- Endi S. Dewata From edewata at redhat.com Thu Jul 17 22:09:17 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 17 Jul 2014 17:09:17 -0500 Subject: [Freeipa-devel] [PATCH] 708 webui: fix disabled state of service's PAC type In-Reply-To: <53BE895E.4090306@redhat.com> References: <53BE895E.4090306@redhat.com> Message-ID: <53C8498D.5050801@redhat.com> On 7/10/2014 7:38 AM, Petr Vobornik wrote: > Nested options (MS-PAC and PAD) of service's PAC type should be > disabled if no value is supplied (default value is "Inherited > from server configuration"). That was not the case - regression. > > This patch fixes it and along with it simplifies the update method > of option_widget_base to be more comprehensible. ACK. -- Endi S. Dewata From pviktori at redhat.com Fri Jul 18 07:50:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 09:50:43 +0200 Subject: [Freeipa-devel] weird data interaction In-Reply-To: <53C832A2.7020207@redhat.com> References: <53C832A2.7020207@redhat.com> Message-ID: <53C8D1D3.9040309@redhat.com> On 07/17/2014 10:31 PM, Rob Crittenden wrote: > Saw something very weird today but my setup was also a bit odd so it may > not be worthy of a ticket. Need a second opinion. > > Ok, so I wanted to test Jan's CA patches. They don't apply to current > master due to the churn pre-4.0, so I just rewound the world to July 3 > and applied them on the master branch. I don't believe the issues I'm > seeing are related to his patches in any way. > > My environment is two masters, F-20, reasonably updated. What DS version are you using? > Ok, so I started with them with 3.3.5 installs as I wanted to test > upgrades. As a goof I ran the ipatests on one of them to simulate a > bunch of work. There were some failures but I didn't pay close attention > because testing in a replicated environment is a bit of an unknown > (there are some timing issues IIRC). Anyway, so then I updated one of > the masters to this pre-4.0 CA-patches build. > > Then I re-ran the tests. These I took more notice of as about half of > them failed. > > Most of them related to adding users and this is due to the user > objectclasses test we have. It can't revert a change: > > On the 4.0-ish master: > > # ipa config-mod --delattr ipauserobjectclasses=ipahost > ipa: ERROR: change collided with another change There was a DS bug that affected multi-valued attributes, that caused MidairCollisions like this. So this would be my first guess: https://fedorahosted.org/389/ticket/47806 -- Petr? From pviktori at redhat.com Fri Jul 18 08:06:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 10:06:14 +0200 Subject: [Freeipa-devel] [PATCH] Fix typos in dns.py In-Reply-To: <1405541882.3105.14.camel@ipa.example.com> References: <1405541882.3105.14.camel@ipa.example.com> Message-ID: <53C8D576.6060302@redhat.com> On 07/16/2014 10:18 PM, Nathaniel McCallum wrote: > On Tue, 2014-07-15 at 21:49 -0600, Gabe Alford wrote: >> Hello, >> >> >> Fixes https://fedorahosted.org/freeipa/ticket/4429 > > ACK Pushed to master, ipa-4-1, ipa-4-0: 9a0aae013393097de655b7c6d1e584b2c8a0a75b -- Petr? From pviktori at redhat.com Fri Jul 18 08:09:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 10:09:00 +0200 Subject: [Freeipa-devel] [PATCH 0241] trusts: Make cn=adtrust agents sysaccount nestedgroup In-Reply-To: <53C531B5.4050109@redhat.com> References: <53C3A7C9.6080205@redhat.com> <53C3F077.8000704@redhat.com> <53C4DEE3.4060004@redhat.com> <53C531B5.4050109@redhat.com> Message-ID: <53C8D61C.505@redhat.com> On 07/15/2014 03:50 PM, Jan Cholasta wrote: > On 15.7.2014 09:57, Tomas Babej wrote: >> >> On 07/14/2014 05:00 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 14.7.2014 11:50, Tomas Babej wrote: >>>> Hi, >>>> >>>> Since recent permissions work references this entry, we need to be >>>> able to have memberOf attributes created on this entry. Hence we >>>> need to include the nestedgroup objectclass. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4433 >>> >>> NACK, "default" will not work for IPA upgrades, you have to use "add". >>> >> >> Oops, thanks for the catch, fixed. >> > > ACK. Pushed to master, ipa-4-1, ipa-4-0: b7a1401e9dd06c1c8b055295087907e33954a889 -- Petr? From pviktori at redhat.com Fri Jul 18 08:11:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 10:11:29 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C7B3D8.6030305@redhat.com> References: <53C7B3D8.6030305@redhat.com> Message-ID: <53C8D6B1.2010503@redhat.com> On 07/17/2014 01:30 PM, Tomas Babej wrote: > > On 07/16/2014 05:48 AM, Gabe Alford wrote: >> Hello, >> >> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is run. >> https://fedorahosted.org/freeipa/ticket/3485 >> >> Thanks, >> >> Gabe > > Thanks, ACK. > Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df -- Petr? From dkupka at redhat.com Fri Jul 18 10:33:33 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 18 Jul 2014 12:33:33 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check Message-ID: <53C8F7FD.9030200@redhat.com> https://fedorahosted.org/freeipa/ticket/2796 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0002-Improve-password-validity-check.patch Type: text/x-patch Size: 3038 bytes Desc: not available URL: From dkupka at redhat.com Fri Jul 18 10:39:00 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 18 Jul 2014 12:39:00 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Test generated passwords composed of all allowed charactes Message-ID: <53C8F944.30104@redhat.com> Test verifying that IPA server is able to install using passwords composed of all but forbidden characters. Related to https://fedorahosted.org/freeipa/ticket/2796 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0003-Test-generated-passwords-composed-of-all-allowed-cha.patch Type: text/x-patch Size: 4046 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 18 10:41:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Jul 2014 12:41:51 +0200 Subject: [Freeipa-devel] [PATCH] 0621 test_xmlrpc: Update tests In-Reply-To: <53BBEE8C.6040604@redhat.com> References: <53BBEE8C.6040604@redhat.com> Message-ID: <53C8F9EF.1050806@redhat.com> On 07/08/2014 03:13 PM, Petr Viktorin wrote: > Two test fixes for recent permission changes Functionally the patch works fine, permission tests are now error-less. There is just one whitespace error. # git am /home/mkosek/freeipa-pviktori-0621-test_xmlrpc-Update-tests.patch Applying: test_xmlrpc: Update tests /root/freeipa-master/.git/rebase-apply/patch:37: trailing whitespace. u'allow (write) groupdn = "ldap:///%s";)' % warning: 1 line adds whitespace errors. When you fix it, it's an ACK. Martin From mkosek at redhat.com Fri Jul 18 10:52:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Jul 2014 12:52:12 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check In-Reply-To: <53C8F7FD.9030200@redhat.com> References: <53C8F7FD.9030200@redhat.com> Message-ID: <53C8FC5C.9030803@redhat.com> On 07/18/2014 12:33 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/2796 1) Would it be easier/more convenient to just implement following simple check instead of bad_prefix/bad_suffix? if password.strip() != password: raise ValueError('Password must not start or end with whitespace') 2) The main goal of the ticket 2796 was not fixed yet. It sometimes happen that when installation crashes somewhere right after pkicreate, it does not record and and does not uninstall the PKI component during "ipa-server-install --uninstall". You may artificially invoke some crash in cainstance.py after pkicreate to test it. When fixing it, check how is_configured() in Service object works an how self.backup_state is called in other service modules (like dsinstance.py) where the detection works correctly. Martin From pviktori at redhat.com Fri Jul 18 11:12:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 13:12:33 +0200 Subject: [Freeipa-devel] [PATCH] 0003 Test generated passwords composed of all allowed charactes In-Reply-To: <53C8F944.30104@redhat.com> References: <53C8F944.30104@redhat.com> Message-ID: <53C90121.70707@redhat.com> On 07/18/2014 12:39 PM, David Kupka wrote: > Test verifying that IPA server is able to install using passwords > composed of all but forbidden characters. > > Related to https://fedorahosted.org/freeipa/ticket/2796 This doesn't work with current master. When you send patches that depend on each other, either send them in a single mail, or explicitly say what the dependencies are. When an exception is raised, you're only logging a message and hiding the error. So not only is the traceback lost, but the test always passes! The proper way to do this is: try: tasks.install_master(self.master) finally: tasks.uninstall_master(self.master) Any other cleanup task, like restoring passwords in the config, should also be in its finally: block. Currently all our tests are (or try to be :) deterministic; I rely on the fact that re-running the tests reproduces the results. Instead of randomness, just use some well-crafted static passwords. You can also test e.g. shorter passwords or ones with longer runs of whitespace -- there's not much variety in what you generate here. And you should be able to get by with fewer than 10 runs. It would be nice to add some basic smoke test to ensure the installation actually works. Something like user-show admin. Finally, please put integration tests in ipatests/test_integration, if there's not big reason against that. Nitpick: in set([chr(c) for c in range(0x20, 0x7F)]) you could avoid creating a temporary list: set(chr(c) for c in range(0x20, 0x7F)) -- Petr? From pspacek at redhat.com Fri Jul 18 12:06:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Jul 2014 14:06:33 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C8D6B1.2010503@redhat.com> References: <53C7B3D8.6030305@redhat.com> <53C8D6B1.2010503@redhat.com> Message-ID: <53C90DC9.4070204@redhat.com> On 18.7.2014 10:11, Petr Viktorin wrote: > On 07/17/2014 01:30 PM, Tomas Babej wrote: >> >> On 07/16/2014 05:48 AM, Gabe Alford wrote: >>> Hello, >>> >>> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is run. >>> https://fedorahosted.org/freeipa/ticket/3485 >>> >>> Thanks, >>> >>> Gabe >> >> Thanks, ACK. >> > > > Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df Isn't it applicable to ipa-4-0 too? I'm just curios :-) -- Petr^2 Spacek From pviktori at redhat.com Fri Jul 18 12:19:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 14:19:34 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C90DC9.4070204@redhat.com> References: <53C7B3D8.6030305@redhat.com> <53C8D6B1.2010503@redhat.com> <53C90DC9.4070204@redhat.com> Message-ID: <53C910D6.7070608@redhat.com> On 07/18/2014 02:06 PM, Petr Spacek wrote: > On 18.7.2014 10:11, Petr Viktorin wrote: >> On 07/17/2014 01:30 PM, Tomas Babej wrote: >>> >>> On 07/16/2014 05:48 AM, Gabe Alford wrote: >>>> Hello, >>>> >>>> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is >>>> run. >>>> https://fedorahosted.org/freeipa/ticket/3485 >>>> >>>> Thanks, >>>> >>>> Gabe >>> >>> Thanks, ACK. >>> >> >> >> Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df > > Isn't it applicable to ipa-4-0 too? > > I'm just curios :-) Well, the patch does apply there, of course :) The ticket is marked as RFE, so I didn't put it in the bugfix release. If there's a reason we want it in 4.0.x, let me hear it. -- Petr? From pspacek at redhat.com Fri Jul 18 12:31:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Jul 2014 14:31:00 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C910D6.7070608@redhat.com> References: <53C7B3D8.6030305@redhat.com> <53C8D6B1.2010503@redhat.com> <53C90DC9.4070204@redhat.com> <53C910D6.7070608@redhat.com> Message-ID: <53C91384.9090807@redhat.com> On 18.7.2014 14:19, Petr Viktorin wrote: > On 07/18/2014 02:06 PM, Petr Spacek wrote: >> On 18.7.2014 10:11, Petr Viktorin wrote: >>> On 07/17/2014 01:30 PM, Tomas Babej wrote: >>>> >>>> On 07/16/2014 05:48 AM, Gabe Alford wrote: >>>>> Hello, >>>>> >>>>> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is >>>>> run. >>>>> https://fedorahosted.org/freeipa/ticket/3485 >>>>> >>>>> Thanks, >>>>> >>>>> Gabe >>>> >>>> Thanks, ACK. >>>> >>> >>> >>> Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df >> >> Isn't it applicable to ipa-4-0 too? >> >> I'm just curios :-) > > Well, the patch does apply there, of course :) > > The ticket is marked as RFE, so I didn't put it in the bugfix release. If > there's a reason we want it in 4.0.x, let me hear it. IMHO easier debugging for AD trusts sounds like sufficient reason for inclusion to me. The patch is soooo tiny that I don't see a reasons against including it to 4.0.x. -- Petr^2 Spacek From pviktori at redhat.com Fri Jul 18 12:42:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 14:42:20 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C91384.9090807@redhat.com> References: <53C7B3D8.6030305@redhat.com> <53C8D6B1.2010503@redhat.com> <53C90DC9.4070204@redhat.com> <53C910D6.7070608@redhat.com> <53C91384.9090807@redhat.com> Message-ID: <53C9162C.2020900@redhat.com> On 07/18/2014 02:31 PM, Petr Spacek wrote: > On 18.7.2014 14:19, Petr Viktorin wrote: >> On 07/18/2014 02:06 PM, Petr Spacek wrote: >>> On 18.7.2014 10:11, Petr Viktorin wrote: >>>> On 07/17/2014 01:30 PM, Tomas Babej wrote: >>>>> >>>>> On 07/16/2014 05:48 AM, Gabe Alford wrote: >>>>>> Hello, >>>>>> >>>>>> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is >>>>>> run. >>>>>> https://fedorahosted.org/freeipa/ticket/3485 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gabe >>>>> >>>>> Thanks, ACK. >>>>> >>>> >>>> >>>> Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df >>> >>> Isn't it applicable to ipa-4-0 too? >>> >>> I'm just curios :-) >> >> Well, the patch does apply there, of course :) >> >> The ticket is marked as RFE, so I didn't put it in the bugfix release. If >> there's a reason we want it in 4.0.x, let me hear it. > > IMHO easier debugging for AD trusts sounds like sufficient reason for > inclusion to me. > > The patch is soooo tiny that I don't see a reasons against including it > to 4.0.x. OK, I now see it's a tiny patch with also a tiny effect. (I don't read & understand every patch that I push :) Pushed to ipa-4-0: 2afcbff133fbb9659a23633283c455a1851589df -- Petr? From pviktori at redhat.com Fri Jul 18 13:03:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Jul 2014 15:03:58 +0200 Subject: [Freeipa-devel] [PATCH] 0621 test_xmlrpc: Update tests In-Reply-To: <53C8F9EF.1050806@redhat.com> References: <53BBEE8C.6040604@redhat.com> <53C8F9EF.1050806@redhat.com> Message-ID: <53C91B3E.1010901@redhat.com> On 07/18/2014 12:41 PM, Martin Kosek wrote: > On 07/08/2014 03:13 PM, Petr Viktorin wrote: >> Two test fixes for recent permission changes > > Functionally the patch works fine, permission tests are now error-less. There > is just one whitespace error. > > # git am /home/mkosek/freeipa-pviktori-0621-test_xmlrpc-Update-tests.patch > Applying: test_xmlrpc: Update tests > /root/freeipa-master/.git/rebase-apply/patch:37: trailing whitespace. > u'allow (write) groupdn = "ldap:///%s";)' % > warning: 1 line adds whitespace errors. > > When you fix it, it's an ACK. Thanks! Fixed & pushed to master, ipa-4-0, ipa-4-1: cd4fd60c0ef7026964aff971346720e9fd60d148 -- Petr? From mkosek at redhat.com Fri Jul 18 13:07:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Jul 2014 15:07:17 +0200 Subject: [Freeipa-devel] [PATCH] Enable debug pid in smb.conf In-Reply-To: <53C9162C.2020900@redhat.com> References: <53C7B3D8.6030305@redhat.com> <53C8D6B1.2010503@redhat.com> <53C90DC9.4070204@redhat.com> <53C910D6.7070608@redhat.com> <53C91384.9090807@redhat.com> <53C9162C.2020900@redhat.com> Message-ID: <53C91C05.9090308@redhat.com> On 07/18/2014 02:42 PM, Petr Viktorin wrote: > On 07/18/2014 02:31 PM, Petr Spacek wrote: >> On 18.7.2014 14:19, Petr Viktorin wrote: >>> On 07/18/2014 02:06 PM, Petr Spacek wrote: >>>> On 18.7.2014 10:11, Petr Viktorin wrote: >>>>> On 07/17/2014 01:30 PM, Tomas Babej wrote: >>>>>> >>>>>> On 07/16/2014 05:48 AM, Gabe Alford wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Adds debug pid = yes to smb.conf when ipa-adtrust-install command is >>>>>>> run. >>>>>>> https://fedorahosted.org/freeipa/ticket/3485 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gabe >>>>>> >>>>>> Thanks, ACK. >>>>>> >>>>> >>>>> >>>>> Pushed to master, ipa-4-1: 2afcbff133fbb9659a23633283c455a1851589df >>>> >>>> Isn't it applicable to ipa-4-0 too? >>>> >>>> I'm just curios :-) >>> >>> Well, the patch does apply there, of course :) >>> >>> The ticket is marked as RFE, so I didn't put it in the bugfix release. If >>> there's a reason we want it in 4.0.x, let me hear it. >> >> IMHO easier debugging for AD trusts sounds like sufficient reason for >> inclusion to me. >> >> The patch is soooo tiny that I don't see a reasons against including it >> to 4.0.x. > > OK, I now see it's a tiny patch with also a tiny effect. (I don't read & > understand every patch that I push :) > > Pushed to ipa-4-0: 2afcbff133fbb9659a23633283c455a1851589df Note that tiny patch does not necessarily equal tiny effect :-) http://en.wikipedia.org/wiki/Butterfly_effect Martin From rcritten at redhat.com Fri Jul 18 13:50:50 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jul 2014 09:50:50 -0400 Subject: [Freeipa-devel] weird data interaction In-Reply-To: <53C8D1D3.9040309@redhat.com> References: <53C832A2.7020207@redhat.com> <53C8D1D3.9040309@redhat.com> Message-ID: <53C9263A.4030002@redhat.com> Petr Viktorin wrote: > On 07/17/2014 10:31 PM, Rob Crittenden wrote: >> Saw something very weird today but my setup was also a bit odd so it may >> not be worthy of a ticket. Need a second opinion. >> >> Ok, so I wanted to test Jan's CA patches. They don't apply to current >> master due to the churn pre-4.0, so I just rewound the world to July 3 >> and applied them on the master branch. I don't believe the issues I'm >> seeing are related to his patches in any way. >> >> My environment is two masters, F-20, reasonably updated. > > What DS version are you using? > >> Ok, so I started with them with 3.3.5 installs as I wanted to test >> upgrades. As a goof I ran the ipatests on one of them to simulate a >> bunch of work. There were some failures but I didn't pay close attention >> because testing in a replicated environment is a bit of an unknown >> (there are some timing issues IIRC). Anyway, so then I updated one of >> the masters to this pre-4.0 CA-patches build. >> >> Then I re-ran the tests. These I took more notice of as about half of >> them failed. >> >> Most of them related to adding users and this is due to the user >> objectclasses test we have. It can't revert a change: >> >> On the 4.0-ish master: >> >> # ipa config-mod --delattr ipauserobjectclasses=ipahost >> ipa: ERROR: change collided with another change > > There was a DS bug that affected multi-valued attributes, that caused > MidairCollisions like this. So this would be my first guess: > https://fedorahosted.org/389/ticket/47806 I'm running 389-ds-base-1.3.2.16-1 Yeah, I see your point. I guess I'll wait for a fix. rob From lkrispen at redhat.com Fri Jul 18 14:07:01 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 18 Jul 2014 16:07:01 +0200 Subject: [Freeipa-devel] weird data interaction In-Reply-To: <53C9263A.4030002@redhat.com> References: <53C832A2.7020207@redhat.com> <53C8D1D3.9040309@redhat.com> <53C9263A.4030002@redhat.com> Message-ID: <53C92A05.9080503@redhat.com> On 07/18/2014 03:50 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 07/17/2014 10:31 PM, Rob Crittenden wrote: >>> Saw something very weird today but my setup was also a bit odd so it may >>> not be worthy of a ticket. Need a second opinion. >>> >>> Ok, so I wanted to test Jan's CA patches. They don't apply to current >>> master due to the churn pre-4.0, so I just rewound the world to July 3 >>> and applied them on the master branch. I don't believe the issues I'm >>> seeing are related to his patches in any way. >>> >>> My environment is two masters, F-20, reasonably updated. >> What DS version are you using? >> >>> Ok, so I started with them with 3.3.5 installs as I wanted to test >>> upgrades. As a goof I ran the ipatests on one of them to simulate a >>> bunch of work. There were some failures but I didn't pay close attention >>> because testing in a replicated environment is a bit of an unknown >>> (there are some timing issues IIRC). Anyway, so then I updated one of >>> the masters to this pre-4.0 CA-patches build. >>> >>> Then I re-ran the tests. These I took more notice of as about half of >>> them failed. >>> >>> Most of them related to adding users and this is due to the user >>> objectclasses test we have. It can't revert a change: >>> >>> On the 4.0-ish master: >>> >>> # ipa config-mod --delattr ipauserobjectclasses=ipahost >>> ipa: ERROR: change collided with another change >> There was a DS bug that affected multi-valued attributes, that caused >> MidairCollisions like this. So this would be my first guess: >> https://fedorahosted.org/389/ticket/47806 > I'm running 389-ds-base-1.3.2.16-1 > > Yeah, I see your point. I guess I'll wait for a fix. that should be fixed in 1.3.2.19 > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From sbose at redhat.com Fri Jul 18 14:23:50 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 18 Jul 2014 16:23:50 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v3 Message-ID: <20140718142350.GE2158@localhost.localdomain> Hi, I have updated http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust with the comments from the latest round. The changes can be see at http://www.freeipa.org/index.php?title=V4%2FMigrating_existing_environments_to_Trust&diff=8696&oldid=8181 I think most aspects are clear now. I think only one decision is needed about how to manage the assignment of a host to a view. In the original draft host groups were used to connect hosts to views. There is only the drawback that a host can only have one view but can belong to multiple host groups. So chances are that when we follow the host-group memberships of a single host to the views we end with two or even more views. To get around this Alexander suggested to add a new single-value LDAP attribute to the host objects which holds the DN of a view. With this all ambiguity is gone. The drawback here is that now at least in the WebUI each host which should not see the default view must be added individually to a view. (On the command line for-loops from the shell can be used). I would prefer Alexander's suggestion. Because although on the first look the host-group approach sounds more comfortable from the management point of view I think the difference is not that large when looking a bit more into the details. It was already recommended to not use host-groups already used for other purposes like HBAC or sudo for views management to avoid unexpected changes of POSIX IDs when those groups are modified for other purposes. For the host-groups which are exclusively used for view management we can add DS plugin which make sure that a host is always only a member of one of such groups to avoid ambiguity. Initially adding hosts to a host-groups is a bit easier due to the host-group add-dialog of the WebUI but later on each new host which should not have the default view has to be added to the related host group as well. It might be even a bit more effort than with Alexander's suggestion because a host cannot be added to a group when it is created, so a host has to be created first and then can be added to a group. As a summary I think there are no real benefits using host-groups for management compared to assigning the view directly to the host. Other opinions, comments and suggestions are welcome. bye, Sumit From rcritten at redhat.com Fri Jul 18 20:32:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jul 2014 16:32:05 -0400 Subject: [Freeipa-devel] [PATCH] - Add DRM to IPA In-Reply-To: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> References: <1922084174.7689340.1405331152213.JavaMail.zimbra@redhat.com> Message-ID: <53C98445.9000900@redhat.com> Ade Lee wrote: > Hi all, > > I have rebased all the previous patches against master, and have squashed them all into a single patch. > Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it > should be familiar and easier to review. > > The main difference with what was specified before is that the DRM database is installed as a subtree > to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. > Replication agreements set up for the Dogtag CA will automatically replicate DRM data. > > In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to > allow the ability to install a database as a subtree of an existing tree. At this time, these > changes have not yet been checked into the dogtag source. You can obtain such a build from: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ > > Please review, The BuildRequires needs to be updated to avoid a bunch of lint errors: ./make-lint ************* Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:249: [E0611(no-name-in-module), ] No name 'crypto' in module 'pki') ipaserver/plugins/dogtag.py:250: [E0611(no-name-in-module), ] No name 'key' in module 'pki') ipaserver/plugins/dogtag.py:251: [E0611(no-name-in-module), ] No name 'kra' in module 'pki') ipaserver/plugins/dogtag.py:1952: [E1101(no-member), drm._setup] Instance of 'PKIConnection' has no 'set_authentication_cert' member) ipaserver/plugins/dogtag.py:1963: [E1101(no-member), drm._setup] Module 'pki' has no 'CERT_HEADER' member) ipaserver/plugins/dogtag.py:1964: [E1101(no-member), drm._setup] Module 'pki' has no 'CERT_FOOTER' member) ************* Module ipaserver.install.dogtaginstance ipaserver/install/dogtaginstance.py:71: [E1101(no-member), get_security_domain] Instance of 'SecurityDomainClient' has no 'get_security_domain_info' member) I forget what back and forth we had on DRM vs no DRM by default, but is it right to have no option at all to add one at install time, ala DNS? My first install failed: Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: ln: failed to create symbolic link ?/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak?: Permission denied Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: SUCCESS: Successfully archived '/var/lib/pki/pki-tomcat/conf/ca/archives/CS.cfg.bak.20140718153836' Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: WARNING: Failed to backup '/var/lib/pki/pki-tomcat/conf/ca/CS.cfg' to '/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak'! Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: /usr/share/pki/scripts/operations: line 1579: 0: command not found Jul 18 15:38:36 ipa.example.com systemd[1]: pki-tomcatd at pki-tomcat.service: control process exited, code=exited status=1 Jul 18 15:38:36 ipa.example.com systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. This is due to SELinux issues: type=AVC msg=audit(1405712316.049:1656): avc: denied { setfscreate } for pid=16702 comm="cp" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process type=AVC msg=audit(1405712316.049:1657): avc: denied { relabelfrom } for pid=16702 comm="cp" name="CS.cfg.bak.20140718153836" dev="dm-0" ino=431097 scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file type=AVC msg=audit(1405712316.050:1658): avc: denied { create } for pid=16703 comm="ln" name="CS.cfg.bak" scontext=system_u:system_r:pki_tomcat_t:s0 tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file I put it into permissive and continued. The installer still references backing up /root/drmcert.p12 but it isn't created by default. The estimate for configuring the DRM seems off. On my VM it took 126 seconds, not 210. Mileage may vary but since my box was the source for all the other timings :-) On the plus side the DRM seems to work. I used the ca-agent cert and was able to follow the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Testing_the_Key_Archival_and_Recovery_Setup.html to issue and recover a key. rob From jcholast at redhat.com Mon Jul 21 07:56:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 21 Jul 2014 09:56:17 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: Message-ID: <53CCC7A1.2090201@redhat.com> Hi, On 16.7.2014 05:48, Gabe Alford wrote: > Hello, > > Adds AD admin and password to interactive commands. > https://fedorahosted.org/freeipa/ticket/3034 > > Thanks, > > Gabe I think that instead of making the parameters mandatory, you should instead set alwaysask=True on them. Honza -- Jan Cholasta From jcholast at redhat.com Mon Jul 21 07:59:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 21 Jul 2014 09:59:09 +0200 Subject: [Freeipa-devel] [PATCH 0243] ipalib: idrange: Make non-implemented range types fail the In-Reply-To: <53C66A91.5030203@redhat.com> References: <53C66A91.5030203@redhat.com> Message-ID: <53CCC84D.7010106@redhat.com> Hi, On 16.7.2014 14:05, Tomas Babej wrote: > Hi, > > The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to > pass the validation tests, however, they are not implemented nor > checked by the 389 server plugin. > > https://fedorahosted.org/freeipa/ticket/4323 ACK. -- Jan Cholasta From mkosek at redhat.com Mon Jul 21 08:28:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Jul 2014 10:28:15 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53CCC7A1.2090201@redhat.com> References: <53CCC7A1.2090201@redhat.com> Message-ID: <53CCCF1F.6040707@redhat.com> On 07/21/2014 09:56 AM, Jan Cholasta wrote: > Hi, > > On 16.7.2014 05:48, Gabe Alford wrote: >> Hello, >> >> Adds AD admin and password to interactive commands. >> https://fedorahosted.org/freeipa/ticket/3034 >> >> Thanks, >> >> Gabe > > I think that instead of making the parameters mandatory, you should instead set > alwaysask=True on them. > > Honza > Trust can be established either with user+password options OR with --trust-secret option - i.e. you cannot use mandatory options nor alwaysask. This would rather lead to interactive_prompt_callback checking if any of authentication method is passed and asking for them if they aren't. Martin From jcholast at redhat.com Mon Jul 21 08:31:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 21 Jul 2014 10:31:14 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53CCCF1F.6040707@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> Message-ID: <53CCCFD2.3040306@redhat.com> On 21.7.2014 10:28, Martin Kosek wrote: > On 07/21/2014 09:56 AM, Jan Cholasta wrote: >> Hi, >> >> On 16.7.2014 05:48, Gabe Alford wrote: >>> Hello, >>> >>> Adds AD admin and password to interactive commands. >>> https://fedorahosted.org/freeipa/ticket/3034 >>> >>> Thanks, >>> >>> Gabe >> >> I think that instead of making the parameters mandatory, you should instead set >> alwaysask=True on them. >> >> Honza >> > > Trust can be established either with user+password options OR with > --trust-secret option - i.e. you cannot use mandatory options nor alwaysask. Ah, right. > > This would rather lead to interactive_prompt_callback checking if any of > authentication method is passed and asking for them if they aren't. +1 > > Martin > -- Jan Cholasta From pvoborni at redhat.com Mon Jul 21 08:59:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 10:59:03 +0200 Subject: [Freeipa-devel] [PATCH] 697-702 webui: usability improvements in attribute widget In-Reply-To: <53C848D9.7040400@redhat.com> References: <53BE8714.2090303@redhat.com> <53BE8EDF.8000606@redhat.com> <53C848D9.7040400@redhat.com> Message-ID: <53CCD657.9020300@redhat.com> On 18.7.2014 00:06, Endi Sukma Dewata wrote: > On 7/10/2014 8:02 AM, Petr Vobornik wrote: > > ACK. Comments below: > >>> == [PATCH] 699 webui: optimize (re)creation of option widget == >>> >>> There is a case where attributes widget can contain > 1000 items. >>> It's about 3000 nodes. It's slow in jQuery. Simple move to dojo >>> speeds it up (is closer to native calls) while maintaining developer >>> friendliness. >>> >>> Now the biggest lag is in browser's render. It's probably not worth >>> developer time to optimize that. > > Is it common to have many items in this widget (doesn't have to be > bigger than 1000, but just large enough)? Maybe the UI should provide > some kind of paging interface, not just for performance reason, but also > for usability. It's not common, it's only in one case and therefore IMO we don't have to spend more time on this issue. WRT paging: IMHO the classic one won't help, but 'infinite scroll paging' might. I would rather see this type of paging on search facets first. > >>> == [PATCH] 700 webui: custom attr in attributes widget == >>> >>> Web UI doesn't always know what are the possible attributes >>> for target object. This will allow to add custom attributes >>> if necessary. > > Right now you can add an undefined attribute, but it will fail when you > try to save it. Should the UI perform a schema validation before > accepting the new attribute? Or should the UI provide a list of valid > attributes? > If we knew the list of valid attrs/schema we would not need this patch. pushed to: master: * b68f819de75073285c17c28a30afe5b5dbfe5176 webui: improve usability of attributes widget * 740d42257fc00235b1cebdc90866fe34bf9464b3 webui: add filter to attributes widget * 9fa447cb6e5f1476072cf167eec8502cfc3e38e3 webui: optimize (re)creation of option widget * 4aefc0d6fe7a4879a9b8024eb7424b4dfa5fa7ca webui: custom attr in attributes widget * d2f2fc5addc0634b24ccda7a5aae1ed1d3c6001a webui: attr widget: get list of possible attrs from ipapermdefaultattr * 8fcf6d6b34400c1924f509701856b86e4f647624 webui: option_widget_base: sort options ipa-4-1: * b68f819de75073285c17c28a30afe5b5dbfe5176 webui: improve usability of attributes widget * 740d42257fc00235b1cebdc90866fe34bf9464b3 webui: add filter to attributes widget * 9fa447cb6e5f1476072cf167eec8502cfc3e38e3 webui: optimize (re)creation of option widget * 4aefc0d6fe7a4879a9b8024eb7424b4dfa5fa7ca webui: custom attr in attributes widget * d2f2fc5addc0634b24ccda7a5aae1ed1d3c6001a webui: attr widget: get list of possible attrs from ipapermdefaultattr * 8fcf6d6b34400c1924f509701856b86e4f647624 webui: option_widget_base: sort options ipa-4-0: * b68f819de75073285c17c28a30afe5b5dbfe5176 webui: improve usability of attributes widget * 740d42257fc00235b1cebdc90866fe34bf9464b3 webui: add filter to attributes widget * 9fa447cb6e5f1476072cf167eec8502cfc3e38e3 webui: optimize (re)creation of option widget * 4aefc0d6fe7a4879a9b8024eb7424b4dfa5fa7ca webui: custom attr in attributes widget * d2f2fc5addc0634b24ccda7a5aae1ed1d3c6001a webui: attr widget: get list of possible attrs from ipapermdefaultattr * 8fcf6d6b34400c1924f509701856b86e4f647624 webui: option_widget_base: sort options -- Petr Vobornik From pvoborni at redhat.com Mon Jul 21 10:31:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 12:31:13 +0200 Subject: [Freeipa-devel] [PATCH] 703-707 webui: improvements in permission details page In-Reply-To: <53C8495C.2020201@redhat.com> References: <53BE8933.80506@redhat.com> <53C8495C.2020201@redhat.com> Message-ID: <53CCEBF1.20305@redhat.com> On 18.7.2014 00:08, Endi Sukma Dewata wrote: > ACK. See comment below: pushed to: master: * 1a904708cc68f742a19036224b267d92644968fc webui: reflect readonly state * e60cfa28626d7e224e2b4aebbe8af8e3fdf1d1c0 webui: fix add of input group class * 75a96fb4c2f58d9ad54a374136afa656ac9a737e webui: show managed fields as readonly and not disabled * 62ac6edcf42d0b736a4363aad0593dc70832ace2 webui: fix selection of empty value in a select widget * 8ba75506c2a9b7deae32d17b4e878de005b98a31 webui: disable ipapermbindruletype if permission in a privilege ipa-4-1: * 1a904708cc68f742a19036224b267d92644968fc webui: reflect readonly state * e60cfa28626d7e224e2b4aebbe8af8e3fdf1d1c0 webui: fix add of input group class * 75a96fb4c2f58d9ad54a374136afa656ac9a737e webui: show managed fields as readonly and not disabled * 62ac6edcf42d0b736a4363aad0593dc70832ace2 webui: fix selection of empty value in a select widget * 8ba75506c2a9b7deae32d17b4e878de005b98a31 webui: disable ipapermbindruletype if permission in a privilege ipa-4-0: * 1a904708cc68f742a19036224b267d92644968fc webui: reflect readonly state * e60cfa28626d7e224e2b4aebbe8af8e3fdf1d1c0 webui: fix add of input group class * 75a96fb4c2f58d9ad54a374136afa656ac9a737e webui: show managed fields as readonly and not disabled * 62ac6edcf42d0b736a4363aad0593dc70832ace2 webui: fix selection of empty value in a select widget * 8ba75506c2a9b7deae32d17b4e878de005b98a31 webui: disable ipapermbindruletype if permission in a privilege > > On 7/10/2014 7:38 AM, Petr Vobornik wrote: >> == [PATCH] 707 webui: disable ipapermbindruletype if permission in a >> privilege == >> >> User is not able to change Bind Rule Type if permission is already >> member of a privilege. Let's disable it and don't confuse user. > > If you open a permission, go to the Privileges tab, add/remove a > privilege, then go back to the Settings tab, the Bind rule type is not > updated automatically, you'd have to click Refresh to see the change. > -- Petr Vobornik From pvoborni at redhat.com Mon Jul 21 10:40:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 12:40:44 +0200 Subject: [Freeipa-devel] [PATCH] 708 webui: fix disabled state of service's PAC type In-Reply-To: <53C8498D.5050801@redhat.com> References: <53BE895E.4090306@redhat.com> <53C8498D.5050801@redhat.com> Message-ID: <53CCEE2C.5040402@redhat.com> On 18.7.2014 00:09, Endi Sukma Dewata wrote: > On 7/10/2014 7:38 AM, Petr Vobornik wrote: >> Nested options (MS-PAC and PAD) of service's PAC type should be >> disabled if no value is supplied (default value is "Inherited >> from server configuration"). That was not the case - regression. >> >> This patch fixes it and along with it simplifies the update method >> of option_widget_base to be more comprehensible. > > ACK. > Pushed to: master: ad593a5c06d447006f14446cbdfbf5b437a0d111 ipa-4-0: ad593a5c06d447006f14446cbdfbf5b437a0d111 ipa-4-1: ad593a5c06d447006f14446cbdfbf5b437a0d111 -- Petr Vobornik From pvoborni at redhat.com Mon Jul 21 11:35:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 13:35:27 +0200 Subject: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights In-Reply-To: <53C8482E.6020806@redhat.com> References: <53BE85DC.5070207@redhat.com> <53C8482E.6020806@redhat.com> Message-ID: <53CCFAFF.8040306@redhat.com> On 18.7.2014 00:03, Endi Sukma Dewata wrote: > On 7/10/2014 7:23 AM, Petr Vobornik wrote: >> Reproduction: >> * add 'extensibleObject' object class to target object >> >> https://fedorahosted.org/freeipa/ticket/4380 > > This is the original if-condition: > > (!rights > && !(that.flags.indexOf('w_if_no_aci') > -1 > && write_oc)) > || (rights && rights.indexOf('w') < 0) > > Here if 'rights' has a value but there's no 'w' in it, the expression > will evaluate to true. > > This is the new code: > > !can_write > && !rights > && !(that.flags.indexOf('w_if_no_aci') > -1 && write_oc) > > Here if 'rights' has any value the expression will evaluate to false. Is > this correct? > You're right, there is an error. Attaching new version. The code is rewritten to be more comprehensible - use cases are in separate variables. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0696-1-webui-support-wildcard-attribute-level-rights.patch Type: text/x-patch Size: 2681 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jul 21 11:51:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 13:51:41 +0200 Subject: [Freeipa-devel] [PATCH] 709 webui: fix nested items creation in dropdown list Message-ID: <53CCFECD.2080208@redhat.com> Items nested in other items were created in root list instead of nested list. Note: this feature is not used in current UI but it's likely to be used by a plugin -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0709-webui-fix-nested-items-creation-in-dropdown-list.patch Type: text/x-patch Size: 2480 bytes Desc: not available URL: From mbasti at redhat.com Mon Jul 21 14:03:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 21 Jul 2014 16:03:56 +0200 Subject: [Freeipa-devel] [PATCH][WIP] 0102 DNSSEC: IPA Install Message-ID: <53CD1DCC.7020102@redhat.com> Notes: 1. To test, please install IPA in following way: * ipa-server-install (do not install with DNS otherwise [2]) * ipa-dns-install * ipa-dnssec-setmaster 2. Service ipa-dnskeysyncd is not implemented yet, please remove "EnabledService" from if ipactl start doesnt work DN: cn=DNSKeySync,cn=example.com,cn=masters,cn=ipa,cn=etc,dc=example.dc=com 3. Requires softhsm2 4. real key generating is not implemented, this is only preview. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-WIP-0102-DNSSEC-IPA-instalation.patch Type: text/x-patch Size: 66972 bytes Desc: not available URL: From dkupka at redhat.com Mon Jul 21 14:08:36 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 21 Jul 2014 16:08:36 +0200 Subject: [Freeipa-devel] [PATCH] Always record that pkicreate has been executed Message-ID: <53CD1EE4.70604@redhat.com> https://fedorahosted.org/freeipa/ticket/2796 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0004-Always-record-that-pkicreate-has-been-executed.patch Type: text/x-patch Size: 2344 bytes Desc: not available URL: From dkupka at redhat.com Mon Jul 21 14:08:55 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 21 Jul 2014 16:08:55 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check In-Reply-To: <53C8FC5C.9030803@redhat.com> References: <53C8F7FD.9030200@redhat.com> <53C8FC5C.9030803@redhat.com> Message-ID: <53CD1EF7.9020501@redhat.com> On 07/18/2014 12:52 PM, Martin Kosek wrote: > On 07/18/2014 12:33 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/2796 > > 1) Would it be easier/more convenient to just implement following simple check > instead of bad_prefix/bad_suffix? > > if password.strip() != password: > raise ValueError('Password must not start or end with whitespace') > Yes it would. Edited patch attached. > > 2) The main goal of the ticket 2796 was not fixed yet. It sometimes happen that > when installation crashes somewhere right after pkicreate, it does not record > and and does not uninstall the PKI component during "ipa-server-install > --uninstall". > > You may artificially invoke some crash in cainstance.py after pkicreate to test > it. When fixing it, check how is_configured() in Service object works an how > self.backup_state is called in other service modules (like dsinstance.py) where > the detection works correctly. You're completely right, Martin. I was unable to reproduce the bug (to force pkicreate/pkispawn to fail) so I thought that it was fixed by the password restriction. Then I discovered that most of the banned characters for password are no longer causing troubles a focused on this. But it's yet another issue. > > Martin > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0002-2-Improve-password-validity-check.patch Type: text/x-patch Size: 2731 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jul 21 14:39:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 21 Jul 2014 16:39:36 +0200 Subject: [Freeipa-devel] [PATCH 0058] Fix login password expiration detection with OTP In-Reply-To: <1405364488.3058.4.camel@ipa.example.com> References: <1405364488.3058.4.camel@ipa.example.com> Message-ID: <53CD2628.50008@redhat.com> On 14.7.2014 21:01, Nathaniel McCallum wrote: > The preexisting code would execute two steps. First, it would perform a > kinit. If the kinit failed, it would attempt to bind using the same > credentials to determine if the password were expired. While this method > is fairly ugly, it mostly worked in the past. > > However, with OTP this breaks. This is because the OTP code is consumed > by the kinit step. But because the password is expired, the kinit step > fails. When the bind is executed, the OTP token is already consumed, so > bind fails. This causes all password expirations to be reported as > invalid credentials. > > After discussion with MIT, the best way to handle this case with the > standard tools is to set LC_ALL=C and check the output from the command. > This eliminates the bind step altogether. The end result is that OTP > works and all password failures are more performant. > > https://fedorahosted.org/freeipa/ticket/4412 > > ACK Pushed to: master: e4771302812388cc7f9773ce48d0bc3b34855248 ipa-4-1: e4771302812388cc7f9773ce48d0bc3b34855248 ipa-4-0: e4771302812388cc7f9773ce48d0bc3b34855248 Initially, when testing, I got preauthentication error because I had old version of krb5: 1.11.5-4 instead of 1.11.5-5. Should we add version dependency >= 1.11.5-5 to spec file? -- Petr Vobornik From npmccallum at redhat.com Mon Jul 21 14:50:25 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 21 Jul 2014 10:50:25 -0400 Subject: [Freeipa-devel] [PATCH 0058] Fix login password expiration detection with OTP In-Reply-To: <53CD2628.50008@redhat.com> References: <1405364488.3058.4.camel@ipa.example.com> <53CD2628.50008@redhat.com> Message-ID: <1405954225.2970.9.camel@ipa.example.com> On Mon, 2014-07-21 at 16:39 +0200, Petr Vobornik wrote: > On 14.7.2014 21:01, Nathaniel McCallum wrote: > > The preexisting code would execute two steps. First, it would perform a > > kinit. If the kinit failed, it would attempt to bind using the same > > credentials to determine if the password were expired. While this method > > is fairly ugly, it mostly worked in the past. > > > > However, with OTP this breaks. This is because the OTP code is consumed > > by the kinit step. But because the password is expired, the kinit step > > fails. When the bind is executed, the OTP token is already consumed, so > > bind fails. This causes all password expirations to be reported as > > invalid credentials. > > > > After discussion with MIT, the best way to handle this case with the > > standard tools is to set LC_ALL=C and check the output from the command. > > This eliminates the bind step altogether. The end result is that OTP > > works and all password failures are more performant. > > > > https://fedorahosted.org/freeipa/ticket/4412 > > > > > > ACK > > Pushed to: > master: e4771302812388cc7f9773ce48d0bc3b34855248 > ipa-4-1: e4771302812388cc7f9773ce48d0bc3b34855248 > ipa-4-0: e4771302812388cc7f9773ce48d0bc3b34855248 > > Initially, when testing, I got preauthentication error because I had old > version of krb5: 1.11.5-4 instead of 1.11.5-5. > > Should we add version dependency >= 1.11.5-5 to spec file? I would guess: yes. From npmccallum at redhat.com Mon Jul 21 16:35:47 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 21 Jul 2014 12:35:47 -0400 Subject: [Freeipa-devel] [PATCH 0059] Update freeipa-server krb5-server dependency to 1.11.5-5 Message-ID: <1405960547.2970.17.camel@ipa.example.com> Previous versions of libkrb5 can't handle expired passwords inside the FAST tunnel. This breaks the password change UI in FreeIPA. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0059-Update-freeipa-server-krb5-server-dependency-to-1.11.patch Type: text/x-patch Size: 948 bytes Desc: not available URL: From mkosek at redhat.com Tue Jul 22 06:36:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Jul 2014 08:36:58 +0200 Subject: [Freeipa-devel] [PATCH 0059] Update freeipa-server krb5-server dependency to 1.11.5-5 In-Reply-To: <1405960547.2970.17.camel@ipa.example.com> References: <1405960547.2970.17.camel@ipa.example.com> Message-ID: <53CE068A.3030300@redhat.com> On 07/21/2014 06:35 PM, Nathaniel McCallum wrote: > Previous versions of libkrb5 can't handle expired passwords > inside the FAST tunnel. This breaks the password change UI > in FreeIPA. ACK, this was easy. Pushed to: master: 53c8efe62f5de1bd48fbdf7bef3fa31debe81de3 ipa-4-1: 53c8efe62f5de1bd48fbdf7bef3fa31debe81de3 ipa-4-0: 53c8efe62f5de1bd48fbdf7bef3fa31debe81de3 Martin From mkosek at redhat.com Tue Jul 22 06:55:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Jul 2014 08:55:21 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check In-Reply-To: <53CD1EF7.9020501@redhat.com> References: <53C8F7FD.9030200@redhat.com> <53C8FC5C.9030803@redhat.com> <53CD1EF7.9020501@redhat.com> Message-ID: <53CE0AD9.4040404@redhat.com> On 07/21/2014 04:08 PM, David Kupka wrote: > On 07/18/2014 12:52 PM, Martin Kosek wrote: >> On 07/18/2014 12:33 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/2796 >> >> 1) Would it be easier/more convenient to just implement following simple check >> instead of bad_prefix/bad_suffix? >> >> if password.strip() != password: >> raise ValueError('Password must not start or end with whitespace') >> > > Yes it would. Edited patch attached. > >> >> 2) The main goal of the ticket 2796 was not fixed yet. It sometimes happen that >> when installation crashes somewhere right after pkicreate, it does not record >> and and does not uninstall the PKI component during "ipa-server-install >> --uninstall". >> >> You may artificially invoke some crash in cainstance.py after pkicreate to test >> it. When fixing it, check how is_configured() in Service object works an how >> self.backup_state is called in other service modules (like dsinstance.py) where >> the detection works correctly. > > You're completely right, Martin. I was unable to reproduce the bug (to force > pkicreate/pkispawn to fail) so I thought that it was fixed by the password > restriction. > Then I discovered that most of the banned characters for password are no longer > causing troubles a focused on this. But it's yet another issue. 1) Whitespace error: $ git am /tmp/freeipa-dkupka-0002-2-Improve-password-validity-check.patch Applying: Improve password validity check. /home/mkosek/freeipa/.git/rebase-apply/patch:25: trailing whitespace. # Disallow leading/trailing whaitespaces warning: 1 line adds whitespace errors. 2) The new admin validator is not applied to "-a" command line option and you can pass any garbage to it. You need to replace this section: if options.admin_password is not None and len(options.admin_password) < 8: parser.error("Admin user password must be at least 8 characters long") ... with the new validator just like we validate DM password. Martin From mkosek at redhat.com Tue Jul 22 07:04:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Jul 2014 09:04:48 +0200 Subject: [Freeipa-devel] [PATCH] Always record that pkicreate has been executed In-Reply-To: <53CD1EE4.70604@redhat.com> References: <53CD1EE4.70604@redhat.com> Message-ID: <53CE0D10.3060301@redhat.com> On 07/21/2014 04:08 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/2796 This works fine. It will help us remove some user frustration when stuck with partially installed Dogtag (JFTR, the cure is "pkidestroy -s CA -i pki-tomcat"). ACK. Pushed to: master: 41b057e38757c0acf1d600245269851f532df389 ipa-4-1: 41b057e38757c0acf1d600245269851f532df389 ipa-4-0: 41b057e38757c0acf1d600245269851f532df389 Martin From mkosek at redhat.com Tue Jul 22 09:01:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Jul 2014 11:01:03 +0200 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid In-Reply-To: <53ABDC43.9050904@redhat.com> References: <53ABDC43.9050904@redhat.com> Message-ID: <53CE284F.30106@redhat.com> On 06/26/2014 10:39 AM, Martin Kosek wrote: > On 06/26/2014 07:28 AM, James wrote: >> I think it's kind of funny that the cert for: https://www.freeipa.org/ >> is invalid, particularly since this is a security product. >> >> In any case, feel free to forward to whoever maintains this in case >> someone thinks it matters. >> >> Cheers, >> James > > You are of course right. Given that OpenShift (where the wiki is running) now > supports certificates for aliases, it is possible to configure the certificate. > > I have started the machinery, stay tuned. > > Thanks, > Martin To update this thread, note that https://www.freeipa.org is now secured with a valid certificate. https://freeipa.org is NOT secured with a valid certificate as this is routed via external server which redirects all requests to "www.freeipa.org". This is required as OpenShift application node A/AAAA records can change and we need to always point to the CNAME (wiki-freeipaorg.rhcloud.com). Given that DNS zone record (freeipa.org) cannot contain CNAME record, we are stuck with this external redirector. Long story short, this one will take more time to solve. Martin From rcritten at redhat.com Tue Jul 22 13:21:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jul 2014 09:21:48 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53B5D0B1.7070706@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> Message-ID: <53CE656C.1060909@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> On 2.7.2014 19:37, Jan Cholasta wrote: >>> On 2.7.2014 19:08, Rob Crittenden wrote: >>>> Trimming to respond to your questions. >>>>>> Not sure if this is related: >>>>>> # pki cert-find >>>>>> PKIException: Internal Server Error >>>> >>>> I'm pretty sure the cert-find error is related to the fact that I had a >>>> test build of dogtag installed, so that can be ignored. >>> >>> It does not work for me as well, with the current F20 dogtag packages, >>> but like I said, it worked some time ago. >> >> Still haven't figured this out, unfortunately. >> >> Added patches 304 and 305 to fix /etc/ipa/ca.crt not having all the CA >> certificates on master. >> >> Updated rebased patches attached. The correct order to apply is 295-294, >> 303-305, 295-299. >> > > 251 I'm a little confused about the profile names. I see you changed the > renewal profile from ipaCACertRenewal to caCACert which I guess makes > sense. I don't see a ipaCACertRenewal profile. There is still a > reference to a ipaRetrieval profile, what is that? > > ACK to the changes in 291 > > 299 I guess you added the check for existing certs to avoid conflicts? I > guess it means that a user is hosed if they chose the same name for > their CA that we use? I think you're missing a sys.exit(1) here. > > 303 Looks good. The man page is still a little thin > > 304 Not to be too pedantic but if removing the old CACERT fails > (SELinux, immutable file) then the install will blow up and this is the > very end. I think the removal should happen earlier, before anything > else happens. That way at least you don't wait 10 minuts to find out the > install failed. > > 305 ACK > > I didn't have a ton of time to test but a basic install fails with: > > 2014-07-03T21:44:49Z DEBUG stderr= > 2014-07-03T21:44:49Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 640, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1046, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 489, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 382, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1041, in __import_ca_chain > (rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 79, in get_cert_nickname > nsscert = x509.load_certificate(cert) > > File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 119, in > load_certificate > return nss.Certificate(buffer(data)) > > 2014-07-03T21:44:49Z DEBUG The ipa-server-install command failed, > exception: NSPRError: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are > attempting to import a cert with the same issuer/serial as an existing > cert, but that is not the same cert. I haven't gotten much further than this. I spent some time trying to find the a change that would cause it and came up empty. Once this bug shows, it always shows, but it can go away at times too which is just blowing my little mind. For example, I tried rolling the patches back one at a time (revert, build, install, repeat). It failed even back to the point where I knew things should be working. I installed 3.3.5, then tried the current build, which had failed before, and it worked. So there is some odd transient thing going on that I can't wrap my head around. rob From mkosek at redhat.com Tue Jul 22 15:01:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Jul 2014 17:01:54 +0200 Subject: [Freeipa-devel] #4450: how to allow password migration? Message-ID: <53CE7CE2.20205@redhat.com> Hello, I was thinking more about the solution to fix migration in FreeIPA 4.0 as proposed in https://fedorahosted.org/freeipa/ticket/4450#comment:6 and I realized it will be more complicated. Conditionally enabling nsslapd-allow-hashed-passwords in cn=config when migration mode is enabled is tricky as this setting is not replicated, compared to ipamigrationenabled. So enabling the migration on one server would still leave it broken on other servers. The same applies for disabling it again. Any ideas how to solve the issue? I am thinking we may need to unconditionally enable this cn=config setting for now to unblock migration (thus effectively revert https://fedorahosted.org/389/ticket/47389). Any other solution I can think of would be too complicated. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From sbose at redhat.com Tue Jul 22 15:24:51 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 22 Jul 2014 17:24:51 +0200 Subject: [Freeipa-devel] [PATCH] 129 ipa-kdb: fix unit tests Message-ID: <20140722152451.GS2158@localhost.localdomain> Hi, it looks like the ipa-kdb unit test is broken. This patch tries to fix it. bye, Sumit -------------- next part -------------- From 5de7f5790d895251c7a22b6af804ac5c61c553c4 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 22 Jul 2014 17:17:45 +0200 Subject: [PATCH] ipa-kdb: fix unit tests --- daemons/ipa-kdb/Makefile.am | 1 + daemons/ipa-kdb/tests/ipa_kdb_tests.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am index b3d6a1b5eaaebbbd1dd01126901bcf01c5dcd10f..80747491f8315a9cb0b38965423ba5d160946278 100644 --- a/daemons/ipa-kdb/Makefile.am +++ b/daemons/ipa-kdb/Makefile.am @@ -79,6 +79,7 @@ ipa_kdb_tests_LDADD = \ $(KRB5_LIBS) \ $(LDAP_LIBS) \ $(NDRPAC_LIBS) \ + $(UNISTRING_LIBS) \ $(NSS_LIBS) \ -lkdb5 \ -lsss_idmap \ diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index fbee4acdbe8d6426664aef8e2d826ef6c065a514..e1ae06a6e359e65873241116581f028f1a4e1bf3 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -174,7 +174,9 @@ START_TEST(test_get_authz_data_types) for (c = 0; test_set[c].authz_data != NULL || test_set[c].global_authz_data != NULL; c++) { ied->authz_data = test_set[c].authz_data; - ipa_ctx->authz_data = test_set[c].global_authz_data; + ipa_ctx->config.authz_data = test_set[c].global_authz_data; + /* Set last_update to avoid LDAP lookups during tests */ + ipa_ctx->config.last_update = time(NULL); entry->princ = test_set[c].princ; get_authz_data_types(krb5_ctx, entry, &with_pac, &with_pad); fail_unless(with_pad == test_set[c].exp_with_pad, "with_pad not %s %s.", -- 1.8.5.3 From redhatrises at gmail.com Tue Jul 22 23:01:02 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 22 Jul 2014 17:01:02 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53CCCFD2.3040306@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> Message-ID: Forgot about --trust-secret. Here is an updated patch. On Mon, Jul 21, 2014 at 2:31 AM, Jan Cholasta wrote: > On 21.7.2014 10:28, Martin Kosek wrote: > >> On 07/21/2014 09:56 AM, Jan Cholasta wrote: >> >>> Hi, >>> >>> On 16.7.2014 05:48, Gabe Alford wrote: >>> >>>> Hello, >>>> >>>> Adds AD admin and password to interactive commands. >>>> https://fedorahosted.org/freeipa/ticket/3034 >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>> >>> I think that instead of making the parameters mandatory, you should >>> instead set >>> alwaysask=True on them. >>> >>> Honza >>> >>> >> Trust can be established either with user+password options OR with >> --trust-secret option - i.e. you cannot use mandatory options nor >> alwaysask. >> > > Ah, right. > > > >> This would rather lead to interactive_prompt_callback checking if any of >> authentication method is passed and asking for them if they aren't. >> > > +1 > > >> Martin >> >> > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0024-2-ipa-trust-add-command-should-be-interactive.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: From lkrispen at redhat.com Wed Jul 23 06:42:02 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 23 Jul 2014 08:42:02 +0200 Subject: [Freeipa-devel] #4450: how to allow password migration? In-Reply-To: <53CE7CE2.20205@redhat.com> References: <53CE7CE2.20205@redhat.com> Message-ID: <53CF593A.20903@redhat.com> On 07/22/2014 05:01 PM, Martin Kosek wrote: > Hello, > > I was thinking more about the solution to fix migration in FreeIPA 4.0 as > proposed in > https://fedorahosted.org/freeipa/ticket/4450#comment:6 > and I realized it will be more complicated. > > Conditionally enabling nsslapd-allow-hashed-passwords in cn=config when > migration mode is enabled is tricky as this setting is not replicated, compared > to ipamigrationenabled. > > So enabling the migration on one server would still leave it broken on other > servers. The same applies for disabling it again. > > Any ideas how to solve the issue? I am thinking we may need to unconditionally > enable this cn=config setting for now to unblock migration (thus effectively > revert https://fedorahosted.org/389/ticket/47389). Any other solution I can > think of would be too complicated. if you alwayys enable it, you would have the same behaviour as before #47389 (which you see as a regression), so it should be ok. Ludwig Thanks. From jcholast at redhat.com Wed Jul 23 07:18:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 09:18:03 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> Message-ID: <53CF61AB.7080706@redhat.com> On 23.7.2014 01:01, Gabe Alford wrote: > Forgot about --trust-secret. Here is an updated patch. > > > On Mon, Jul 21, 2014 at 2:31 AM, Jan Cholasta > wrote: > > On 21.7.2014 10:28, Martin Kosek wrote: > > On 07/21/2014 09:56 AM, Jan Cholasta wrote: > > Hi, > > On 16.7.2014 05:48, Gabe Alford wrote: > > Hello, > > Adds AD admin and password to interactive commands. > https://fedorahosted.org/__freeipa/ticket/3034 > > > Thanks, > > Gabe > > > I think that instead of making the parameters mandatory, you > should instead set > alwaysask=True on them. > > Honza > > > Trust can be established either with user+password options OR with > --trust-secret option - i.e. you cannot use mandatory options > nor alwaysask. > > > Ah, right. > > > > This would rather lead to interactive_prompt_callback checking > if any of > authentication method is passed and asking for them if they aren't. > > > +1 > > > Martin > > > > -- > Jan Cholasta > > I don't think using an extra function to update a value in a dictionary is very beneficial, is there a reason not to use "kw[X] = self.prompt_param(self.params[X])" directly? -- Jan Cholasta From dkupka at redhat.com Wed Jul 23 07:56:21 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 23 Jul 2014 09:56:21 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API Message-ID: <53CF6AA5.7040909@redhat.com> While solving ticket #4280 I noticed that we are messing with certmonger's files right under its hands. That can lead to some unpleasant race condition issues. Is there any reason why not to call certmonger via DBus and ask it to stop tracking the requests? -- David Kupka From mkosek at redhat.com Wed Jul 23 08:12:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 10:12:39 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF6AA5.7040909@redhat.com> References: <53CF6AA5.7040909@redhat.com> Message-ID: <53CF6E77.5000101@redhat.com> On 07/23/2014 09:56 AM, David Kupka wrote: > While solving ticket #4280 I noticed that we are messing with certmonger's > files right under its hands. That can lead to some unpleasant race condition > issues. > Is there any reason why not to call certmonger via DBus and ask it to stop > tracking the requests? +1 for using the dbus API. When I saw the hacky way of parsing certmonger internal configuration files in ipapython/certmonger.py, I suggested the dbus way as IMO it would not be difficult to implement, it would make us more future proof and it would remove intermittent problems like #4280. Certmonger API looked complete enough to pull this off: https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt If I am wrong, please tell me. Thanks, Martin From jcholast at redhat.com Wed Jul 23 08:33:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 10:33:24 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF6E77.5000101@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> Message-ID: <53CF7354.6000305@redhat.com> On 23.7.2014 10:12, Martin Kosek wrote: > On 07/23/2014 09:56 AM, David Kupka wrote: >> While solving ticket #4280 I noticed that we are messing with certmonger's >> files right under its hands. That can lead to some unpleasant race condition >> issues. >> Is there any reason why not to call certmonger via DBus and ask it to stop >> tracking the requests? > > +1 for using the dbus API. When I saw the hacky way of parsing certmonger > internal configuration files in ipapython/certmonger.py, I suggested the dbus > way as IMO it would not be difficult to implement, it would make us more future > proof and it would remove intermittent problems like #4280. I have already started using the API, e.g. for adding/removing of the CA helper in cainstance. Word of warning, the API apparently does not exercised much and there might be bugs (I found one causing certmonger to segfault which Nalin promptly fixed). > > Certmonger API looked complete enough to pull this off: > https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt > > If I am wrong, please tell me. IIRC some of the properties in requests might not be accessible using the API. But I'm not sure if this is true or if it affects us. > > Thanks, > Martin -- Jan Cholasta From abokovoy at redhat.com Wed Jul 23 08:32:52 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Jul 2014 11:32:52 +0300 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF6E77.5000101@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> Message-ID: <20140723083252.GB1659@redhat.com> On Wed, 23 Jul 2014, Martin Kosek wrote: >On 07/23/2014 09:56 AM, David Kupka wrote: >> While solving ticket #4280 I noticed that we are messing with certmonger's >> files right under its hands. That can lead to some unpleasant race condition >> issues. >> Is there any reason why not to call certmonger via DBus and ask it to stop >> tracking the requests? > >+1 for using the dbus API. When I saw the hacky way of parsing certmonger >internal configuration files in ipapython/certmonger.py, I suggested the dbus >way as IMO it would not be difficult to implement, it would make us more future >proof and it would remove intermittent problems like #4280. > >Certmonger API looked complete enough to pull this off: >https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt > >If I am wrong, please tell me. Were there DBus Python bindings available in RHEL 5/6 at the time when the code was written? Anyway, it looks good target to rewrite this code to use DBus these days. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jul 23 08:38:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 10:38:39 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF7354.6000305@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <53CF7354.6000305@redhat.com> Message-ID: <53CF748F.8000506@redhat.com> On 07/23/2014 10:33 AM, Jan Cholasta wrote: > On 23.7.2014 10:12, Martin Kosek wrote: >> On 07/23/2014 09:56 AM, David Kupka wrote: >>> While solving ticket #4280 I noticed that we are messing with certmonger's >>> files right under its hands. That can lead to some unpleasant race condition >>> issues. >>> Is there any reason why not to call certmonger via DBus and ask it to stop >>> tracking the requests? >> >> +1 for using the dbus API. When I saw the hacky way of parsing certmonger >> internal configuration files in ipapython/certmonger.py, I suggested the dbus >> way as IMO it would not be difficult to implement, it would make us more future >> proof and it would remove intermittent problems like #4280. > > I have already started using the API, e.g. for adding/removing of the CA helper > in cainstance. Word of warning, the API apparently does not exercised much and > there might be bugs (I found one causing certmonger to segfault which Nalin > promptly fixed). Yup, this is the place where the inspiration came from :-) >> Certmonger API looked complete enough to pull this off: >> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >> >> If I am wrong, please tell me. > > IIRC some of the properties in requests might not be accessible using the API. > But I'm not sure if this is true or if it affects us. I did couple tests and it seems that getting properties works fine: >>> import dbus >>> bus = dbus.SystemBus() >>> obj = bus.get_object('org.fedorahosted.certmonger','/org/fedorahosted/certmonger') >>> iface = dbus.Interface(obj, 'org.fedorahosted.certmonger') >>> reqs = iface.get_requests() >>> req = bus.get_object('org.fedorahosted.certmonger', reqs[0]) >>> iface_request = dbus.Interface(req, 'org.fedorahosted.certmonger.request') >>> iface_request.get_nickname() dbus.String(u'20140723081859') >>> iface_request.get_status() (dbus.String(u'MONITORING'), dbus.Boolean(False)) >>> iface_request.get_key_storage_info() (dbus.String(u'NSSDB'), dbus.String(u'/etc/pki/pki-tomcat/alias'), dbus.String(u'auditSigningCert cert-pki-ca'), dbus.String(u'NSS Certificate DB')) >>> iface_request.get_cert_data() dbus.String(u'-----BEGIN CERTIFICATE-----\nMIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRNS09T\r\nRUstRkVET1JBMjAuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5\r\nMB4XDTE0MDcyMzA4MTc1OVoXDTE2MDcxMjA4MTc1OVowMjEdMBsGA1UECgwUTUtP\r\nU0VLLUZFRE9SQTIwLlRFU1QxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG\r\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxHJ6iNEUOCLybjMsuC1X3ojJFDml91caAT6u\r\nvySSnz6S79Y2Z3CgpnS71p842SukEXtawkBH+4Vzv3EkiT2OEGFMIFPxtg0z6KJw\r\n64Kv7R6qP1N9iW091pSsui8CoypINtvOmdZtop6meqPEcbjqVzYqQxZ2nq4FI1Ed\r\ncPiirF33OkAJQ5CuvzJFotoZ7f7tAisTpUqghCBAr0kg5MtvcjtlB+hysdVWf+rf\r\nCpzsVA1DbXRNdwsZpOv07Lhm1EGIsJZ3/wZszBpycM1H+8mIuTa5mpNpluDHoDrG\r\ne51TzF5F/DQI7ctMoI6CGxPvyPGbammKcID/yDzyePx3XBnCaQIDAQABo3sweTAf\r\nBgNVHSMEGDAWgBQoqt6chwnASMhQa2DwaWvSF9C/GDAOBgNVHQ8BAf8EBAMCBsAw\r\nRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vaXBhLm1rb3Nlay1m\r\nZWRvcmEyMC50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAEDoy8AW\r\nJinIA4pYEDuTYG/mUBJvvaH+XR7a8pZtX0mnWOlS1mbI1gjlkCCBi7t//c2U3Nmx\r\nb+EiG8isXT0urowI3iB! jhOXyweJDF 7+Wa1kN57SRkMeJIhCTBWOVGEBYGA6nUUKb\r\nnULomV9XXE5Bj+yP3IRewe0AYL0Gyk5QnSNLCYUMA+u/oi4i+uloKv3yZd6On0Re\r\nuIVSvmwXNHMKgGPg2cKSu1fd9tZ7qvQo6Vblf/zYp17tg2Vgd/ESeqgclgJs8AaL\r\nRDED3RT0FaOR/6SCTrXTGymmRaAVA6gGCUScyWD+MaKldOu2qDBG32obPiSw9lm8\r\nnxQBR2IlqByyeDA=\n-----END CERTIFICATE-----\n\n') Martin From jcholast at redhat.com Wed Jul 23 08:49:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 10:49:54 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF748F.8000506@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <53CF7354.6000305@redhat.com> <53CF748F.8000506@redhat.com> Message-ID: <53CF7732.4050704@redhat.com> On 23.7.2014 10:38, Martin Kosek wrote: > On 07/23/2014 10:33 AM, Jan Cholasta wrote: >> On 23.7.2014 10:12, Martin Kosek wrote: >>> On 07/23/2014 09:56 AM, David Kupka wrote: >>>> While solving ticket #4280 I noticed that we are messing with certmonger's >>>> files right under its hands. That can lead to some unpleasant race condition >>>> issues. >>>> Is there any reason why not to call certmonger via DBus and ask it to stop >>>> tracking the requests? >>> >>> +1 for using the dbus API. When I saw the hacky way of parsing certmonger >>> internal configuration files in ipapython/certmonger.py, I suggested the dbus >>> way as IMO it would not be difficult to implement, it would make us more future >>> proof and it would remove intermittent problems like #4280. >> >> I have already started using the API, e.g. for adding/removing of the CA helper >> in cainstance. Word of warning, the API apparently does not exercised much and >> there might be bugs (I found one causing certmonger to segfault which Nalin >> promptly fixed). > > Yup, this is the place where the inspiration came from :-) > >>> Certmonger API looked complete enough to pull this off: >>> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >>> >>> If I am wrong, please tell me. >> >> IIRC some of the properties in requests might not be accessible using the API. >> But I'm not sure if this is true or if it affects us. > > I did couple tests and it seems that getting properties works fine: > >>>> import dbus >>>> bus = dbus.SystemBus() >>>> obj = > bus.get_object('org.fedorahosted.certmonger','/org/fedorahosted/certmonger') >>>> iface = dbus.Interface(obj, 'org.fedorahosted.certmonger') >>>> reqs = iface.get_requests() >>>> req = bus.get_object('org.fedorahosted.certmonger', reqs[0]) >>>> iface_request = dbus.Interface(req, 'org.fedorahosted.certmonger.request') >>>> iface_request.get_nickname() > dbus.String(u'20140723081859') >>>> iface_request.get_status() > (dbus.String(u'MONITORING'), dbus.Boolean(False)) >>>> iface_request.get_key_storage_info() > (dbus.String(u'NSSDB'), dbus.String(u'/etc/pki/pki-tomcat/alias'), > dbus.String(u'auditSigningCert cert-pki-ca'), dbus.String(u'NSS Certificate DB')) >>>> iface_request.get_cert_data() > dbus.String(u'-----BEGIN > CERTIFICATE-----\nMIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRNS09T\r\nRUstRkVET1JBMjAuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5\r\nMB4XDTE0MDcyMzA4MTc1OVoXDTE2MDcxMjA4MTc1OVowMjEdMBsGA1UECgwUTUtP\r\nU0VLLUZFRE9SQTIwLlRFU1QxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG\r\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxHJ6iNEUOCLybjMsuC1X3ojJFDml91caAT6u\r\nvySSnz6S79Y2Z3CgpnS71p842SukEXtawkBH+4Vzv3EkiT2OEGFMIFPxtg0z6KJw\r\n64Kv7R6qP1N9iW091pSsui8CoypINtvOmdZtop6meqPEcbjqVzYqQxZ2nq4FI1Ed\r\ncPiirF33OkAJQ5CuvzJFotoZ7f7tAisTpUqghCBAr0kg5MtvcjtlB+hysdVWf+rf\r\nCpzsVA1DbXRNdwsZpOv07Lhm1EGIsJZ3/wZszBpycM1H+8mIuTa5mpNpluDHoDrG\r\ne51TzF5F/DQI7ctMoI6CGxPvyPGbammKcID/yDzyePx3XBnCaQIDAQABo3sweTAf\r\nBgNVHSMEGDAWgBQoqt6chwnASMhQa2DwaWvSF9C/GDAOBgNVHQ8BAf8EBAMCBsAw\r\nRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vaXBhLm1rb3Nlay1m\r\nZWRvcmEyMC50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAEDoy8AW\r\nJinIA4pYEDuTYG/mUBJvvaH+XR7a8pZtX0mnWOlS1mbI1gjlkCCBi7t//c2U3Nmx\r\nb+EiG8isXT0urowI3! iB! > jhOXyweJDF > 7+Wa1kN57SRkMeJIhCTBWOVGEBYGA6nUUKb\r\nnULomV9XXE5Bj+yP3IRewe0AYL0Gyk5QnSNLCYUMA+u/oi4i+uloKv3yZd6On0Re\r\nuIVSvmwXNHMKgGPg2cKSu1fd9tZ7qvQo6Vblf/zYp17tg2Vgd/ESeqgclgJs8AaL\r\nRDED3RT0FaOR/6SCTrXTGymmRaAVA6gGCUScyWD+MaKldOu2qDBG32obPiSw9lm8\r\nnxQBR2IlqByyeDA=\n-----END > CERTIFICATE-----\n\n') > > Martin > When I said "some of the properties", I certainly did not mean the absolute basics, but rather stuff like "cert-presave-command". -- Jan Cholasta From pspacek at redhat.com Wed Jul 23 09:14:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Jul 2014 11:14:06 +0200 Subject: [Freeipa-devel] Ipsilon vs. FedOAuth Message-ID: <53CF7CDE.5070509@redhat.com> Hello list, I have noticed that Fedora is heavily using project FedOAuth: Federated Open Authentication "FedOAuth is a provider for federated authentication mechanisms with a modular authentication backend." It sounds somewhat similar to our Ipsilon project and it is also written in Python. Maybe it would be beneficial to somehow cooperate ... -- Petr^2 Spacek From mkosek at redhat.com Wed Jul 23 10:23:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 12:23:00 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF7732.4050704@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <53CF7354.6000305@redhat.com> <53CF748F.8000506@redhat.com> <53CF7732.4050704@redhat.com> Message-ID: <53CF8D04.3010301@redhat.com> On 07/23/2014 10:49 AM, Jan Cholasta wrote: > On 23.7.2014 10:38, Martin Kosek wrote: >> On 07/23/2014 10:33 AM, Jan Cholasta wrote: >>> On 23.7.2014 10:12, Martin Kosek wrote: >>>> On 07/23/2014 09:56 AM, David Kupka wrote: >>>>> While solving ticket #4280 I noticed that we are messing with certmonger's >>>>> files right under its hands. That can lead to some unpleasant race condition >>>>> issues. >>>>> Is there any reason why not to call certmonger via DBus and ask it to stop >>>>> tracking the requests? >>>> >>>> +1 for using the dbus API. When I saw the hacky way of parsing certmonger >>>> internal configuration files in ipapython/certmonger.py, I suggested the dbus >>>> way as IMO it would not be difficult to implement, it would make us more >>>> future >>>> proof and it would remove intermittent problems like #4280. >>> >>> I have already started using the API, e.g. for adding/removing of the CA helper >>> in cainstance. Word of warning, the API apparently does not exercised much and >>> there might be bugs (I found one causing certmonger to segfault which Nalin >>> promptly fixed). >> >> Yup, this is the place where the inspiration came from :-) >> >>>> Certmonger API looked complete enough to pull this off: >>>> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >>>> >>>> If I am wrong, please tell me. >>> >>> IIRC some of the properties in requests might not be accessible using the API. >>> But I'm not sure if this is true or if it affects us. >> >> I did couple tests and it seems that getting properties works fine: >> >>>>> import dbus >>>>> bus = dbus.SystemBus() >>>>> obj = >> bus.get_object('org.fedorahosted.certmonger','/org/fedorahosted/certmonger') >>>>> iface = dbus.Interface(obj, 'org.fedorahosted.certmonger') >>>>> reqs = iface.get_requests() >>>>> req = bus.get_object('org.fedorahosted.certmonger', reqs[0]) >>>>> iface_request = dbus.Interface(req, 'org.fedorahosted.certmonger.request') >>>>> iface_request.get_nickname() >> dbus.String(u'20140723081859') >>>>> iface_request.get_status() >> (dbus.String(u'MONITORING'), dbus.Boolean(False)) >>>>> iface_request.get_key_storage_info() >> (dbus.String(u'NSSDB'), dbus.String(u'/etc/pki/pki-tomcat/alias'), >> dbus.String(u'auditSigningCert cert-pki-ca'), dbus.String(u'NSS Certificate >> DB')) >>>>> iface_request.get_cert_data() >> dbus.String(u'-----BEGIN >> CERTIFICATE-----\nMIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRNS09T\r\nRUstRkVET1JBMjAuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5\r\nMB4XDTE0MDcyMzA4MTc1OVoXDTE2MDcxMjA4MTc1OVowMjEdMBsGA1UECgwUTUtP\r\nU0VLLUZFRE9SQTIwLlRFU1QxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG\r\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxHJ6iNEUOCLybjMsuC1X3ojJFDml91caAT6u\r\nvySSnz6S79Y2Z3CgpnS71p842SukEXtawkBH+4Vzv3EkiT2OEGFMIFPxtg0z6KJw\r\n64Kv7R6qP1N9iW091pSsui8CoypINtvOmdZtop6meqPEcbjqVzYqQxZ2nq4FI1Ed\r\ncPiirF33OkAJQ5CuvzJFotoZ7f7tAisTpUqghCBAr0kg5MtvcjtlB+hysdVWf+rf\r\nCpzsVA1DbXRNdwsZpOv07Lhm1EGIsJZ3/wZszBpycM1H+8mIuTa5mpNpluDHoDrG\r\ne51TzF5F/DQI7ctMoI6CGxPvyPGbammKcID/yDzyePx3XBnCaQIDAQABo3sweTAf\r\nBgNVHSMEGDAWgBQoqt6chwnASMhQa2DwaWvSF9C/GDAOBgNVHQ8BAf8EBAMCBsAw\r\nRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vaXBhLm1rb3Nlay1m\r\nZWRvcmEyMC50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAEDoy8AW\r\nJinIA4pYEDuTYG/mUBJvvaH+XR7a8pZtX0mnWOlS1mbI1gjlkCCBi7t//c2U3Nmx\r\nb+EiG8isXT0urowI! 3! >> > iB! >> jhOXyweJDF >> 7+Wa1kN57SRkMeJIhCTBWOVGEBYGA6nUUKb\r\nnULomV9XXE5Bj+yP3IRewe0AYL0Gyk5QnSNLCYUMA+u/oi4i+uloKv3yZd6On0Re\r\nuIVSvmwXNHMKgGPg2cKSu1fd9tZ7qvQo6Vblf/zYp17tg2Vgd/ESeqgclgJs8AaL\r\nRDED3RT0FaOR/6SCTrXTGymmRaAVA6gGCUScyWD+MaKldOu2qDBG32obPiSw9lm8\r\nnxQBR2IlqByyeDA=\n-----END >> >> CERTIFICATE-----\n\n') >> >> Martin >> > > When I said "some of the properties", I certainly did not mean the absolute > basics, but rather stuff like "cert-presave-command". Ah, ok. Then I think this snippet will help: >>> properties_manager = dbus.Interface(req, 'org.freedesktop.DBus.Properties') >>> properties_manager.Get('org.fedorahosted.certmonger.request', 'cert-presave-command') dbus.String(u'/usr/lib64/ipa/certmonger/stop_pkicad') >>> properties_manager.Get('org.fedorahosted.certmonger.request', 'cert-postsave-command') dbus.String(u'/usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"') Martin From jcholast at redhat.com Wed Jul 23 11:09:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 13:09:07 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF8D04.3010301@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <53CF7354.6000305@redhat.com> <53CF748F.8000506@redhat.com> <53CF7732.4050704@redhat.com> <53CF8D04.3010301@redhat.com> Message-ID: <53CF97D3.90001@redhat.com> On 23.7.2014 12:23, Martin Kosek wrote: > On 07/23/2014 10:49 AM, Jan Cholasta wrote: >> On 23.7.2014 10:38, Martin Kosek wrote: >>> On 07/23/2014 10:33 AM, Jan Cholasta wrote: >>>> On 23.7.2014 10:12, Martin Kosek wrote: >>>>> On 07/23/2014 09:56 AM, David Kupka wrote: >>>>>> While solving ticket #4280 I noticed that we are messing with certmonger's >>>>>> files right under its hands. That can lead to some unpleasant race condition >>>>>> issues. >>>>>> Is there any reason why not to call certmonger via DBus and ask it to stop >>>>>> tracking the requests? >>>>> >>>>> +1 for using the dbus API. When I saw the hacky way of parsing certmonger >>>>> internal configuration files in ipapython/certmonger.py, I suggested the dbus >>>>> way as IMO it would not be difficult to implement, it would make us more >>>>> future >>>>> proof and it would remove intermittent problems like #4280. >>>> >>>> I have already started using the API, e.g. for adding/removing of the CA helper >>>> in cainstance. Word of warning, the API apparently does not exercised much and >>>> there might be bugs (I found one causing certmonger to segfault which Nalin >>>> promptly fixed). >>> >>> Yup, this is the place where the inspiration came from :-) >>> >>>>> Certmonger API looked complete enough to pull this off: >>>>> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >>>>> >>>>> If I am wrong, please tell me. >>>> >>>> IIRC some of the properties in requests might not be accessible using the API. >>>> But I'm not sure if this is true or if it affects us. >>> >>> I did couple tests and it seems that getting properties works fine: >>> >>>>>> import dbus >>>>>> bus = dbus.SystemBus() >>>>>> obj = >>> bus.get_object('org.fedorahosted.certmonger','/org/fedorahosted/certmonger') >>>>>> iface = dbus.Interface(obj, 'org.fedorahosted.certmonger') >>>>>> reqs = iface.get_requests() >>>>>> req = bus.get_object('org.fedorahosted.certmonger', reqs[0]) >>>>>> iface_request = dbus.Interface(req, 'org.fedorahosted.certmonger.request') >>>>>> iface_request.get_nickname() >>> dbus.String(u'20140723081859') >>>>>> iface_request.get_status() >>> (dbus.String(u'MONITORING'), dbus.Boolean(False)) >>>>>> iface_request.get_key_storage_info() >>> (dbus.String(u'NSSDB'), dbus.String(u'/etc/pki/pki-tomcat/alias'), >>> dbus.String(u'auditSigningCert cert-pki-ca'), dbus.String(u'NSS Certificate >>> DB')) >>>>>> iface_request.get_cert_data() >>> dbus.String(u'-----BEGIN >>> CERTIFICATE-----\nMIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRNS09T\r\nRUstRkVET1JBMjAuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5\r\nMB4XDTE0MDcyMzA4MTc1OVoXDTE2MDcxMjA4MTc1OVowMjEdMBsGA1UECgwUTUtP\r\nU0VLLUZFRE9SQTIwLlRFU1QxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG\r\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxHJ6iNEUOCLybjMsuC1X3ojJFDml91caAT6u\r\nvySSnz6S79Y2Z3CgpnS71p842SukEXtawkBH+4Vzv3EkiT2OEGFMIFPxtg0z6KJw\r\n64Kv7R6qP1N9iW091pSsui8CoypINtvOmdZtop6meqPEcbjqVzYqQxZ2nq4FI1Ed\r\ncPiirF33OkAJQ5CuvzJFotoZ7f7tAisTpUqghCBAr0kg5MtvcjtlB+hysdVWf+rf\r\nCpzsVA1DbXRNdwsZpOv07Lhm1EGIsJZ3/wZszBpycM1H+8mIuTa5mpNpluDHoDrG\r\ne51TzF5F/DQI7ctMoI6CGxPvyPGbammKcID/yDzyePx3XBnCaQIDAQABo3sweTAf\r\nBgNVHSMEGDAWgBQoqt6chwnASMhQa2DwaWvSF9C/GDAOBgNVHQ8BAf8EBAMCBsAw\r\nRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vaXBhLm1rb3Nlay1m\r\nZWRvcmEyMC50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAEDoy8AW\r\nJinIA4pYEDuTYG/mUBJvvaH+XR7a8pZtX0mnWOlS1mbI1gjlkCCBi7t//c2U3Nmx\r\nb+EiG8isXT0urow! I! > 3! >>> >> iB! >>> jhOXyweJDF >>> 7+Wa1kN57SRkMeJIhCTBWOVGEBYGA6nUUKb\r\nnULomV9XXE5Bj+yP3IRewe0AYL0Gyk5QnSNLCYUMA+u/oi4i+uloKv3yZd6On0Re\r\nuIVSvmwXNHMKgGPg2cKSu1fd9tZ7qvQo6Vblf/zYp17tg2Vgd/ESeqgclgJs8AaL\r\nRDED3RT0FaOR/6SCTrXTGymmRaAVA6gGCUScyWD+MaKldOu2qDBG32obPiSw9lm8\r\nnxQBR2IlqByyeDA=\n-----END >>> >>> CERTIFICATE-----\n\n') >>> >>> Martin >>> >> >> When I said "some of the properties", I certainly did not mean the absolute >> basics, but rather stuff like "cert-presave-command". > > Ah, ok. Then I think this snippet will help: > >>>> properties_manager = dbus.Interface(req, 'org.freedesktop.DBus.Properties') >>>> properties_manager.Get('org.fedorahosted.certmonger.request', > 'cert-presave-command') > dbus.String(u'/usr/lib64/ipa/certmonger/stop_pkicad') >>>> properties_manager.Get('org.fedorahosted.certmonger.request', > 'cert-postsave-command') > dbus.String(u'/usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert > cert-pki-ca"') > > Martin > Nice, I think we are good to go then. -- Jan Cholasta From mkosek at redhat.com Wed Jul 23 11:55:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 13:55:49 +0200 Subject: [Freeipa-devel] [PATCH] 478 Allow hashed passwords in DS Message-ID: <53CFA2C5.5090904@redhat.com> See related thread "#4450: how to allow password migration?" for more information. --- Without nsslapd-allow-hashed-passwords being turned on, user password migration fails. https://fedorahosted.org/freeipa/ticket/4450 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-478-allow-hashed-passwords-in-ds.patch Type: text/x-patch Size: 1899 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 23 12:26:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 14:26:42 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53CE656C.1060909@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> Message-ID: <53CFAA02.9050607@redhat.com> On 22.7.2014 15:21, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 2.7.2014 19:37, Jan Cholasta wrote: >>>> On 2.7.2014 19:08, Rob Crittenden wrote: >>>>> Trimming to respond to your questions. >>>>>>> Not sure if this is related: >>>>>>> # pki cert-find >>>>>>> PKIException: Internal Server Error >>>>> >>>>> I'm pretty sure the cert-find error is related to the fact that I had a >>>>> test build of dogtag installed, so that can be ignored. >>>> >>>> It does not work for me as well, with the current F20 dogtag packages, >>>> but like I said, it worked some time ago. >>> >>> Still haven't figured this out, unfortunately. Fixed. Part of the problem was that the validation code I used on CA certificates was too tolerant (fixed in patches 249 and 251). Another part was the NSS validation code that Dogtag uses requires the issuing CA to be present in the NSS database (fixed in patch 306). Finally, Dogtag uses default NSS certificate path validation, which means you have to either keep all versions of the CA certificate in the NSS database, or enable PKIX path validation in NSS. Certmonger does not like having multiple versions of a certificate it is tracking in the database, so I have gone the PKIX route (patch 307). >>> >>> Added patches 304 and 305 to fix /etc/ipa/ca.crt not having all the CA >>> certificates on master. >>> >>> Updated rebased patches attached. The correct order to apply is 295-294, >>> 303-305, 295-299. >>> >> >> 251 I'm a little confused about the profile names. I see you changed the >> renewal profile from ipaCACertRenewal to caCACert which I guess makes >> sense. I don't see a ipaCACertRenewal profile. There is still a >> reference to a ipaRetrieval profile, what is that? Oops, I forgot to mention that, I guess I shouldn't post patches at such late hour :) Sorry. ipaCACertRenewal should be used only for automatic renewal, not for manual. It calls caCACert and ipaRetrieval internally, but there are some conditions, which don't apply to manual renewal. It's a change I forgot to make before, so I made it now when I noticed it. ipaRetrieval fetches the certificate from cn=ca_renewal, i.e. what dogtag-ipa-retrieve-agent-submit used to do. >> >> ACK to the changes in 291 >> >> 299 I guess you added the check for existing certs to avoid conflicts? I >> guess it means that a user is hosed if they chose the same name for >> their CA that we use? I think you're missing a sys.exit(1) here. Yes. It is a poor man's solution, but it would take time to make something better. (I can deal with nickname conflicts rather easy by renaming the certificates, but handling subject conflict would require removing the old certificate from the certificate store, which is not yet supported.) Fixed missing exit. >> >> 303 Looks good. The man page is still a little thin >> >> 304 Not to be too pedantic but if removing the old CACERT fails >> (SELinux, immutable file) then the install will blow up and this is the >> very end. I think the removal should happen earlier, before anything >> else happens. That way at least you don't wait 10 minuts to find out the >> install failed. I switched to overwriting the file instead. It is created/written a few lines above, so if it shall fail, it will fail there. >> >> 305 ACK >> >> I didn't have a ton of time to test but a basic install fails with: >> >> 2014-07-03T21:44:49Z DEBUG stderr= >> 2014-07-03T21:44:49Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 640, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1046, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 489, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 382, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 1041, in __import_ca_chain >> (rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >> line 79, in get_cert_nickname >> nsscert = x509.load_certificate(cert) >> >> File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 119, in >> load_certificate >> return nss.Certificate(buffer(data)) >> >> 2014-07-03T21:44:49Z DEBUG The ipa-server-install command failed, >> exception: NSPRError: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are >> attempting to import a cert with the same issuer/serial as an existing >> cert, but that is not the same cert. > > I haven't gotten much further than this. I spent some time trying to > find the a change that would cause it and came up empty. Once this bug > shows, it always shows, but it can go away at times too which is just > blowing my little mind. > > For example, I tried rolling the patches back one at a time (revert, > build, install, repeat). It failed even back to the point where I knew > things should be working. I installed 3.3.5, then tried the current > build, which had failed before, and it worked. So there is some odd > transient thing going on that I can't wrap my head around. I have not yet seen this failure myself. It looks like NSS internally imports the certificate, which conflicts with the database NSS is initialized with. Perhaps a well placed nss_shutdown() might fix this? Maybe using NSS contexts instead of global initialization could help. > > rob > I have taken your advice and don't touch trust flags on unknown CA certs on upgrades anymore. I have also made a number of little tweaks. Updated rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.7-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.7-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.7-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.7-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.7-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.7-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.7-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.7-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.7-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 1824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.7-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 3887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.7-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.7-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.7-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.6-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.5-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.5-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.5-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.4-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.4-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.4-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.4-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.4-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 8975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.4-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 3979 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.4-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3439 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.4-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.4-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.4-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 12821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.4-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.4-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.4-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 15471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.4-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.4-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 4282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.4-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.4-Add-new-add_cert-method-for-adding-certificates-to-N.patch Type: text/x-patch Size: 3843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.4-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.4-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.4-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.4-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.4-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.4-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 4357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.4-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.4-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.4-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.4-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.4-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.4-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.4-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296.4-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 4556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297.4-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298.4-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5873 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299.4-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 15881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-303.2-Add-client-certificate-update-tool-ipa-certupdate.patch Type: text/x-patch Size: 12141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-304.1-Export-full-CA-chain-to-etc-ipa-ca.crt-in-ipa-server.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-305.1-Allow-multiple-CA-certificates-in-replica-info-files.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-306-Update-external-CA-cert-in-Dogtag-NSS-DB-on-IPA-CA-c.patch Type: text/x-patch Size: 4211 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-307-Enable-NSS-PKIX-certificate-path-discovery-and-valid.patch Type: text/x-patch Size: 4267 bytes Desc: not available URL: From pspacek at redhat.com Wed Jul 23 12:25:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Jul 2014 14:25:37 +0200 Subject: [Freeipa-devel] [PATCH 0275] Add TLSARecord to idnsRecord object class Message-ID: <53CFA9C1.10303@redhat.com> Hello, Add TLSARecord to idnsRecord object class. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0275-Add-TLSARecord-to-idnsRecord-object-class.patch Type: text/x-patch Size: 877 bytes Desc: not available URL: From pspacek at redhat.com Wed Jul 23 12:26:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Jul 2014 14:26:02 +0200 Subject: [Freeipa-devel] [PATCH 0276] Fix crash during reconnection to LDAP Message-ID: <53CFA9DA.8000606@redhat.com> Hello, Fix crash during reconnection to LDAP. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0276-Fix-crash-during-reconnection-to-LDAP.patch Type: text/x-patch Size: 1288 bytes Desc: not available URL: From pspacek at redhat.com Wed Jul 23 12:27:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Jul 2014 14:27:47 +0200 Subject: [Freeipa-devel] [PATCH 0277] Bump NVR to 5.1 Message-ID: <53CFAA43.60606@redhat.com> Hello, Bump NVR to 5.1. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0277-Bump-NVR-to-5.1.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: From tbabej at redhat.com Wed Jul 23 12:40:23 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Jul 2014 14:40:23 +0200 Subject: [Freeipa-devel] [PATCH 0245] baseldap: Remove redundant search from LDAPAddReverseMember Message-ID: <53CFAD37.7080402@redhat.com> Hi, when poking in the depths of the baseldap, I found this seemingly redundant search. -- 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-0245-baseldap-Remove-redundant-search-from-LDAPAddReverse.patch Type: text/x-patch Size: 1576 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 23 13:03:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 15:03:09 +0200 Subject: [Freeipa-devel] [PATCH 0245] baseldap: Remove redundant search from LDAPAddReverseMember In-Reply-To: <53CFAD37.7080402@redhat.com> References: <53CFAD37.7080402@redhat.com> Message-ID: <53CFB28D.4080603@redhat.com> On 23.7.2014 14:40, Tomas Babej wrote: > Hi, > > when poking in the depths of the baseldap, I found this seemingly > redundant search. ACK. For the record, before commit f1f1b4e the result was used for wait_for_memberof. BTW, I think this bit: # Ensure our target exists result = self.api.Command[self.show_command](keys[-1])['result'] dn = result['dn'] could be optimized to use get_dn_if_exists. -- Jan Cholasta From mbasti at redhat.com Wed Jul 23 13:06:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Jul 2014 15:06:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0102-0103 DNS upgrade: add missing tests if DNS is installed Message-ID: <53CFB366.6090000@redhat.com> This should be applied in 4.0.x, 4.1, master Patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0103-Fix-DNS-upgrade-plugin-should-check-if-DNS-container.patch Type: text/x-patch Size: 1455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0104-FIX-named_enable_dnssec-should-verify-if-DNS-is-inst.patch Type: text/x-patch Size: 1005 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 23 13:13:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 15:13:11 +0200 Subject: [Freeipa-devel] [PATCH 0245] baseldap: Remove redundant search from LDAPAddReverseMember In-Reply-To: <53CFB28D.4080603@redhat.com> References: <53CFAD37.7080402@redhat.com> <53CFB28D.4080603@redhat.com> Message-ID: <53CFB4E7.6000704@redhat.com> On 07/23/2014 03:03 PM, Jan Cholasta wrote: > On 23.7.2014 14:40, Tomas Babej wrote: >> Hi, >> >> when poking in the depths of the baseldap, I found this seemingly >> redundant search. > > ACK. For the record, before commit f1f1b4e the result was used for > wait_for_memberof. Pushed to master, ipa-4-1. Martin From pvoborni at redhat.com Wed Jul 23 13:16:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Jul 2014 15:16:06 +0200 Subject: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session Message-ID: <53CFB596.4080003@redhat.com> Disable automatic re-execution of command after pending authentication. It's possible to enable it again globally by 'freeipa/config':`rpc_retry_auth`. https://fedorahosted.org/freeipa/ticket/4374 # Additional info: This ticket is in 4.0 stabilization milestone. I don't think it's the best fit. It has a potential to break things. It's also harder to test because integration tests don't test it - one has to remove session cookie every time and then react appropriately. It's also first usage of ./config module (other items there are not used). This module was originally implemented to contain global webui config which could be overwritten by config configured on server, ie for disabling paging in large deployments. The server part doesn't exist yet. Other reason is to split ipa.js into more single-purpose files. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0710-webui-review-pending-operation-after-expired-session.patch Type: text/x-patch Size: 3841 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 23 13:17:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Jul 2014 15:17:30 +0200 Subject: [Freeipa-devel] [PATCH] 711 webui: internet explorer fixes Message-ID: <53CFB5EA.7070904@redhat.com> Fixed: 1. IE doesn't support value 'initial' in CSS rule. 2. setting innerHTML='' also destroys content of child nodes in LoginScreen in IE -> reattached buttons have no text. Should go into 4.0 Milestone -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0711-webui-internet-explorer-fixes.patch Type: text/x-patch Size: 1939 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 23 13:17:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Jul 2014 15:17:36 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater Message-ID: <53CFB5F0.7030507@redhat.com> This patch fixes ordering problem of schema updates Martin should it be in IPA 4.0.x ? It requires rebased ldap_python (will be in Fedora 21) Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0105-FIX-ldap_updater-needs-correct-orderng-of-the-update.patch Type: text/x-patch Size: 8339 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 23 13:24:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2014 09:24:30 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF97D3.90001@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <53CF7354.6000305@redhat.com> <53CF748F.8000506@redhat.com> <53CF7732.4050704@redhat.com> <53CF8D04.3010301@redhat.com> <53CF97D3.90001@redhat.com> Message-ID: <53CFB78E.8040304@redhat.com> Jan Cholasta wrote: > On 23.7.2014 12:23, Martin Kosek wrote: >> On 07/23/2014 10:49 AM, Jan Cholasta wrote: >>> On 23.7.2014 10:38, Martin Kosek wrote: >>>> On 07/23/2014 10:33 AM, Jan Cholasta wrote: >>>>> On 23.7.2014 10:12, Martin Kosek wrote: >>>>>> On 07/23/2014 09:56 AM, David Kupka wrote: >>>>>>> While solving ticket #4280 I noticed that we are messing with >>>>>>> certmonger's >>>>>>> files right under its hands. That can lead to some unpleasant >>>>>>> race condition >>>>>>> issues. >>>>>>> Is there any reason why not to call certmonger via DBus and ask >>>>>>> it to stop >>>>>>> tracking the requests? >>>>>> >>>>>> +1 for using the dbus API. When I saw the hacky way of parsing >>>>>> certmonger >>>>>> internal configuration files in ipapython/certmonger.py, I >>>>>> suggested the dbus >>>>>> way as IMO it would not be difficult to implement, it would make >>>>>> us more >>>>>> future >>>>>> proof and it would remove intermittent problems like #4280. >>>>> >>>>> I have already started using the API, e.g. for adding/removing of >>>>> the CA helper >>>>> in cainstance. Word of warning, the API apparently does not >>>>> exercised much and >>>>> there might be bugs (I found one causing certmonger to segfault >>>>> which Nalin >>>>> promptly fixed). >>>> >>>> Yup, this is the place where the inspiration came from :-) >>>> >>>>>> Certmonger API looked complete enough to pull this off: >>>>>> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >>>>>> >>>>>> If I am wrong, please tell me. >>>>> >>>>> IIRC some of the properties in requests might not be accessible >>>>> using the API. >>>>> But I'm not sure if this is true or if it affects us. >>>> >>>> I did couple tests and it seems that getting properties works fine: >>>> >>>>>>> import dbus >>>>>>> bus = dbus.SystemBus() >>>>>>> obj = >>>> bus.get_object('org.fedorahosted.certmonger','/org/fedorahosted/certmonger') >>>> >>>>>>> iface = dbus.Interface(obj, 'org.fedorahosted.certmonger') >>>>>>> reqs = iface.get_requests() >>>>>>> req = bus.get_object('org.fedorahosted.certmonger', reqs[0]) >>>>>>> iface_request = dbus.Interface(req, >>>>>>> 'org.fedorahosted.certmonger.request') >>>>>>> iface_request.get_nickname() >>>> dbus.String(u'20140723081859') >>>>>>> iface_request.get_status() >>>> (dbus.String(u'MONITORING'), dbus.Boolean(False)) >>>>>>> iface_request.get_key_storage_info() >>>> (dbus.String(u'NSSDB'), dbus.String(u'/etc/pki/pki-tomcat/alias'), >>>> dbus.String(u'auditSigningCert cert-pki-ca'), dbus.String(u'NSS >>>> Certificate >>>> DB')) >>>>>>> iface_request.get_cert_data() >>>> dbus.String(u'-----BEGIN >>>> CERTIFICATE-----\nMIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA/MR0wGwYDVQQKDBRNS09T\r\nRUstRkVET1JBMjAuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5\r\nMB4XDTE0MDcyMzA4MTc1OVoXDTE2MDcxMjA4MTc1OVowMjEdMBsGA1UECgwUTUtP\r\nU0VLLUZFRE9SQTIwLlRFU1QxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG\r\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxHJ6iNEUOCLybjMsuC1X3ojJFDml91caAT6u\r\nvySSnz6S79Y2Z3CgpnS71p842SukEXtawkBH+4Vzv3EkiT2OEGFMIFPxtg0z6KJw\r\n64Kv7R6qP1N9iW091pSsui8CoypINtvOmdZtop6meqPEcbjqVzYqQxZ2nq4FI1Ed\r\ncPiirF33OkAJQ5CuvzJFotoZ7f7tAisTpUqghCBAr0kg5MtvcjtlB+hysdVWf+rf\r\nCpzsVA1DbXRNdwsZpOv07Lhm1EGIsJZ3/wZszBpycM1H+8mIuTa5mpNpluDHoDrG\r\ne51TzF5F/DQI7ctMoI6CGxPvyPGbammKcID/yDzyePx3XBnCaQIDAQABo3sweTAf\r\nBgNVHSMEGDAWgBQoqt6chwnASMhQa2DwaWvSF9C/GDAOBgNVHQ8BAf8EBAMCBsAw\r\nRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vaXBhLm1rb3Nlay1m\r\nZWRvcmEyMC50ZXN0OjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAEDoy8AW\r\nJinIA4pYEDuTYG/mUBJvvaH+XR7a8pZtX0mnWOlS1mbI1gjlkCCBi7t//c2U3Nmx\r\nb+EiG8isXT0uro! w! >>>> > I! >> 3! >>>> >>> iB! >>>> jhOXyweJDF >>>> 7+Wa1kN57SRkMeJIhCTBWOVGEBYGA6nUUKb\r\nnULomV9XXE5Bj+yP3IRewe0AYL0Gyk5QnSNLCYUMA+u/oi4i+uloKv3yZd6On0Re\r\nuIVSvmwXNHMKgGPg2cKSu1fd9tZ7qvQo6Vblf/zYp17tg2Vgd/ESeqgclgJs8AaL\r\nRDED3RT0FaOR/6SCTrXTGymmRaAVA6gGCUScyWD+MaKldOu2qDBG32obPiSw9lm8\r\nnxQBR2IlqByyeDA=\n-----END >>>> >>>> >>>> CERTIFICATE-----\n\n') >>>> >>>> Martin >>>> >>> >>> When I said "some of the properties", I certainly did not mean the >>> absolute >>> basics, but rather stuff like "cert-presave-command". >> >> Ah, ok. Then I think this snippet will help: >> >>>>> properties_manager = dbus.Interface(req, >>>>> 'org.freedesktop.DBus.Properties') >>>>> properties_manager.Get('org.fedorahosted.certmonger.request', >> 'cert-presave-command') >> dbus.String(u'/usr/lib64/ipa/certmonger/stop_pkicad') >>>>> properties_manager.Get('org.fedorahosted.certmonger.request', >> 'cert-postsave-command') >> dbus.String(u'/usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert >> cert-pki-ca"') >> >> Martin >> > > Nice, I think we are good to go then. > +1 on DBus. And to answer David's second question, yes, it would be bad to stop tracking these requests automatically because we don't know what they are. A customer could be using certmonger for their own purposes. rob From pvoborni at redhat.com Wed Jul 23 13:25:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Jul 2014 15:25:15 +0200 Subject: [Freeipa-devel] [PATCH] 712 webui: detach facet nodes Message-ID: <53CFB7BB.3090206@redhat.com> Detach/attach facet nodes when switching facets instead of hiding/showing. Keeps dom-tree more simple. This patch is not really needed. I implemented it while testing something in IE. But it might have positive effect for poorly written parts of Web UI(if there are any :) ) or plugins. Basically it simplifies DOM tree to contain nodes only for the active facet. Therefore ugly expressions like $('button .foobar') are much more performant. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0712-webui-detach-facet-nodes.patch Type: text/x-patch Size: 2357 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 23 13:26:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Jul 2014 15:26:53 +0200 Subject: [Freeipa-devel] [PATCH] 713-714 webui: replace action_buttons with action_widget Message-ID: <53CFB81D.50609@redhat.com> [PATCH] 713 webui: replace action_buttons with action_widget Simplify code base by reuse of 'disable' feature of button_widget. All occurrences of action-button which were disabled/enabled were replaced by button-widget. https://fedorahosted.org/freeipa/ticket/4258 [PATCH] 714 webui: remove remaining action-button-disabled occurrences Buttons in hbactest check for 'action-button-disabled' but it's never set. https://fedorahosted.org/freeipa/ticket/4258 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0714-webui-remove-remaining-action-button-disabled-occurr.patch Type: text/x-patch Size: 3739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0713-webui-replace-action_buttons-with-action_widget.patch Type: text/x-patch Size: 17430 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 23 13:30:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2014 09:30:39 -0400 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <53CFB5F0.7030507@redhat.com> References: <53CFB5F0.7030507@redhat.com> Message-ID: <53CFB8FF.2020307@redhat.com> Martin Basti wrote: > This patch fixes ordering problem of schema updates > > Martin should it be in IPA 4.0.x ? It requires rebased ldap_python (will > be in Fedora 21) > > Patch attached It looks like the modlist is only generated during a live run which would diminish the utility of the --test mode. Is it safe to assume this was done on purpose because schema changes are being done incrementally vs done all at once, so that parent classes may not exist in test mode? rob From nalin at redhat.com Wed Jul 23 13:34:40 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 23 Jul 2014 09:34:40 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <20140723083252.GB1659@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723083252.GB1659@redhat.com> Message-ID: <20140723133440.GA1400@redhat.com> On Wed, Jul 23, 2014 at 11:32:52AM +0300, Alexander Bokovoy wrote: > Were there DBus Python bindings available in RHEL 5/6 at the time when the > code was written? Yes, but the API itself wasn't all there, and large parts of the internals needed to be rewritten around its 0.53 release. Before then, it didn't expose _anything_ as properties. The methods that return data were all that it provided. HTH, Nalin From nalin at redhat.com Wed Jul 23 13:45:07 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 23 Jul 2014 09:45:07 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53CF6E77.5000101@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> Message-ID: <20140723134507.GB1400@redhat.com> On Wed, Jul 23, 2014 at 10:12:39AM +0200, Martin Kosek wrote: > Certmonger API looked complete enough to pull this off: > https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt > > If I am wrong, please tell me. No, it's meant to be complete -- the getcert command only uses the APIs to talk to the daemon, so they provide at least what it needs. Two words of caution: * That file's manually maintained, so it might not completely reflect what's available. The introspection data's generated at runtime, so if you poke the service with an introspection request, or using d-feet, which does so under the covers, you might spot discrepancies. It probably goes without saying, but please report any that you find. * The majority of properties are currently marked read-only, and you currently have to use the 'modify' API request to change them. Mostly this is a result of 'getcert' not having needed anything more than that, and properties having been added after the initial versions, so it's not set in stone. HTH, Nalin From mkosek at redhat.com Wed Jul 23 13:45:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 15:45:56 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <53CFB5F0.7030507@redhat.com> References: <53CFB5F0.7030507@redhat.com> Message-ID: <53CFBC94.7090007@redhat.com> On 07/23/2014 03:17 PM, Martin Basti wrote: > This patch fixes ordering problem of schema updates > > Martin should it be in IPA 4.0.x ? It requires rebased ldap_python (will be in > Fedora 21) > > Patch attached If current LDAP updater does not fail or crash on 4.0.x, I would personally leave this change for FreeIPA 4.1. Note that you may need to also add the new python-ldap build to pviktori's COPR repo to make it available to Fedora 20 users. Martin From dkupka at redhat.com Wed Jul 23 13:46:41 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 23 Jul 2014 15:46:41 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid Message-ID: <53CFBCC1.70907@redhat.com> https://fedorahosted.org/freeipa/ticket/4244 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0005-Verify-otptoken-timespan-is-valid.patch Type: text/x-patch Size: 3900 bytes Desc: not available URL: From dkupka at redhat.com Wed Jul 23 14:08:41 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 23 Jul 2014 16:08:41 +0200 Subject: [Freeipa-devel] [PATCH] 0006 Fix group-remove-member crash when group is removed from a protected group Message-ID: <53CFC1E9.5050209@redhat.com> https://fedorahosted.org/freeipa/ticket/4448 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0006-Fix-group-remove-member-crash-when-group-is-removed-.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 23 14:15:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 16:15:17 +0200 Subject: [Freeipa-devel] [PATCH] 0006 Fix group-remove-member crash when group is removed from a protected group In-Reply-To: <53CFC1E9.5050209@redhat.com> References: <53CFC1E9.5050209@redhat.com> Message-ID: <53CFC375.4010102@redhat.com> On 07/23/2014 04:08 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4448 Alternatively, we could also update the "if" condition to avoid running this section at all when options['user'] does not exist or is empty. This would save us at least from api.Command.group_show call. Martin From rcritten at redhat.com Wed Jul 23 14:29:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2014 10:29:24 -0400 Subject: [Freeipa-devel] [PATCH] 0006 Fix group-remove-member crash when group is removed from a protected group In-Reply-To: <53CFC375.4010102@redhat.com> References: <53CFC1E9.5050209@redhat.com> <53CFC375.4010102@redhat.com> Message-ID: <53CFC6C4.9080003@redhat.com> Martin Kosek wrote: > On 07/23/2014 04:08 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4448 > > Alternatively, we could also update the "if" condition to avoid running this > section at all when options['user'] does not exist or is empty. This would save > us at least from api.Command.group_show call. A new test or tests would be nice as well. rob From dkupka at redhat.com Wed Jul 23 14:32:25 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 23 Jul 2014 16:32:25 +0200 Subject: [Freeipa-devel] [PATCH] 0006 Fix group-remove-member crash when group is removed from a protected group In-Reply-To: <53CFC375.4010102@redhat.com> References: <53CFC1E9.5050209@redhat.com> <53CFC375.4010102@redhat.com> Message-ID: <53CFC779.3090100@redhat.com> On 07/23/2014 04:15 PM, Martin Kosek wrote: > On 07/23/2014 04:08 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4448 > > Alternatively, we could also update the "if" condition to avoid running this > section at all when options['user'] does not exist or is empty. This would save > us at least from api.Command.group_show call. > > Martin > You're right as always, Martin :-) -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0006-2-Fix-group-remove-member-crash-when-group-is-removed-.patch Type: text/x-patch Size: 1063 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 23 14:38:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 16:38:20 +0200 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme Message-ID: <53CFC8DC.50403@redhat.com> Theme package is contains resources for PKI web interface. This interface is not needed by FreeIPA as it rather utilizes it's API. As recommended in https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard dependency. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-479-do-not-require-dogtag-pki-server-theme.patch Type: text/x-patch Size: 941 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 23 14:45:08 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Jul 2014 16:45:08 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <53CFB8FF.2020307@redhat.com> References: <53CFB5F0.7030507@redhat.com> <53CFB8FF.2020307@redhat.com> Message-ID: <53CFCA74.3030402@redhat.com> On 23/07/14 15:30, Rob Crittenden wrote: > Martin Basti wrote: >> This patch fixes ordering problem of schema updates >> >> Martin should it be in IPA 4.0.x ? It requires rebased ldap_python (will >> be in Fedora 21) >> >> Patch attached > It looks like the modlist is only generated during a live run which > would diminish the utility of the --test mode. > > Is it safe to assume this was done on purpose because schema changes are > being done incrementally vs done all at once, so that parent classes may > not exist in test mode? > > rob My bad, I fixed it. Now modlist will show updated data in --test mode too. Data are not updated to LDAP in test mode, so there is no restrictions to have a proper order of classes, and could be written all at once. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0105-2-FIX-ldap_updater-needs-correct-orderng-of-the-update.patch Type: text/x-patch Size: 7959 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 23 14:59:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Jul 2014 16:59:30 +0200 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html Message-ID: <53CFCDD2.3000606@redhat.com> reset_password.html now redirects browser to URL specified in 'redirect' uri component (if present). The component has to be URI encoded. ie (in browser console): $ encodeURIComponent('http://pvoborni.fedorapeople.org/doc/#!/guide/Debugging') --> "http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging" --> https://my.freeipa.server/ipa/ui/reset_password.html?redirect=http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging https://fedorahosted.org/freeipa/ticket/4440 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0715-webui-add-bounce-url-to-reset_password.html.patch Type: text/x-patch Size: 2027 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 23 15:07:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Jul 2014 17:07:07 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53CFBCC1.70907@redhat.com> References: <53CFBCC1.70907@redhat.com> Message-ID: <53CFCF9B.7080302@redhat.com> Hi, On 23.7.2014 15:46, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4244 1) Use "isinstance(X, Y)" instead of "type(X) is Y". 2) When is "type(not_before) is str" or "type(not_after) is str" true? The values coming from command options or LDAP should always be datetime, never str. 3) There are some misindentations: + raise ValidationError(name='not_after', + error='is before not_before!') + raise ValidationError(name='not_after', + error='is before not_before!') + raise ValidationError(name='not_before', + error='is after not_after!') 4) We don't do exclamation marks in errors messages. 5) Generally, when you want to validate command options, you should look into "options", not "entry_attrs". 6) This is not right: + result = self.api.Command.otptoken_find(ipatokenuniqueid= + entry_attrs.get('ipatokenuniqueid', None))['result'] This is: + result = self.api.Command.otptoken_show(keys[-1])['result'] Honza -- Jan Cholasta From abokovoy at redhat.com Wed Jul 23 15:07:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Jul 2014 18:07:56 +0300 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <53CFC8DC.50403@redhat.com> References: <53CFC8DC.50403@redhat.com> Message-ID: <20140723150756.GD1659@redhat.com> On Wed, 23 Jul 2014, Martin Kosek wrote: >Theme package is contains resources for PKI web interface. This interface >is not needed by FreeIPA as it rather utilizes it's API. As recommended in >https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >dependency. I've seen several times that people continue using PKI web interfaces for things we do not support yet, like issuing user certificates and the rest of features supported in Dogtag. I think this change might be subtle but otherwise breaking for some users. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jul 23 15:11:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 17:11:22 +0200 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <20140723150756.GD1659@redhat.com> References: <53CFC8DC.50403@redhat.com> <20140723150756.GD1659@redhat.com> Message-ID: <53CFD09A.7080705@redhat.com> On 07/23/2014 05:07 PM, Alexander Bokovoy wrote: > On Wed, 23 Jul 2014, Martin Kosek wrote: >> Theme package is contains resources for PKI web interface. This interface >> is not needed by FreeIPA as it rather utilizes it's API. As recommended in >> https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >> dependency. > I've seen several times that people continue using PKI web interfaces > for things we do not support yet, like issuing user certificates and the > rest of features supported in Dogtag. > > I think this change might be subtle but otherwise breaking for some > users. Ah, I personally did not see that yet. However, as this is still quite hacky and experimental use of FreeIPA PKI, it should not be in the list of hard requirements IMO. People who really need to use this interface can always install the package. Martin From abokovoy at redhat.com Wed Jul 23 15:21:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Jul 2014 18:21:20 +0300 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <53CFD09A.7080705@redhat.com> References: <53CFC8DC.50403@redhat.com> <20140723150756.GD1659@redhat.com> <53CFD09A.7080705@redhat.com> Message-ID: <20140723152120.GE1659@redhat.com> On Wed, 23 Jul 2014, Martin Kosek wrote: >On 07/23/2014 05:07 PM, Alexander Bokovoy wrote: >> On Wed, 23 Jul 2014, Martin Kosek wrote: >>> Theme package is contains resources for PKI web interface. This interface >>> is not needed by FreeIPA as it rather utilizes it's API. As recommended in >>> https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >>> dependency. >> I've seen several times that people continue using PKI web interfaces >> for things we do not support yet, like issuing user certificates and the >> rest of features supported in Dogtag. >> >> I think this change might be subtle but otherwise breaking for some >> users. > >Ah, I personally did not see that yet. However, as this is still quite hacky >and experimental use of FreeIPA PKI, it should not be in the list of hard >requirements IMO. People who really need to use this interface can always >install the package. At the very least this change has to be in the release notes. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jul 23 15:22:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Jul 2014 17:22:57 +0200 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <20140723152120.GE1659@redhat.com> References: <53CFC8DC.50403@redhat.com> <20140723150756.GD1659@redhat.com> <53CFD09A.7080705@redhat.com> <20140723152120.GE1659@redhat.com> Message-ID: <53CFD351.8070704@redhat.com> On 07/23/2014 05:21 PM, Alexander Bokovoy wrote: > On Wed, 23 Jul 2014, Martin Kosek wrote: >> On 07/23/2014 05:07 PM, Alexander Bokovoy wrote: >>> On Wed, 23 Jul 2014, Martin Kosek wrote: >>>> Theme package is contains resources for PKI web interface. This interface >>>> is not needed by FreeIPA as it rather utilizes it's API. As recommended in >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >>>> dependency. >>> I've seen several times that people continue using PKI web interfaces >>> for things we do not support yet, like issuing user certificates and the >>> rest of features supported in Dogtag. >>> >>> I think this change might be subtle but otherwise breaking for some >>> users. >> >> Ah, I personally did not see that yet. However, as this is still quite hacky >> and experimental use of FreeIPA PKI, it should not be in the list of hard >> requirements IMO. People who really need to use this interface can always >> install the package. > At the very least this change has to be in the release notes. I think I see the deal - apply the patch only for FreeIPA 4.1 and master (and not for 4.0.x) and add appropriate release notes for 4.1, when released. Martin From abokovoy at redhat.com Wed Jul 23 15:28:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Jul 2014 18:28:29 +0300 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <53CFD351.8070704@redhat.com> References: <53CFC8DC.50403@redhat.com> <20140723150756.GD1659@redhat.com> <53CFD09A.7080705@redhat.com> <20140723152120.GE1659@redhat.com> <53CFD351.8070704@redhat.com> Message-ID: <20140723152829.GF1659@redhat.com> On Wed, 23 Jul 2014, Martin Kosek wrote: >On 07/23/2014 05:21 PM, Alexander Bokovoy wrote: >> On Wed, 23 Jul 2014, Martin Kosek wrote: >>> On 07/23/2014 05:07 PM, Alexander Bokovoy wrote: >>>> On Wed, 23 Jul 2014, Martin Kosek wrote: >>>>> Theme package is contains resources for PKI web interface. This interface >>>>> is not needed by FreeIPA as it rather utilizes it's API. As recommended in >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >>>>> dependency. >>>> I've seen several times that people continue using PKI web interfaces >>>> for things we do not support yet, like issuing user certificates and the >>>> rest of features supported in Dogtag. >>>> >>>> I think this change might be subtle but otherwise breaking for some >>>> users. >>> >>> Ah, I personally did not see that yet. However, as this is still quite hacky >>> and experimental use of FreeIPA PKI, it should not be in the list of hard >>> requirements IMO. People who really need to use this interface can always >>> install the package. >> At the very least this change has to be in the release notes. > >I think I see the deal - apply the patch only for FreeIPA 4.1 and master (and >not for 4.0.x) and add appropriate release notes for 4.1, when released. Agreed. -- / Alexander Bokovoy From redhatrises at gmail.com Wed Jul 23 22:15:45 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 23 Jul 2014 16:15:45 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53CF61AB.7080706@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> Message-ID: Nope. Somehow in my head it felt cleaner. Updated patched attached. On Wed, Jul 23, 2014 at 1:18 AM, Jan Cholasta wrote: > On 23.7.2014 01:01, Gabe Alford wrote: > >> Forgot about --trust-secret. Here is an updated patch. >> >> >> On Mon, Jul 21, 2014 at 2:31 AM, Jan Cholasta > > wrote: >> >> On 21.7.2014 10:28, Martin Kosek wrote: >> >> On 07/21/2014 09:56 AM, Jan Cholasta wrote: >> >> Hi, >> >> On 16.7.2014 05:48, Gabe Alford wrote: >> >> Hello, >> >> Adds AD admin and password to interactive commands. >> https://fedorahosted.org/__freeipa/ticket/3034 >> >> >> >> Thanks, >> >> Gabe >> >> >> I think that instead of making the parameters mandatory, you >> should instead set >> alwaysask=True on them. >> >> Honza >> >> >> Trust can be established either with user+password options OR with >> --trust-secret option - i.e. you cannot use mandatory options >> nor alwaysask. >> >> >> Ah, right. >> >> >> >> This would rather lead to interactive_prompt_callback checking >> if any of >> authentication method is passed and asking for them if they >> aren't. >> >> >> +1 >> >> >> Martin >> >> >> >> -- >> Jan Cholasta >> >> >> > I don't think using an extra function to update a value in a dictionary is > very beneficial, is there a reason not to use "kw[X] = > self.prompt_param(self.params[X])" directly? > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0024-3-ipa-trust-add-command-should-be-interactive.patch Type: text/x-patch Size: 2402 bytes Desc: not available URL: From redhatrises at gmail.com Wed Jul 23 22:30:51 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 23 Jul 2014 16:30:51 -0600 Subject: [Freeipa-devel] [PATCH 0026][DOC] Type in sudocmd in documentation Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4451 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0026-Typo-in-upstream-documentation.patch Type: text/x-patch Size: 2142 bytes Desc: not available URL: From purpleidea at gmail.com Thu Jul 24 04:43:54 2014 From: purpleidea at gmail.com (James) Date: Thu, 24 Jul 2014 00:43:54 -0400 Subject: [Freeipa-devel] Storing/Looking up the creation time of a type Message-ID: <1406177034.4479.26.camel@freed> Hi devel, It would be particularly useful if each FreeIPA entry (eg: user, host, service, etc...) had creation and last modified timestamps. Do these fields already exist, and if they do, how can I access them? If they do not, I would like to propose these as a feature request. One use case for this feature: if this data exists, then actions could be scripted based on how old something is. For example: * an admin could check for old entries in case they are unneeded * puppet could be told to not manage entries older than a certain date * entries could be sorted by last modified to browse recent activity * and so on... An example of how this could be specifically useful is explained in my just published Puppet+FreeIPA article: https://ttboj.wordpress.com/2014/07/24/hybrid-management-of-freeipa-types-with-puppet/ Thank you again, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From abokovoy at redhat.com Thu Jul 24 05:40:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Jul 2014 08:40:45 +0300 Subject: [Freeipa-devel] Storing/Looking up the creation time of a type In-Reply-To: <1406177034.4479.26.camel@freed> References: <1406177034.4479.26.camel@freed> Message-ID: <20140724054045.GH1659@redhat.com> On Thu, 24 Jul 2014, James wrote: >Hi devel, > >It would be particularly useful if each FreeIPA entry (eg: user, host, >service, etc...) had creation and last modified timestamps. Do these >fields already exist, and if they do, how can I access them? > >If they do not, I would like to propose these as a feature request. These are called operational attributes and are available already, look at RFC 2251. 389-ds implements some more, check http://directory.fedoraproject.org/wiki/Howto:OperationalAttributes for details. $ ldapsearch -Y GSSAPI uid=admin modifyTimestamp createTimestamp SASL/GSSAPI authentication started SASL username: admin at T.VDA.LI SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=admin # requesting: modifyTimestamp createTimestamp # # admin, users, compat, t.vda.li dn: uid=admin,cn=users,cn=compat,dc=t,dc=vda,dc=li modifyTimestamp: 20140722091651Z createTimestamp: 20140722091651Z # admin, users, accounts, t.vda.li dn: uid=admin,cn=users,cn=accounts,dc=t,dc=vda,dc=li modifyTimestamp: 20140724053745Z createTimestamp: 20140722091018Z # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 Note that operational attributes modifyTimestamp and createTimestamp for compat tree differ from the main tree due to the way of working of slapi-nis plugin. If you stick to the main tree, you should be fine. -- / Alexander Bokovoy From purpleidea at gmail.com Thu Jul 24 06:11:50 2014 From: purpleidea at gmail.com (James) Date: Thu, 24 Jul 2014 02:11:50 -0400 Subject: [Freeipa-devel] Storing/Looking up the creation time of a type In-Reply-To: <20140724054045.GH1659@redhat.com> References: <1406177034.4479.26.camel@freed> <20140724054045.GH1659@redhat.com> Message-ID: <1406182310.4479.40.camel@freed> On Thu, 2014-07-24 at 08:40 +0300, Alexander Bokovoy wrote: > On Thu, 24 Jul 2014, James wrote: > >Hi devel, > > > >It would be particularly useful if each FreeIPA entry (eg: user, host, > >service, etc...) had creation and last modified timestamps. Do these > >fields already exist, and if they do, how can I access them? > > > >If they do not, I would like to propose these as a feature request. > These are called operational attributes and are available already, look > at RFC 2251. > 389-ds implements some more, check > http://directory.fedoraproject.org/wiki/Howto:OperationalAttributes for > details. As usual ab, your responses are always particularly helpful. Thanks!! > > $ ldapsearch -Y GSSAPI uid=admin modifyTimestamp createTimestamp > SASL/GSSAPI authentication started > SASL username: admin at T.VDA.LI > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: uid=admin > # requesting: modifyTimestamp createTimestamp > # > > # admin, users, compat, t.vda.li > dn: uid=admin,cn=users,cn=compat,dc=t,dc=vda,dc=li > modifyTimestamp: 20140722091651Z > createTimestamp: 20140722091651Z > > # admin, users, accounts, t.vda.li > dn: uid=admin,cn=users,cn=accounts,dc=t,dc=vda,dc=li > modifyTimestamp: 20140724053745Z > createTimestamp: 20140722091018Z > > # search result > search: 4 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 Will the modify and create timestamps be the same from replica to replica for the same item? I'm hoping they are, however if they aren't, are there any recommended practices to ensure consistency across queries? > > > Note that operational attributes modifyTimestamp and createTimestamp for > compat tree differ from the main tree due to the way of working of > slapi-nis plugin. If you stick to the main tree, you should be fine. Do you think you could briefly elaborate what the difference is and/or how to avoid the compat tree? > > > Thanks again, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mbasti at redhat.com Thu Jul 24 07:06:04 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Jul 2014 09:06:04 +0200 Subject: [Freeipa-devel] [PATCH] 0105 FIX: LDAP_updater In-Reply-To: <53CFB5F0.7030507@redhat.com> References: <53CFB5F0.7030507@redhat.com> Message-ID: <53D0B05C.3060405@redhat.com> On 23/07/14 15:17, Martin Basti wrote: > This patch fixes ordering problem of schema updates > > Martin should it be in IPA 4.0.x ? It requires rebased ldap_python > (will be in Fedora 21) > > Patch attached > > I found a bug there, but before I send updated version, I need to decide how print modlist: 1. Print modlist before each LDAP update (if changes exist), show modlist per incremental update 2. Print modlist only at once with all updates 3. Use [1] for live_run, [2] for test -- Martin Basti From dkupka at redhat.com Thu Jul 24 08:00:33 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 24 Jul 2014 10:00:33 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53CFCF9B.7080302@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> Message-ID: <53D0BD21.4000805@redhat.com> On 07/23/2014 05:07 PM, Jan Cholasta wrote: > Hi, > > On 23.7.2014 15:46, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4244 > > 1) Use "isinstance(X, Y)" instead of "type(X) is Y". Thanks for advice, will try to remember. > > 2) When is "type(not_before) is str" or "type(not_after) is str" true? > The values coming from command options or LDAP should always be > datetime, never str. Actually, it is never true. I don't know why I thought that there is such option. > > 3) There are some misindentations: > > + raise ValidationError(name='not_after', > + error='is before not_before!') > > + raise ValidationError(name='not_after', > + error='is before not_before!') > > + raise ValidationError(name='not_before', > + error='is after not_after!') > > 4) We don't do exclamation marks in errors messages. You re right, it's probably better not to shout at customer :) > > 5) Generally, when you want to validate command options, you should look > into "options", not "entry_attrs". > > 6) This is not right: > > + result = self.api.Command.otptoken_find(ipatokenuniqueid= > + entry_attrs.get('ipatokenuniqueid', None))['result'] > > This is: > > + result = self.api.Command.otptoken_show(keys[-1])['result'] Both works, but Martin explained me why is otptoken_show better and how it actually works. > > Honza > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0005-2-Verify-otptoken-timespan-is-valid.patch Type: text/x-patch Size: 3580 bytes Desc: not available URL: From thozza at redhat.com Thu Jul 24 08:20:18 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 24 Jul 2014 10:20:18 +0200 Subject: [Freeipa-devel] [PATCH 0275] Add TLSARecord to idnsRecord object class In-Reply-To: <53CFA9C1.10303@redhat.com> References: <53CFA9C1.10303@redhat.com> Message-ID: <53D0C1C2.7010107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2014 02:25 PM, Petr Spacek wrote: > Hello, > > Add TLSARecord to idnsRecord object class. > ACK. Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT0MG0AAoJEMWIetUdnzwtdCcH/RqNYSs4x/rRh0RfrFnl01UG ub7B7Er3BOgYwB1KeOcjFMBySI8DXZHPE40YshBw1fWfhatrc9DMPGZGJSebW2ti 4rvr6olfRHPwGJuzDxG7FLpd7CDt16m2Vc62a6191LlZeXYbeABimfUuz6Ffst+8 JejLkdKR2dpKOOYHWEZ1TMKG7WVd1qA3eOWdzWWVbiCxt7oAGZpJL+ftDh9UnJMS PwwWlYKKiZI8d+bqX7fmZfsGkMGIliQxEnKoRV/j+G/dJjIIGeGJuHRMas/NGlSL CUD8NuUTuJmLwYzZRkPrRoeOKiLhZhjlEuOhUMNqHNGaA91zi1bQYF9XeMPt16s= =m1A3 -----END PGP SIGNATURE----- From thozza at redhat.com Thu Jul 24 08:20:49 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 24 Jul 2014 10:20:49 +0200 Subject: [Freeipa-devel] [PATCH 0276] Fix crash during reconnection to LDAP In-Reply-To: <53CFA9DA.8000606@redhat.com> References: <53CFA9DA.8000606@redhat.com> Message-ID: <53D0C1E1.50901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2014 02:26 PM, Petr Spacek wrote: > Hello, > > Fix crash during reconnection to LDAP. > The fix works. ACK. Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT0MHhAAoJEMWIetUdnzwtwBYH/1GyydKyhakuGp42PWLUHs55 cpl/VvHjQtDqlQPe5osxkMRhz32oJ/pn5B965lHZnRHsOySp9Cqtk/3dRiyxxvUA rllLgunTrC4oVM4SsLateREOZPl+hvIy599e2ZiXyHnPqvmi1rXN/SX9BZEhLGoh z6DAK6unkkcEG+8NUkt4SnPXwnQ6zY4yYicmAp73IjO9p09Xy8uV98xk6Od/UfSB 6VPfvre3OhEEndiCISnzti18LTKrmgCeH371bXb8gKcX8y3zNcnxAFE95Yp5N2W3 /qViRpHTt+iUABN4Bt5rk4fVMN95Mn9AndE2O7CKx42xdh9TMzYYPM5amZKZUz8= =Ka0U -----END PGP SIGNATURE----- From thozza at redhat.com Thu Jul 24 08:21:03 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 24 Jul 2014 10:21:03 +0200 Subject: [Freeipa-devel] [PATCH 0277] Bump NVR to 5.1 In-Reply-To: <53CFAA43.60606@redhat.com> References: <53CFAA43.60606@redhat.com> Message-ID: <53D0C1EF.4090706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2014 02:27 PM, Petr Spacek wrote: > Hello, > > Bump NVR to 5.1. > ACK. Tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT0MHvAAoJEMWIetUdnzwtwG4H/3yoylMft5vskUK5thelM+TH 19dLJ5LmDNuEhLQx2nsz7L4BzI9XLfESj1KYZiqFzR9ENqvwb9uKoEV6rZztwnNe jT3A14AIRoE6S/hhaaXbDvOzTheyfQBbHh0WZxTY7Ge+QVv/1WfD1Ko8bLiPbNY3 m+CdXGGB+lnF6zBP+yNyyHwnyhI9Vda7JwVi5VfIVKPJCtafXloVTiHGKVBKyBj/ sojXcVOF2FSyhykBFbM24HnirWbHVUuv5NLiO1ciwKzJx3hL3feP8bTySCwr+FzH E4vvaa3jVT9yBLzz7bnzsL4r2jLn+IYaT84nG8SGlMyqNioHqxrQPKXRnSGBuds= =X41u -----END PGP SIGNATURE----- From pspacek at redhat.com Thu Jul 24 09:00:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Jul 2014 11:00:23 +0200 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files In-Reply-To: <20140227141937.GA32698@mail.corp.redhat.com> References: <20140227141937.GA32698@mail.corp.redhat.com> Message-ID: <53D0CB27.7090203@redhat.com> 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! -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 24 10:00:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Jul 2014 12:00:46 +0200 Subject: [Freeipa-devel] [PATCH 0275] Add TLSARecord to idnsRecord object class In-Reply-To: <53D0C1C2.7010107@redhat.com> References: <53CFA9C1.10303@redhat.com> <53D0C1C2.7010107@redhat.com> Message-ID: <53D0D94E.2020205@redhat.com> On 24.7.2014 10:20, Tomas Hozza wrote: > On 07/23/2014 02:25 PM, Petr Spacek wrote: >> >Hello, >> > >> >Add TLSARecord to idnsRecord object class. >> > > ACK. Pushed to master: 2d358ccbc323ea6d4339f22b16d419195054e017 -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 24 10:01:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Jul 2014 12:01:10 +0200 Subject: [Freeipa-devel] [PATCH 0276] Fix crash during reconnection to LDAP In-Reply-To: <53D0C1E1.50901@redhat.com> References: <53CFA9DA.8000606@redhat.com> <53D0C1E1.50901@redhat.com> Message-ID: <53D0D966.6030304@redhat.com> On 24.7.2014 10:20, Tomas Hozza wrote: > On 07/23/2014 02:26 PM, Petr Spacek wrote: >> >Hello, >> > >> >Fix crash during reconnection to LDAP. >> > > The fix works. > > ACK. Pushed to master: fb979d2f07be16f8cf441d393612504235ab26d8 -- Petr^2 Spacek From pspacek at redhat.com Thu Jul 24 10:01:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Jul 2014 12:01:32 +0200 Subject: [Freeipa-devel] [PATCH 0277] Bump NVR to 5.1 In-Reply-To: <53D0C1EF.4090706@redhat.com> References: <53CFAA43.60606@redhat.com> <53D0C1EF.4090706@redhat.com> Message-ID: <53D0D97C.10106@redhat.com> On 24.7.2014 10:21, Tomas Hozza wrote: > On 07/23/2014 02:27 PM, Petr Spacek wrote: >> >Hello, >> > >> >Bump NVR to 5.1. >> > > ACK. Pushed to master: 1ac2fd5e1d7e5ad742739b4ec5d2c326dcc0f184 -- Petr^2 Spacek From tbabej at redhat.com Thu Jul 24 10:35:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 24 Jul 2014 12:35:22 +0200 Subject: [Freeipa-devel] [PATCH 0246] baseldap: Fix undefined variable reference in Message-ID: <53D0E16A.9020303@redhat.com> Hi, on receiving a PublicError we fail with InternalError since msg is not defined. -- 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-0246-baseldap-Fix-undefined-variable-reference-in-LDAPAdd.patch Type: text/x-patch Size: 1400 bytes Desc: not available URL: From tbabej at redhat.com Thu Jul 24 10:56:21 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 24 Jul 2014 12:56:21 +0200 Subject: [Freeipa-devel] [PATCH 0246] baseldap: Fix undefined variable reference in In-Reply-To: <53D0E16A.9020303@redhat.com> References: <53D0E16A.9020303@redhat.com> Message-ID: <53D0E655.7050504@redhat.com> On 07/24/2014 12:35 PM, Tomas Babej wrote: > Hi, > > on receiving a PublicError we fail with InternalError since msg is not > defined. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I also realized there's no need for the nested try-blocks, so added some refactoring to the fix, which makes the code much more simple. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0246-2-baseldap-Fix-undefined-variable-reference-in-LDAPAdd.patch Type: text/x-patch Size: 3915 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 24 11:03:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Jul 2014 13:03:05 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 5.1 Message-ID: <53D0E7E9.3010305@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 5.1. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.1-1.fc20 Release to Fedora 'updates' repo will be coordinated with FreeIPA 4.0 release to prevent breakages. == Changes in 5.1 == [1] Fix crash during reconnection to LDAP. == Changes in 5.0 == [1] Support for DNSSEC in-line signing was added. Now any LDAP zone can be signed with keys provided by user. [2] DNSKEY, RRSIG, NSEC and NSEC3 records are automatically managed by BIND+bind-dyndb-ldap. Respective attributes in LDAP are ignored. [3] Forwarder semantic was changed to match BIND's semantics: - idnsZone object always represents master zone - idnsForwardZone object (new) always represents forward zone [4] Master root zone can be stored in LDAP. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. !!! CAUTION !!! idnsZone object class changed it's semantics in version 5.0. Please read https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README and update idnsForwarders and idnsForward policy attributes in your DNS zones accordingly. Transition from idnsZone to idnsForwardZone object class can be made seamless if you change data in LDAP before you upgrade to version 5.x. All bind-dyndb-ldap versions >= 3.0 support the idnsForwardZone object class. Users of FreeIPA < 4.0 should be careful when upgrading bind-dyndb-ldap to version >= 5.0 (if they do not upgrade to FreeIPA 4.x at the same time). Configuration semantics related to conditional (per-zone) forwarding has changed and FreeIPA < 4.0 doesn't have appropriate user interface and API. It is safe to upgrade if you use *only* global forwarders (shown by 'ipa dnsconfig-show') and *do not* use per-zone forwarders (shown by 'ipa dnszone-show'). Don't hesitate to ask freeipa-users mailing list if you need help with upgrade. !!! CAUTION !!! Downgrading back to any 4.x version is supported. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From mkosek at redhat.com Thu Jul 24 11:58:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Jul 2014 13:58:55 +0200 Subject: [Freeipa-devel] [PATCH] 479 Do not require dogtag-pki-server-theme In-Reply-To: <20140723152829.GF1659@redhat.com> References: <53CFC8DC.50403@redhat.com> <20140723150756.GD1659@redhat.com> <53CFD09A.7080705@redhat.com> <20140723152120.GE1659@redhat.com> <53CFD351.8070704@redhat.com> <20140723152829.GF1659@redhat.com> Message-ID: <53D0F4FF.6080001@redhat.com> On 07/23/2014 05:28 PM, Alexander Bokovoy wrote: > On Wed, 23 Jul 2014, Martin Kosek wrote: >> On 07/23/2014 05:21 PM, Alexander Bokovoy wrote: >>> On Wed, 23 Jul 2014, Martin Kosek wrote: >>>> On 07/23/2014 05:07 PM, Alexander Bokovoy wrote: >>>>> On Wed, 23 Jul 2014, Martin Kosek wrote: >>>>>> Theme package is contains resources for PKI web interface. This interface >>>>>> is not needed by FreeIPA as it rather utilizes it's API. As recommended in >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1068029#c5, remove this hard >>>>>> dependency. >>>>> I've seen several times that people continue using PKI web interfaces >>>>> for things we do not support yet, like issuing user certificates and the >>>>> rest of features supported in Dogtag. >>>>> >>>>> I think this change might be subtle but otherwise breaking for some >>>>> users. >>>> >>>> Ah, I personally did not see that yet. However, as this is still quite hacky >>>> and experimental use of FreeIPA PKI, it should not be in the list of hard >>>> requirements IMO. People who really need to use this interface can always >>>> install the package. >>> At the very least this change has to be in the release notes. >> >> I think I see the deal - apply the patch only for FreeIPA 4.1 and master (and >> not for 4.0.x) and add appropriate release notes for 4.1, when released. > Agreed. Pushed to: master: 1026a6387cd392994ec996db53141d16dfcbee29 ipa-4-1: 1026a6387cd392994ec996db53141d16dfcbee29 Please remind me in case we forgot to mention that in our release notes :-) Thanks, Martin From dkupka at redhat.com Thu Jul 24 12:02:53 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 24 Jul 2014 14:02:53 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check In-Reply-To: <53CE0AD9.4040404@redhat.com> References: <53C8F7FD.9030200@redhat.com> <53C8FC5C.9030803@redhat.com> <53CD1EF7.9020501@redhat.com> <53CE0AD9.4040404@redhat.com> Message-ID: <53D0F5ED.8090808@redhat.com> On 07/22/2014 08:55 AM, Martin Kosek wrote: > On 07/21/2014 04:08 PM, David Kupka wrote: >> On 07/18/2014 12:52 PM, Martin Kosek wrote: >>> On 07/18/2014 12:33 PM, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/2796 >>> >>> 1) Would it be easier/more convenient to just implement following simple check >>> instead of bad_prefix/bad_suffix? >>> >>> if password.strip() != password: >>> raise ValueError('Password must not start or end with whitespace') >>> >> >> Yes it would. Edited patch attached. >> >>> >>> 2) The main goal of the ticket 2796 was not fixed yet. It sometimes happen that >>> when installation crashes somewhere right after pkicreate, it does not record >>> and and does not uninstall the PKI component during "ipa-server-install >>> --uninstall". >>> >>> You may artificially invoke some crash in cainstance.py after pkicreate to test >>> it. When fixing it, check how is_configured() in Service object works an how >>> self.backup_state is called in other service modules (like dsinstance.py) where >>> the detection works correctly. >> >> You're completely right, Martin. I was unable to reproduce the bug (to force >> pkicreate/pkispawn to fail) so I thought that it was fixed by the password >> restriction. >> Then I discovered that most of the banned characters for password are no longer >> causing troubles a focused on this. But it's yet another issue. > > 1) Whitespace error: > > $ git am /tmp/freeipa-dkupka-0002-2-Improve-password-validity-check.patch > Applying: Improve password validity check. > /home/mkosek/freeipa/.git/rebase-apply/patch:25: trailing whitespace. > # Disallow leading/trailing whaitespaces > warning: 1 line adds whitespace errors. Git is highlighting these errors I was probably temporary blind. > > 2) The new admin validator is not applied to "-a" command line option and you > can pass any garbage to it. You need to replace this section: > > if options.admin_password is not None and len(options.admin_password) < 8: > parser.error("Admin user password must be at least 8 characters long") > > ... with the new validator just like we validate DM password. Added. > > Martin > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0002-3-Improve-password-validity-check.patch Type: text/x-patch Size: 3350 bytes Desc: not available URL: From mkosek at redhat.com Thu Jul 24 12:23:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Jul 2014 14:23:34 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Improve password validity check In-Reply-To: <53D0F5ED.8090808@redhat.com> References: <53C8F7FD.9030200@redhat.com> <53C8FC5C.9030803@redhat.com> <53CD1EF7.9020501@redhat.com> <53CE0AD9.4040404@redhat.com> <53D0F5ED.8090808@redhat.com> Message-ID: <53D0FAC6.5070001@redhat.com> On 07/24/2014 02:02 PM, David Kupka wrote: > On 07/22/2014 08:55 AM, Martin Kosek wrote: >> On 07/21/2014 04:08 PM, David Kupka wrote: >>> On 07/18/2014 12:52 PM, Martin Kosek wrote: >>>> On 07/18/2014 12:33 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2796 >>>> >>>> 1) Would it be easier/more convenient to just implement following simple check >>>> instead of bad_prefix/bad_suffix? >>>> >>>> if password.strip() != password: >>>> raise ValueError('Password must not start or end with whitespace') >>>> >>> >>> Yes it would. Edited patch attached. >>> >>>> >>>> 2) The main goal of the ticket 2796 was not fixed yet. It sometimes happen >>>> that >>>> when installation crashes somewhere right after pkicreate, it does not record >>>> and and does not uninstall the PKI component during "ipa-server-install >>>> --uninstall". >>>> >>>> You may artificially invoke some crash in cainstance.py after pkicreate to >>>> test >>>> it. When fixing it, check how is_configured() in Service object works an how >>>> self.backup_state is called in other service modules (like dsinstance.py) >>>> where >>>> the detection works correctly. >>> >>> You're completely right, Martin. I was unable to reproduce the bug (to force >>> pkicreate/pkispawn to fail) so I thought that it was fixed by the password >>> restriction. >>> Then I discovered that most of the banned characters for password are no longer >>> causing troubles a focused on this. But it's yet another issue. >> >> 1) Whitespace error: >> >> $ git am /tmp/freeipa-dkupka-0002-2-Improve-password-validity-check.patch >> Applying: Improve password validity check. >> /home/mkosek/freeipa/.git/rebase-apply/patch:25: trailing whitespace. >> # Disallow leading/trailing whaitespaces >> warning: 1 line adds whitespace errors. > > Git is highlighting these errors I was probably temporary blind. >> >> 2) The new admin validator is not applied to "-a" command line option and you >> can pass any garbage to it. You need to replace this section: >> >> if options.admin_password is not None and len(options.admin_password) < 8: >> parser.error("Admin user password must be at least 8 characters long") >> >> ... with the new validator just like we validate DM password. > Added. This one works fine. ACK. Pushed to: master: 603842867c65ae93d74a7c453c4301073c998441 ipa-4-1: 603842867c65ae93d74a7c453c4301073c998441 Martin From dkupka at redhat.com Thu Jul 24 13:11:13 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 24 Jul 2014 15:11:13 +0200 Subject: [Freeipa-devel] [PATCH] 0007 test group: remove group from protected group Message-ID: <53D105F1.8080907@redhat.com> Simple test scenario from ticket #4448. Last test will fail until patch freeipa-dkupka-0006 gets accepted. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0007-test-group-remove-group-from-protected-group.patch Type: text/x-patch Size: 3530 bytes Desc: not available URL: From rcritten at redhat.com Thu Jul 24 13:21:11 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jul 2014 09:21:11 -0400 Subject: [Freeipa-devel] [PATCH 0246] baseldap: Fix undefined variable reference in In-Reply-To: <53D0E655.7050504@redhat.com> References: <53D0E16A.9020303@redhat.com> <53D0E655.7050504@redhat.com> Message-ID: <53D10847.3050509@redhat.com> Tomas Babej wrote: > > On 07/24/2014 12:35 PM, Tomas Babej wrote: >> Hi, >> >> on receiving a PublicError we fail with InternalError since msg is not >> defined. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I also realized there's no need for the nested try-blocks, so added some > refactoring to the fix, which makes the code much more simple. Please open a ticket for this. Also note that the exc_wrapper may raise an exception which I believe is why I nested the exception originally. It may be no longer needed but worth a second look. rob From npmccallum at redhat.com Thu Jul 24 13:55:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 24 Jul 2014 09:55:10 -0400 Subject: [Freeipa-devel] [PATCH 0060] Fix ipa-getkeytab for pre-4.0 servers Message-ID: <1406210110.2976.1.camel@redhat.com> Also, make the error messages for this fallback case less scary and clean up some indentation issues in the nearby code which made this code difficult to read. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0060-Fix-ipa-getkeytab-for-pre-4.0-servers.patch Type: text/x-patch Size: 3524 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 24 14:10:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 24 Jul 2014 16:10:32 +0200 Subject: [Freeipa-devel] [PATCH] 308 Allow changing CA renewal master in ipa-csreplica-manage Message-ID: <53D113D8.9050507@redhat.com> Hi, the attached patch fixes . Requires my patches 246 and 262 (current versions attached). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.8-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.7-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-308-Allow-changing-CA-renewal-master-in-ipa-csreplica-ma.patch Type: text/x-patch Size: 2780 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 24 14:19:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Jul 2014 17:19:18 +0300 Subject: [Freeipa-devel] [PATCH 0060] Fix ipa-getkeytab for pre-4.0 servers In-Reply-To: <1406210110.2976.1.camel@redhat.com> References: <1406210110.2976.1.camel@redhat.com> Message-ID: <20140724141918.GJ1659@redhat.com> On Thu, 24 Jul 2014, Nathaniel McCallum wrote: >Also, make the error messages for this fallback case less scary and >clean up some indentation issues in the nearby code which made this >code difficult to read. ACK. Here is how it looks now in /var/log/ipaclient-install.log: 2014-07-24T14:15:36Z DEBUG Starting external process 2014-07-24T14:15:36Z DEBUG args='/usr/sbin/ipa-join' '-s' 'ipa-07-f20.t.vda.li' '-b' 'dc=t,dc=vda,dc=li' '-h' 'ipa-01.t.vda.li' 2014-07-24T14:15:38Z DEBUG Process finished, return code=0 2014-07-24T14:15:38Z DEBUG stdout= 2014-07-24T14:15:38Z DEBUG stderr=Failed to parse result: unsupported extended operation Retrying with pre-4.0 keytab retrieval method... Keytab successfully retrieved and stored in: /etc/krb5.keytab Certificate subject base is: O=T.VDA.LI 2014-07-24T14:15:38Z INFO Enrolled in IPA realm T.VDA.LI -- / Alexander Bokovoy From jcholast at redhat.com Thu Jul 24 14:42:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 24 Jul 2014 16:42:11 +0200 Subject: [Freeipa-devel] [PATCH] 309 Check if /root/ipa.csr exists when installing server with external CA Message-ID: <53D11B43.80100@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-309-Check-if-root-ipa.csr-exists-when-installing-server-.patch Type: text/x-patch Size: 2193 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jul 24 15:12:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 24 Jul 2014 11:12:07 -0400 Subject: [Freeipa-devel] [PATCH 0060] Fix ipa-getkeytab for pre-4.0 servers In-Reply-To: <20140724141918.GJ1659@redhat.com> References: <1406210110.2976.1.camel@redhat.com> <20140724141918.GJ1659@redhat.com> Message-ID: <1406214727.2976.2.camel@redhat.com> On Thu, 2014-07-24 at 17:19 +0300, Alexander Bokovoy wrote: > On Thu, 24 Jul 2014, Nathaniel McCallum wrote: > >Also, make the error messages for this fallback case less scary and > >clean up some indentation issues in the nearby code which made this > >code difficult to read. > ACK. Here is how it looks now in /var/log/ipaclient-install.log: > > 2014-07-24T14:15:36Z DEBUG Starting external process > 2014-07-24T14:15:36Z DEBUG args='/usr/sbin/ipa-join' '-s' 'ipa-07-f20.t.vda.li' '-b' 'dc=t,dc=vda,dc=li' '-h' 'ipa-01.t.vda.li' > 2014-07-24T14:15:38Z DEBUG Process finished, return code=0 > 2014-07-24T14:15:38Z DEBUG stdout= > 2014-07-24T14:15:38Z DEBUG stderr=Failed to parse result: unsupported extended operation > Retrying with pre-4.0 keytab retrieval method... > Keytab successfully retrieved and stored in: /etc/krb5.keytab > Certificate subject base is: O=T.VDA.LI > > 2014-07-24T14:15:38Z INFO Enrolled in IPA realm T.VDA.LI Attached is the same patch with the bug link in the commit message. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0060-Fix-ipa-getkeytab-for-pre-4.0-servers.patch Type: text/x-patch Size: 3570 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 24 15:14:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Jul 2014 17:14:58 +0200 Subject: [Freeipa-devel] LDAP updater with --test option Message-ID: <53D122F2.60404@redhat.com> Hi list, maybe I missed something, but I expected, there are no modifications with this option. With --test option the LDAP schema is not updated, but update plugins don't care about --test option ('live_run' in code). Update plugins use and IPA api directly to modify LDAP instead of return a required changes (DNS, update_idranges, update_managed_permissions, update_pacs, update_services plugins). Am wrong, or it is bad behavior and plugin should be fixed to not execute any modifications in test mode? Next Q: I have method which prepares IPA to support DNSSEC. The method requires both updating LDAP and creating directories/keytabs/etc. Should I separate the LDAP part of update method, or can I use it all in ldap-updater? -- Martin Basti From jcholast at redhat.com Thu Jul 24 15:30:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 24 Jul 2014 17:30:06 +0200 Subject: [Freeipa-devel] LDAP updater with --test option In-Reply-To: <53D122F2.60404@redhat.com> References: <53D122F2.60404@redhat.com> Message-ID: <53D1267E.4070401@redhat.com> Dne 24.7.2014 v 17:14 Martin Basti napsal(a): > Hi list, > > maybe I missed something, but I expected, there are no modifications > with this option. > > With --test option the LDAP schema is not updated, but update plugins > don't care about --test option ('live_run' in code). Most plugins should respect --test, only those that use ipaldap directly not, see . > > Update plugins use and IPA api directly to modify LDAP instead of return > a required changes > (DNS, update_idranges, update_managed_permissions, update_pacs, > update_services plugins). > > Am wrong, or it is bad behavior and plugin should be fixed to not > execute any modifications in test mode? > > Next Q: I have method which prepares IPA to support DNSSEC. The method > requires both updating LDAP and creating directories/keytabs/etc. > Should I separate the LDAP part of update method, or can I use it all in > ldap-updater? > -- Jan Cholasta From rcritten at redhat.com Thu Jul 24 15:29:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jul 2014 11:29:40 -0400 Subject: [Freeipa-devel] LDAP updater with --test option In-Reply-To: <53D122F2.60404@redhat.com> References: <53D122F2.60404@redhat.com> Message-ID: <53D12664.1040809@redhat.com> Martin Basti wrote: > Hi list, > > maybe I missed something, but I expected, there are no modifications > with this option. > > With --test option the LDAP schema is not updated, but update plugins > don't care about --test option ('live_run' in code). > > Update plugins use and IPA api directly to modify LDAP instead of return > a required changes > (DNS, update_idranges, update_managed_permissions, update_pacs, > update_services plugins). > > Am wrong, or it is bad behavior and plugin should be fixed to not > execute any modifications in test mode? I seem to recall that Petr^3 saw this as well and filed a ticket though I can't find it. IMHO yes, plugins should honor the test mode. > Next Q: I have method which prepares IPA to support DNSSEC. The method > requires both updating LDAP and creating directories/keytabs/etc. > Should I separate the LDAP part of update method, or can I use it all in > ldap-updater? The updater is intended for LDAP updates only. Probably best to split it with the ipa-upgradeconfig script. rob From jcholast at redhat.com Thu Jul 24 15:33:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 24 Jul 2014 17:33:10 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap Message-ID: <53D12736.9000409@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-310-Exclude-attributelevelrights-from-raw-result-process.patch Type: text/x-patch Size: 1217 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 24 16:36:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 24 Jul 2014 18:36:39 +0200 Subject: [Freeipa-devel] [PATCH] 711 webui: internet explorer fixes In-Reply-To: <53CFB5EA.7070904@redhat.com> References: <53CFB5EA.7070904@redhat.com> Message-ID: <53D13617.2070204@redhat.com> On 23.7.2014 15:17, Petr Vobornik wrote: > Fixed: > 1. IE doesn't support value 'initial' in CSS rule. > 2. setting innerHTML='' also destroys content of child nodes in > LoginScreen in IE -> reattached buttons have no text. > > Should go into 4.0 Milestone > Found an issue in the implementation, new version attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0711-1-webui-internet-explorer-fixes.patch Type: text/x-patch Size: 1892 bytes Desc: not available URL: From mkosek at redhat.com Fri Jul 25 06:25:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 08:25:18 +0200 Subject: [Freeipa-devel] [PATCH 0060] Fix ipa-getkeytab for pre-4.0 servers In-Reply-To: <1406214727.2976.2.camel@redhat.com> References: <1406210110.2976.1.camel@redhat.com> <20140724141918.GJ1659@redhat.com> <1406214727.2976.2.camel@redhat.com> Message-ID: <53D1F84E.9000200@redhat.com> On 07/24/2014 05:12 PM, Nathaniel McCallum wrote: > On Thu, 2014-07-24 at 17:19 +0300, Alexander Bokovoy wrote: >> On Thu, 24 Jul 2014, Nathaniel McCallum wrote: >>> Also, make the error messages for this fallback case less scary and >>> clean up some indentation issues in the nearby code which made this >>> code difficult to read. >> ACK. Here is how it looks now in /var/log/ipaclient-install.log: >> >> 2014-07-24T14:15:36Z DEBUG Starting external process >> 2014-07-24T14:15:36Z DEBUG args='/usr/sbin/ipa-join' '-s' 'ipa-07-f20.t.vda.li' '-b' 'dc=t,dc=vda,dc=li' '-h' 'ipa-01.t.vda.li' >> 2014-07-24T14:15:38Z DEBUG Process finished, return code=0 >> 2014-07-24T14:15:38Z DEBUG stdout= >> 2014-07-24T14:15:38Z DEBUG stderr=Failed to parse result: unsupported extended operation >> Retrying with pre-4.0 keytab retrieval method... >> Keytab successfully retrieved and stored in: /etc/krb5.keytab >> Certificate subject base is: O=T.VDA.LI >> >> 2014-07-24T14:15:38Z INFO Enrolled in IPA realm T.VDA.LI > > Attached is the same patch with the bug link in the commit message. Good! Thanks for fixing the scary error messages :-) Pushed to: master: 96986056f65beb120cd74a311524b6601383ee80 ipa-4-1: 96986056f65beb120cd74a311524b6601383ee80 ipa-4-0: 217aba77dcfc59c52ad565e33af341da06e76bcc Martin From lkrispen at redhat.com Fri Jul 25 08:13:41 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 25 Jul 2014 10:13:41 +0200 Subject: [Freeipa-devel] ipa-replica-manage and topology plugin Message-ID: <53D211B5.50002@redhat.com> Hi, I am working on ticket #4302 and am building a protoptype to verify if the current design [1] will work an what is missing. Now the question comes up, how will this be managed and what happens with eg ipa-replica-manage ? If the topology plugin is deployed and configured it will control all replication related tasks via modifcations of the entries in the shared tree, direct modofications of replication agreements will be rejected. This makes several subcommands of ipa-replica-manage unusable, like connect/disconnect/... . So should the functionality of ipa-replica-manage be changed to use the shared tree or should there be a new command like ipa-topology-manage. I would prefere a new command, so ipa-replica-manage is there if the topology plugin is disabled, also there shoul be some new subcommands like topology-verify, topology-view ... Let me know what you think, Thanks, Ludwig [1] http://www.freeipa.org/page/V4/Manage_replication_topology From abokovoy at redhat.com Fri Jul 25 08:24:47 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 25 Jul 2014 11:24:47 +0300 Subject: [Freeipa-devel] [PATCH 0057] Add TOTP watermark support In-Reply-To: <1405097033.3032.5.camel@ipa.example.com> References: <1405097033.3032.5.camel@ipa.example.com> Message-ID: <20140725082447.GP1659@redhat.com> On Fri, 11 Jul 2014, Nathaniel McCallum wrote: >This prevents the reuse of TOTP tokens by recording the last token >interval that was used. This will be replicated as normal. However, >this patch does not increase the number of writes to the database >in the standard authentication case. This is because it also >eliminates an unnecessary write during authentication. Hence, this >patch should be write-load neutral with the existing code. > >Further performance enhancement is desired, but is outside the >scope of this patch. > >https://fedorahosted.org/freeipa/ticket/4410 ACK. I've tested it with successive LDAP binds with TOTP token and only first attempt to bind was successful with the same TOTP code. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jul 25 08:26:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 25 Jul 2014 11:26:14 +0300 Subject: [Freeipa-devel] [PATCH] 478 Allow hashed passwords in DS In-Reply-To: <53CFA2C5.5090904@redhat.com> References: <53CFA2C5.5090904@redhat.com> Message-ID: <20140725082614.GQ1659@redhat.com> On Wed, 23 Jul 2014, Martin Kosek wrote: >See related thread "#4450: how to allow password migration?" for more information. > >--- >Without nsslapd-allow-hashed-passwords being turned on, user password >migration fails. > >https://fedorahosted.org/freeipa/ticket/4450 > ACK, also given that Bryce reported it working for his environment. -- / Alexander Bokovoy From purpleidea at gmail.com Fri Jul 25 08:29:13 2014 From: purpleidea at gmail.com (James) Date: Fri, 25 Jul 2014 04:29:13 -0400 Subject: [Freeipa-devel] ipa-replica-manage and topology plugin In-Reply-To: <53D211B5.50002@redhat.com> References: <53D211B5.50002@redhat.com> Message-ID: <1406276953.4479.100.camel@freed> On Fri, 2014-07-25 at 10:13 +0200, Ludwig Krispenz wrote: > Hi, > I am working on ticket #4302 and am building a protoptype to verify if > the current design [1] will work an what is missing. > > Now the question comes up, how will this be managed and what happens > with eg ipa-replica-manage ? If the topology plugin is deployed and > configured it will control all replication related tasks via > modifcations of the entries in the shared tree, direct modofications of > replication agreements will be rejected. This makes several subcommands > of ipa-replica-manage unusable, like connect/disconnect/... . > So should the functionality of ipa-replica-manage be changed to use the > shared tree or should there be a new command like ipa-topology-manage. > > I would prefere a new command, so ipa-replica-manage is there if the > topology plugin is disabled, also there shoul be some new subcommands > like topology-verify, topology-view ... > > Let me know what you think, I think the current mechanism of *managing* the topology works well, what I'd like to understand is what will change functionality wise with this feature... For some background, I have written the code (but not yet blogged or well documented) how topologies can be managed and defined in puppet... You might be interested in: https://github.com/purpleidea/puppet-ipa/commit/b621b1ae2d33ac2f56874fd7948f45829c6047d7 and https://github.com/purpleidea/puppet-ipa/commit/73712d1b051398c4193b081c3f35eddf679896e2 I define the topology shape algorithmic-ally (eg: ring, flat, star, etc...) and the replica make it happen :) Cheers, James > > Thanks, > Ludwig > > [1] http://www.freeipa.org/page/V4/Manage_replication_topology > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mkosek at redhat.com Fri Jul 25 08:38:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 10:38:36 +0200 Subject: [Freeipa-devel] [PATCH] 478 Allow hashed passwords in DS In-Reply-To: <20140725082614.GQ1659@redhat.com> References: <53CFA2C5.5090904@redhat.com> <20140725082614.GQ1659@redhat.com> Message-ID: <53D2178C.50009@redhat.com> On 07/25/2014 10:26 AM, Alexander Bokovoy wrote: > On Wed, 23 Jul 2014, Martin Kosek wrote: >> See related thread "#4450: how to allow password migration?" for more >> information. >> >> --- >> Without nsslapd-allow-hashed-passwords being turned on, user password >> migration fails. >> >> https://fedorahosted.org/freeipa/ticket/4450 >> > ACK, also given that Bryce reported it working for his environment. Pushed to: master: 15eb343b9c235a1ca3a6cc48f730590949d439ec ipa-4-1: 15eb343b9c235a1ca3a6cc48f730590949d439ec ipa-4-0: 47825306169b941902a443b01ac5a51991dcfb95 Martin From mkosek at redhat.com Fri Jul 25 08:48:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 10:48:15 +0200 Subject: [Freeipa-devel] [PATCH 0057] Add TOTP watermark support In-Reply-To: <20140725082447.GP1659@redhat.com> References: <1405097033.3032.5.camel@ipa.example.com> <20140725082447.GP1659@redhat.com> Message-ID: <53D219CF.6070105@redhat.com> On 07/25/2014 10:24 AM, Alexander Bokovoy wrote: > On Fri, 11 Jul 2014, Nathaniel McCallum wrote: >> This prevents the reuse of TOTP tokens by recording the last token >> interval that was used. This will be replicated as normal. However, >> this patch does not increase the number of writes to the database >> in the standard authentication case. This is because it also >> eliminates an unnecessary write during authentication. Hence, this >> patch should be write-load neutral with the existing code. >> >> Further performance enhancement is desired, but is outside the >> scope of this patch. >> >> https://fedorahosted.org/freeipa/ticket/4410 > ACK. I've tested it with successive LDAP binds with TOTP token and only > first attempt to bind was successful with the same TOTP code. > Thanks! Pushed to: master: d3638438fce1a9d1e07c2be3b8f43befb07a6b40 ipa-4-1: d3638438fce1a9d1e07c2be3b8f43befb07a6b40 ipa-4-0: b7c0c9335a5a0f88243b63bb26d6349444e6ed19 Martin From mkosek at redhat.com Fri Jul 25 10:23:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 12:23:53 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.0.1 Message-ID: <53D23039.107@redhat.com> Hello, As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 containing the first bunch of stabilization fixes in 4.0 branch. One of the most critical ones were client installation and migration issues which blocked some of our users. Those are now fixed. This is the candidate release notes, updates or feedback welcome: http://www.freeipa.org/page/Releases/4.0.1 Is there anything else you would see as a blocker for release? I plan to move all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would be released in August. The only think I am now little concerned about is following report for new 389 DS: https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 I can now also see it in my single node server, I am not sure whether it is benign (and annoying) error message or something more serious? Ludwig, is this something that should stall the FreeIPA release? After all, freeipa-server depends on this DS version. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Fri Jul 25 10:56:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 25 Jul 2014 12:56:33 +0200 Subject: [Freeipa-devel] [PATCH] 716 baseldap: return 'none' attr level right as unicode string Message-ID: <53D237E1.7020204@redhat.com> Returning non-unicode causes serialization into base64 which causes havoc in Web UI. https://fedorahosted.org/freeipa/ticket/4454 IMHO we should fix JSON-RPC serialization to encode non-unicode strings to normal JSON strings. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0716-baseldap-return-none-attr-level-right-as-unicode-str.patch Type: text/x-patch Size: 1025 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jul 25 11:02:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 25 Jul 2014 14:02:42 +0300 Subject: [Freeipa-devel] [PATCH] 716 baseldap: return 'none' attr level right as unicode string In-Reply-To: <53D237E1.7020204@redhat.com> References: <53D237E1.7020204@redhat.com> Message-ID: <20140725110242.GR1659@redhat.com> On Fri, 25 Jul 2014, Petr Vobornik wrote: >Returning non-unicode causes serialization into base64 which causes >havoc in Web UI. > >https://fedorahosted.org/freeipa/ticket/4454 ACK for this patch. > > >IMHO we should fix JSON-RPC serialization to encode non-unicode >strings to normal JSON strings. We should use unicode strings everywhere and leave non-unicode ones to present binary content, that's why it is encoded as base64. So no, we shouldn't change JSON-RPC serialization. However, we need to find a way to track non-unicode strings where possible. -- / Alexander Bokovoy From lkrispen at redhat.com Fri Jul 25 11:15:44 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 25 Jul 2014 13:15:44 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.0.1 In-Reply-To: <53D23039.107@redhat.com> References: <53D23039.107@redhat.com> Message-ID: <53D23C60.9080204@redhat.com> On 07/25/2014 12:23 PM, Martin Kosek wrote: > Hello, > > As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 > containing the first bunch of stabilization fixes in 4.0 branch. One of the > most critical ones were client installation and migration issues which blocked > some of our users. Those are now fixed. > > This is the candidate release notes, updates or feedback welcome: > http://www.freeipa.org/page/Releases/4.0.1 > > Is there anything else you would see as a blocker for release? I plan to move > all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would > be released in August. > > The only think I am now little concerned about is following report for new 389 DS: > > https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 > > I can now also see it in my single node server, I am not sure whether it is > benign (and annoying) error message or something more serious? Ludwig, is this > something that should stall the FreeIPA release? After all, freeipa-server > depends on this DS version. This message is caused by fix for #47834, it tries to get the connid (for use in potential error messages later) and this fails for internal operations, it checks this case, but the error message is already logged :-( I think you should see this for any internal add/delete/modrdn operation. It shouldn't cause any problems, but could be very annoying - so it should be fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your decision. Cant we upgrade DS independently of upgrading to 4.0.2, just when it is available ? > From abokovoy at redhat.com Fri Jul 25 11:19:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 25 Jul 2014 14:19:59 +0300 Subject: [Freeipa-devel] Releasing FreeIPA 4.0.1 In-Reply-To: <53D23C60.9080204@redhat.com> References: <53D23039.107@redhat.com> <53D23C60.9080204@redhat.com> Message-ID: <20140725111959.GA14057@redhat.com> On Fri, 25 Jul 2014, Ludwig Krispenz wrote: > >On 07/25/2014 12:23 PM, Martin Kosek wrote: >>Hello, >> >>As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 >>containing the first bunch of stabilization fixes in 4.0 branch. One of the >>most critical ones were client installation and migration issues which blocked >>some of our users. Those are now fixed. >> >>This is the candidate release notes, updates or feedback welcome: >>http://www.freeipa.org/page/Releases/4.0.1 >> >>Is there anything else you would see as a blocker for release? I plan to move >>all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would >>be released in August. >> >>The only think I am now little concerned about is following report for new 389 DS: >> >>https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 >> >>I can now also see it in my single node server, I am not sure whether it is >>benign (and annoying) error message or something more serious? Ludwig, is this >>something that should stall the FreeIPA release? After all, freeipa-server >>depends on this DS version. >This message is caused by fix for #47834, it tries to get the connid >(for use in potential error messages later) and this fails for >internal operations, it checks this case, but the error message is >already logged :-( >I think you should see this for any internal add/delete/modrdn operation. > >It shouldn't cause any problems, but could be very annoying - so it >should be fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your >decision. Cant we upgrade DS independently of upgrading to 4.0.2, just >when it is available ? We can upgrade 389-ds independently. Put a warning into FreeIPA 4.0.1 release notes, explaining the message being harmless and fix 389-ds asynchronously in Fedora. -- / Alexander Bokovoy From lkrispen at redhat.com Fri Jul 25 11:28:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 25 Jul 2014 13:28:51 +0200 Subject: [Freeipa-devel] ipa-replica-manage and topology plugin In-Reply-To: <1406276953.4479.100.camel@freed> References: <53D211B5.50002@redhat.com> <1406276953.4479.100.camel@freed> Message-ID: <53D23F73.6040007@redhat.com> On 07/25/2014 10:29 AM, James wrote: > On Fri, 2014-07-25 at 10:13 +0200, Ludwig Krispenz wrote: >> Hi, >> I am working on ticket #4302 and am building a protoptype to verify if >> the current design [1] will work an what is missing. >> >> Now the question comes up, how will this be managed and what happens >> with eg ipa-replica-manage ? If the topology plugin is deployed and >> configured it will control all replication related tasks via >> modifcations of the entries in the shared tree, direct modofications of >> replication agreements will be rejected. This makes several subcommands >> of ipa-replica-manage unusable, like connect/disconnect/... . >> So should the functionality of ipa-replica-manage be changed to use the >> shared tree or should there be a new command like ipa-topology-manage. >> >> I would prefere a new command, so ipa-replica-manage is there if the >> topology plugin is disabled, also there shoul be some new subcommands >> like topology-verify, topology-view ... >> >> Let me know what you think, > I think the current mechanism of *managing* the topology works well, > what I'd like to understand is what will change functionality wise with > this feature... the major change is that with this plugin replication information will be in the shared tree and so everything is available on any server and can be changed on any server, no creation of individual repl agreements need to be setup. what ipa-replica-manage connect does would be achieved, by adding a segment to the topology tree, this would be replicated and on each affected endpoint, the plugin would create the agreement > > For some background, I have written the code (but not yet blogged or > well documented) how topologies can be managed and defined in puppet... > You might be interested in: > https://github.com/purpleidea/puppet-ipa/commit/b621b1ae2d33ac2f56874fd7948f45829c6047d7 > and > https://github.com/purpleidea/puppet-ipa/commit/73712d1b051398c4193b081c3f35eddf679896e2 > > I define the topology shape algorithmic-ally (eg: ring, flat, star, > etc...) and the replica make it happen :) I will look into this, but after a first quick look it turnes out that ipa-replica-manage is already used in other applications, not only by admins on the command line, so probably the changes should be inside ipa-replica-manage and transparent to other apps. > > Cheers, > James > >> Thanks, >> Ludwig >> >> [1] http://www.freeipa.org/page/V4/Manage_replication_topology >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Fri Jul 25 11:29:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 25 Jul 2014 13:29:10 +0200 Subject: [Freeipa-devel] [PATCH] 716 baseldap: return 'none' attr level right as unicode string In-Reply-To: <20140725110242.GR1659@redhat.com> References: <53D237E1.7020204@redhat.com> <20140725110242.GR1659@redhat.com> Message-ID: <53D23F86.6050107@redhat.com> On 25.7.2014 13:02, Alexander Bokovoy wrote: > On Fri, 25 Jul 2014, Petr Vobornik wrote: >> Returning non-unicode causes serialization into base64 which causes >> havoc in Web UI. >> >> https://fedorahosted.org/freeipa/ticket/4454 > ACK for this patch. Pushed to: master: c475c093c9524353be0fbc1d5690a081b0c56cdc ipa-4-1: c475c093c9524353be0fbc1d5690a081b0c56cdc ipa-4-0: a356385f2d73d17ec883d2618d6037efee08f548 > >> >> >> IMHO we should fix JSON-RPC serialization to encode non-unicode >> strings to normal JSON strings. > We should use unicode strings everywhere and leave non-unicode ones to > present binary content, that's why it is encoded as base64. > > So no, we shouldn't change JSON-RPC serialization. However, we need to > find a way to track non-unicode strings where possible. > ok -- Petr Vobornik From mkosek at redhat.com Fri Jul 25 11:38:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 13:38:08 +0200 Subject: [Freeipa-devel] Releasing FreeIPA 4.0.1 In-Reply-To: <20140725111959.GA14057@redhat.com> References: <53D23039.107@redhat.com> <53D23C60.9080204@redhat.com> <20140725111959.GA14057@redhat.com> Message-ID: <53D241A0.8060106@redhat.com> On 07/25/2014 01:19 PM, Alexander Bokovoy wrote: > On Fri, 25 Jul 2014, Ludwig Krispenz wrote: >> >> On 07/25/2014 12:23 PM, Martin Kosek wrote: >>> Hello, >>> >>> As I mentioned earlier, I would like to very soon release FreeIPA 4.0.1 >>> containing the first bunch of stabilization fixes in 4.0 branch. One of the >>> most critical ones were client installation and migration issues which blocked >>> some of our users. Those are now fixed. >>> >>> This is the candidate release notes, updates or feedback welcome: >>> http://www.freeipa.org/page/Releases/4.0.1 >>> >>> Is there anything else you would see as a blocker for release? I plan to move >>> all remaining 4.0.1 Trac milestone tickets to new 4.0.2 milestone which would >>> be released in August. >>> >>> The only think I am now little concerned about is following report for new >>> 389 DS: >>> >>> https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 >>> >>> >>> I can now also see it in my single node server, I am not sure whether it is >>> benign (and annoying) error message or something more serious? Ludwig, is this >>> something that should stall the FreeIPA release? After all, freeipa-server >>> depends on this DS version. >> This message is caused by fix for #47834, it tries to get the connid (for use >> in potential error messages later) and this fails for internal operations, it >> checks this case, but the error message is already logged :-( >> I think you should see this for any internal add/delete/modrdn operation. >> >> It shouldn't cause any problems, but could be very annoying - so it should be >> fixed. If it should hold 4.0.1 or can wait for 4.0.2 is your decision. Cant >> we upgrade DS independently of upgrading to 4.0.2, just when it is available ? > We can upgrade 389-ds independently. Put a warning into FreeIPA 4.0.1 > release notes, explaining the message being harmless and fix 389-ds > asynchronously in Fedora. ACK. I added a Known Issue paragraph to release notes: http://www.freeipa.org/page/Releases/4.0.1#Excessive_logging_by_389-ds-base_1.3.2.20 Martin From rcritten at redhat.com Fri Jul 25 12:50:39 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2014 08:50:39 -0400 Subject: [Freeipa-devel] ipa-replica-manage and topology plugin In-Reply-To: <53D211B5.50002@redhat.com> References: <53D211B5.50002@redhat.com> Message-ID: <53D2529F.2090504@redhat.com> Ludwig Krispenz wrote: > Hi, > I am working on ticket #4302 and am building a protoptype to verify if > the current design [1] will work an what is missing. > > Now the question comes up, how will this be managed and what happens > with eg ipa-replica-manage ? If the topology plugin is deployed and > configured it will control all replication related tasks via > modifcations of the entries in the shared tree, direct modofications of > replication agreements will be rejected. This makes several subcommands > of ipa-replica-manage unusable, like connect/disconnect/... . > So should the functionality of ipa-replica-manage be changed to use the > shared tree or should there be a new command like ipa-topology-manage. > > I would prefere a new command, so ipa-replica-manage is there if the > topology plugin is disabled, also there shoul be some new subcommands > like topology-verify, topology-view ... > > Let me know what you think, > > Thanks, > Ludwig > > [1] http://www.freeipa.org/page/V4/Manage_replication_topology It occurs to me this could make for a bumpy transition. It would mean that an older master can't manage the topology of a new master since ipa-replica-manage on that old master is going to try to make direct changes. So I suppose we need at least good error messages and documentation. Given that when it comes to upgrading we recommending doing it fairly quickly. We can add to that that recommendation any topology management should be done from the newest master. rob From mkosek at redhat.com Fri Jul 25 14:13:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Jul 2014 16:13:17 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.1 Message-ID: <53D265FD.7050702@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.0.1! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 21 or in an unofficial Fedora 20 [https://copr.fedoraproject.org/coprs/pviktori/freeipa/ COPR repository]. These release notes can be read at: http://www.freeipa.org/page/Releases/4.0.1 == Highlights in 4.0.1 == === Enhancements === * TOTP watermark support was added. The last token interval is now being added to database and replicated in FreeIPA realm. Note that the number of writes is kept the same as an unnecessary LDAP write was eliminated. * Effective Attributes widget in the Add Permission Web UI page was improved === Bug fixes === * ipa-client-install is now again able to join older servers (pre-4.0) * Password migration in migrate-ds command was fixed by enabling nsslapd-allow-hashed-passwords setting by default * ipa-client-install no longer crashes during uninstallation when chronyd service cannot be started * Server installation could hang as no members could be added to "cn=adtrust agents" system account * Web UI login page now distinguishes between OTP users with invalid and expired password and properly shows the Reset password dialog * ipa-server-install and ipa-replica-install now better detects when PKI was configured and is able to properly uninstall it when installation crashed == Known Issues == === Excessive logging by 389-ds-base 1.3.2.20 === FreeIPA 4.0.1 pulls 389-ds-base 1.3.2.20 as a dependency ([https://admin.fedoraproject.org/updates/FEDORA-2014-8709/389-ds-base-1.3.2.20-1.fc20 updates-testing repo] in Fedora 20). However, this version of the Directory Server produces following logs for internal write operations: [26/Jul/2014:01:28:53 +0200] - Connection is NULL and hence cannot access SLAPI_CONN_ID This log is [http://www.redhat.com/archives/freeipa-devel/2014-July/msg00388.html benign], Directory Server team tracks the problem in ticket [https://fedorahosted.org/389/ticket/47834 #47834]. == 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-upgradeconfig # ipa-ldap-updater --upgrade 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.0 == === David Kupka (2) === * Fix ipa-client-install --uninstall crash * Always record that pkicreate has been executed. === Gabe (2) === * Fix typos in dns.py * Enable debug pid in smb.conf === Luk?? Slebodn?k (2) === * Fix warning: Using uninitialized value ld. * Add missing break === Martin Ko?ek (2) === * Allow hashed passwords in DS * Become IPA 4.0.1 === Nathaniel McCallum (4) === * Fix login password expiration detection with OTP * Update freeipa-server krb5-server dependency to 1.11.5-5 * Fix ipa-getkeytab for pre-4.0 servers * Add TOTP watermark support === Petr Viktorin (3) === * baseldap: Return empty string when no effective rights are found * ldap2 indirect membership processing: Use global limits if greater than per-query ones * test_xmlrpc: Update tests === Petr Voborn?k (14) === * webui: capitalize labels of undo and undo all buttons * webui: improve usability of attributes widget * webui: add filter to attributes widget * webui: optimize (re)creation of option widget * webui: custom attr in attributes widget * webui: attr widget: get list of possible attrs from ipapermdefaultattr * webui: option_widget_base: sort options * webui: reflect readonly state * webui: fix add of input group class * webui: show managed fields as readonly and not disabled * webui: fix selection of empty value in a select widget * webui: disable ipapermbindruletype if permission in a privilege * webui: fix disabled state of service's PAC type * baseldap: return 'none' attr level right as unicode string === Tom?? Babej (3) === * trusts: Validate missing trust secret properly * ipatests: tasks: Fix dns configuration for trusts * trusts: Make cn=adtrust agents sysaccount nestedgroup -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pspacek at redhat.com Fri Jul 25 17:26:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Jul 2014 19:26:51 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53C78991.1020708@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> Message-ID: <53D2935B.8070706@redhat.com> On 17.7.2014 10:30, Jan Cholasta wrote: > On 16.7.2014 17:13, Petr Spacek wrote: >> On 24.6.2014 08:43, Jan Cholasta wrote: >>> On 20.6.2014 20:23, Simo Sorce wrote: >>>> On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: >>>>> ipk11Private;privatekey: TRUE >>>>> ipk11Private;publickey: FALSE >>>> >>>> can these two ever hold a different value ? >>>> ie a privatekey be FALSE and a publickey be TRUE ? >>>> >>>> If not I suggest you do not add this attribute at all and assume their >>>> value ? >>> >>> +1, we can use default values for most, if not all of the boolean flag >>> attributes. Personally, I would try to avoid using ipk11 attributes >>> until the >>> PKCS#11 module is designed/implemented. >> >> I hope that this will not create headache in future... >> >> Anyway, I have taken default values used by OpenDNSSEC v1 and modified >> them a little bit to accommodate our requirements. >> >> I'm using [1] as reference. >> >> Public keys >> =========== >> CKA_CLASS CKO_PUBLIC_KEY >> CKA_COPYABLE TRUE >> CKA_DERIVE FALSE >> CKA_ENCRYPT FALSE >> CKA_LOCAL TRUE >> CKA_MODIFIABLE TRUE >> CKA_PRIVATE TRUE >> CKA_TRUSTED FALSE >> CKA_VERIFY TRUE >> CKA_VERIFY_RECOVER TRUE >> CKA_WRAP FALSE >> >> >> Private keys >> ============ >> CKA_CLASS CKO_PRIVATE_KEY >> CKA_ALWAYS_AUTHENTICATE FALSE >> CKA_ALWAYS_SENSITIVE TRUE >> CKA_COPYABLE TRUE >> CKA_DECRYPT FALSE >> CKA_DERIVE FALSE >> CKA_EXTRACTABLE TRUE # changed by pspacek >> CKA_LOCAL TRUE >> CKA_MODIFIABLE TRUE >> CKA_NEVER_EXTRACTABLE TRUE >> CKA_PRIVATE TRUE >> CKA_SENSITIVE TRUE >> CKA_SIGN TRUE >> CKA_SIGN_RECOVER TRUE >> CKA_UNWRAP FALSE >> CKA_WRAP_WITH_TRUSTED FALSE > > If you want the keys to be extractable, you also need to set CKA_SENSITIVE > (and CKA_ALWAYS_SENSITIVE) to CK_FALSE. > >> >> We can use this set for all DNSSEC key pair objects. Replica keys will >> require small change, i.e. to change SIGN/VERIFY attributes to FALSE and >> WRAP/UNWRAP attributes to TRUE. > > Replica private keys should not be extractable, i.e. should have > CKA_EXTRACTABLE = CK_FALSE and CKA_SENSITIVE = CK_TRUE. > >> >> OpenDNSSEC itself doesn't create any secret keys so we have to invent >> own defaults. I propose to use following values: >> >> Secret keys >> =========== >> CKA_CLASS CKO_SECRET_KEY >> CKA_COPYABLE TRUE >> CKA_DECRYPT FALSE >> CKA_DERIVE FALSE >> CKA_ENCRYPT FALSE >> CKA_EXTRACTABLE TRUE >> CKA_MODIFIABLE TRUE >> CKA_PRIVATE TRUE >> CKA_SENSITIVE FALSE >> CKA_SIGN FALSE >> CKA_UNWRAP TRUE >> CKA_VERIFY FALSE >> CKA_WRAP TRUE >> CKA_WRAP_WITH_TRUSTED FALSE > > When master key is rotated, CKA_WRAP on the old key should be set to CK_FALSE, > so that new DNSSEC keys can't be wrapped with it. > >> >> >>>> (btw I forgot what's the point of that attribute) >>> >>> When it is true, a user may not access the object until the user has been >>> authenticated to the token (what PKCS#11 spec says). >> >> In practice it means that SoftHSM encrypts values of "PRIVATE" objects >> before storing them to file system. >> >> [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >> > > BTW I have noticed at > > that public key of each replica is stored in a ipk11 entry under cn=DNS. IMO > it should be enough to store just the public key blob in ipaPublicKey > attribute in cn=DNS itself. I have updated design page and diagrams: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 25 17:29:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Jul 2014 19:29:32 +0200 Subject: [Freeipa-devel] DNSSEC key metadata handling In-Reply-To: <53A1CA15.8020402@redhat.com> References: <5399C270.1060608@redhat.com> <1402586393.22737.42.camel@willson.usersys.redhat.com> <5399CC20.9090907@redhat.com> <539B2A3C.80908@redhat.com> <53A1CA15.8020402@redhat.com> Message-ID: <53D293FC.9040106@redhat.com> On 18.6.2014 19:19, Petr Spacek wrote: > On 13.6.2014 18:43, Petr Spacek wrote: >> On 12.6.2014 17:49, Petr Spacek wrote: >>> On 12.6.2014 17:19, Simo Sorce wrote: >>>> On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: >>>>> Hello list, >>>>> >>>>> I have realized that we need to store certain DNSSEC metadata for every >>>>> (zone,key,replica) triplet. It is necessary to handle splits in replication >>>>> topology. >>>>> >>>>> DNSSEC key can be in one of following states: >>>>> - key created >>>>> - published but not used for signing >>>>> - published and used for signing >>>>> - published and not used for signing but old signatures exist >>>>> - unpublished >>>>> >>>>> Every state transition has to be postponed until relevant TTL expires, >>>>> and of >>>>> course, we need to consider TTL on all replicas. >>>>> >>>>> >>>>> Example of a problem >>>>> ==================== >>>>> DNS TTL=10 units >>>>> Key life time=100 units >>>>> >>>>> Replica=1 Key=1 Time=0 Published >>>>> Replica=2 Key=1 Time=0 Published >>>>> Replica=1 Key=1 Time=10 Published, signing >>>>> Replica=2 Key=1 Time=10 Published, signing >>>>> Replica=1 Key=2 Time=90 Generated, published, not signing yet >>>>> Replica=2 Key=2 Time=90 >>>>> Replica=1 Key=1 Time=100 >>>>> ^^^ From time=100, all new signatures should be created with key=2 but that >>>>> can break DNSSEC validation because key=2 is not available on replica=2. >>>> >>>> Can you explain how this break validation ? >>>> Aren't signatures regenerated on each replica ? >>> They are. >>> >>>> And so isn't each replica self-consistent ? >>> Ah, sorry, I didn't mention one important detail. Keys published in the zone >>> 'example.com.' have to match keys published in parent zone. There has to be a >>> mechanism for synchronizing this. >>> >>> Validation will break if (keys published by parent) are not subset of (keys on >>> replicas). >>> >>> Next logical step in the example above is to remove key1 from replica 1 so you >>> will end replica1 having key2 and replica2 having only key1. >>> >>> How can we guarantee that synchronization mechanism will not wipe key1 from >>> parent? Or the other way around? How can we guarantee that key2 was uploaded? >>> >>> Also, things will break is number of keys in parent exceeds reasonable number >>> (because DNS replies will be to big etc.). >>> >>>>> Proposal 1 >>>>> ========== >>>>> - Store state and timestamps for (zone,key,replica) triplet >>>>> - Do state transition only if all triplets (zone,key,?) indicate that all >>>>> replicas reached desired state so the transition is safe. >>>>> - This implicitly means that no transition will happen if one or more >>>>> replicas >>>>> is down. This is necessary otherwise DNSSEC validation can break >>>>> mysteriously >>>>> when keys got out of sync. >>>>> >>>>> dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, >>>>> cn=dns, dc=example >>>>> idnssecKeyCreated: >>>>> idnssecKeyPublished: >>>>> idnssecKeyActivated: >>>>> idnssecKeyInactivated: >>>>> idnssecKeyDeleted: >>>> >>>> Why do you care for all 5 states ? >>> In short, to follow RFC 6781 and all it's requirements. >> >> Simo and I have discussed this off-line. The final decision is to rely on >> replication. The assumption is that if replication is broken, everything will >> break soon anyway, so the original proposal is overkill. >> >> We have to store one set of timestamps somewhere to be able to follow RFC >> 6781, so we decided to store it in the key-metadata object. >> >> I added other attributes to object class definition so it contains all >> necessary metadata. The new object class idnsSecKey is now complete. >> >> Please note that DN in the previous example was incorrect. It is necessary to >> store the metadata separately for pairs (zone, key) to cover the case where >> key is shared between zones. This also nicely splits metadata from actual key >> material. >> >> All attributes are single-valued. >> MUST attributes are: >> idnsSecKeyRef >> idnsSecKeyCreated >> idnsSecAlgorithm >> >> dn: cn=, cn=keys, idnsname=example.com, cn=dns, dc=example >> objectClass: idnsSecKey >> idnsSecKeyRef: >> idnsSecKeyCreated: >> idnsSecKeyPublish: >> idnsSecKeyActivate: >> idnsSecKeyInactive: >> idnsSecKeyDelete: >> idnsSecKeyZone: equivalent to bit 7 (ZONE) in [1] >> idnsSecKeyRevoke: equivalent to bit 8 (REVOKE) in [1] >> idnsSecKeySep: equivalent to bit 15 (SEP) in [1] >> idnsSecAlgorithm: used as mnemonic in [2] > > I haven't heard any complains so I allocated OIDs and I'm going to implement it. Relevant LDAP schema is: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#DNSSECmetadata Me and Honza have discussed off-line that reference from metadata to key material should be in form of PKCS#11 URI so it will work even with real HSM. The new definition is: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#idnsSecKeyRef -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 25 17:43:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Jul 2014 19:43:07 +0200 Subject: [Freeipa-devel] DNSSEC feature status (with pictures!) Message-ID: <53D2972B.6090601@redhat.com> Hello list, Now you have unique chance to stop me before I really implement something (:-), I'm leaving DNSSEC world for a while. I will resume work after two weeks of silence. Status ====== We (Martin Basti and me) have encountered various problems on our way to DNSSEC feature, you can read the summary: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Implementation All necessary patches were submitted upstream. Now we need to really write IPA-code. Design page =========== Design have changed many times so I have drawn new high-level picture for you: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Design This page also describes work flows related to replica management etc. It would be really nice if someone could review the whole design - some aspects have changed significantly. Proof of concept code ===================== (described on design page; for adventurous or archaeologists) https://github.com/spacekpe/openssl/tree/aes_wrap_pad https://github.com/spacekpe/ipadnssecd https://github.com/spacekpe/python-ldap https://github.com/spacekpe/SoftHSMv2/tree/asym_wrap_api https://github.com/spacekpe/SoftHSMv2/tree/asym_wrap.sq https://github.com/spacekpe/SoftHSMv2/tree/cka_sensitive https://github.com/spacekpe/opendnssec/tree/cka_extractable https://github.com/spacekpe/freeipa-pkcs11 https://github.com/spacekpe/dnspython/commits/DNSKEY.flags_to_text_set Have a nice day(s). -- Petr^2 Spacek From edewata at redhat.com Fri Jul 25 20:25:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:25:35 -0500 Subject: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights In-Reply-To: <53CCFAFF.8040306@redhat.com> References: <53BE85DC.5070207@redhat.com> <53C8482E.6020806@redhat.com> <53CCFAFF.8040306@redhat.com> Message-ID: <53D2BD3F.5090009@redhat.com> On 7/21/2014 6:35 AM, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/4380 >> >> This is the original if-condition: >> >> (!rights >> && !(that.flags.indexOf('w_if_no_aci') > -1 >> && write_oc)) >> || (rights && rights.indexOf('w') < 0) >> >> Here if 'rights' has a value but there's no 'w' in it, the expression >> will evaluate to true. >> >> This is the new code: >> >> !can_write >> && !rights >> && !(that.flags.indexOf('w_if_no_aci') > -1 && write_oc) >> >> Here if 'rights' has any value the expression will evaluate to false. Is >> this correct? >> > > You're right, there is an error. Attaching new version. The code is > rewritten to be more comprehensible - use cases are in separate variables. ACK. The code now makes more sense. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:25:42 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:25:42 -0500 Subject: [Freeipa-devel] [PATCH] 709 webui: fix nested items creation in dropdown list In-Reply-To: <53CCFECD.2080208@redhat.com> References: <53CCFECD.2080208@redhat.com> Message-ID: <53D2BD46.2040402@redhat.com> On 7/21/2014 6:51 AM, Petr Vobornik wrote: > Items nested in other items were created in root list instead of nested > list. > > Note: this feature is not used in current UI but it's likely to be used > by a plugin ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:26:42 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:26:42 -0500 Subject: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session In-Reply-To: <53CFB596.4080003@redhat.com> References: <53CFB596.4080003@redhat.com> Message-ID: <53D2BD82.4070700@redhat.com> On 7/23/2014 8:16 AM, Petr Vobornik wrote: > Disable automatic re-execution of command after pending authentication. > > It's possible to enable it again globally by > 'freeipa/config':`rpc_retry_auth`. > > https://fedorahosted.org/freeipa/ticket/4374 > > # Additional info: > This ticket is in 4.0 stabilization milestone. I don't think it's the > best fit. It has a potential to break things. It's also harder to test > because integration tests don't test it - one has to remove session > cookie every time and then react appropriately. > > It's also first usage of ./config module (other items there are not > used). This module was originally implemented to contain global webui > config which could be overwritten by config configured on server, ie for > disabling paging in large deployments. The server part doesn't exist > yet. Other reason is to split ipa.js into more single-purpose files. It works a little bit differently than expected. Right now suppose I'm trying to delete a user, I have the delete dialog open and I let it sit until the session expires, then when I click Delete it will show me a login screen. Once I re-login, the dialog box is gone. It still has the user to be deleted selected, but there's no indication what the operation I was trying to do before. I was thinking the session expiration would work like desktop screensaver lock. So when I re-login I would see same screen as I left it, i.e. the delete dialog is still waiting for action. The patch itself is fine, so it's ACKed, but I'll let you decide if this is sufficient to close the bug. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:26:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:26:51 -0500 Subject: [Freeipa-devel] [PATCH] 711 webui: internet explorer fixes In-Reply-To: <53D13617.2070204@redhat.com> References: <53CFB5EA.7070904@redhat.com> <53D13617.2070204@redhat.com> Message-ID: <53D2BD8B.205@redhat.com> On 7/24/2014 11:36 AM, Petr Vobornik wrote: > On 23.7.2014 15:17, Petr Vobornik wrote: >> Fixed: >> 1. IE doesn't support value 'initial' in CSS rule. >> 2. setting innerHTML='' also destroys content of child nodes in >> LoginScreen in IE -> reattached buttons have no text. >> >> Should go into 4.0 Milestone > > Found an issue in the implementation, new version attached. ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:27:09 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:27:09 -0500 Subject: [Freeipa-devel] [PATCH] 712 webui: detach facet nodes In-Reply-To: <53CFB7BB.3090206@redhat.com> References: <53CFB7BB.3090206@redhat.com> Message-ID: <53D2BD9D.70909@redhat.com> On 7/23/2014 8:25 AM, Petr Vobornik wrote: > Detach/attach facet nodes when switching facets instead of > hiding/showing. > > Keeps dom-tree more simple. > > > This patch is not really needed. I implemented it while testing > something in IE. But it might have positive effect for poorly written > parts of Web UI(if there are any :) ) or plugins. Basically it > simplifies DOM tree to contain nodes only for the active facet. > Therefore ugly expressions like $('button .foobar') are much more > performant. ACK. In the future the entire facet itself probably can even be loaded dynamically, so this is a step in that direction. The "facet" element itself probably can be merged with the "content" element since there's only one facet/content at any time. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:27:17 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:27:17 -0500 Subject: [Freeipa-devel] [PATCH] 713-714 webui: replace action_buttons with action_widget In-Reply-To: <53CFB81D.50609@redhat.com> References: <53CFB81D.50609@redhat.com> Message-ID: <53D2BDA5.10000@redhat.com> On 7/23/2014 8:26 AM, Petr Vobornik wrote: > [PATCH] 713 webui: replace action_buttons with action_widget > > Simplify code base by reuse of 'disable' feature of button_widget. All > occurrences of action-button which were disabled/enabled were replaced > by button-widget. > > https://fedorahosted.org/freeipa/ticket/4258 > > [PATCH] 714 webui: remove remaining action-button-disabled occurrences > > Buttons in hbactest check for 'action-button-disabled' but it's never set. > > https://fedorahosted.org/freeipa/ticket/4258 ACK. -- Endi S. Dewata From edewata at redhat.com Fri Jul 25 20:27:33 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 Jul 2014 15:27:33 -0500 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html In-Reply-To: <53CFCDD2.3000606@redhat.com> References: <53CFCDD2.3000606@redhat.com> Message-ID: <53D2BDB5.5080109@redhat.com> On 7/23/2014 9:59 AM, Petr Vobornik wrote: > reset_password.html now redirects browser to URL specified in 'redirect' > uri component (if present). > > The component has to be URI encoded. ie (in browser console): > > $ > encodeURIComponent('http://pvoborni.fedorapeople.org/doc/#!/guide/Debugging') > > > --> > "http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging" > > --> > > https://my.freeipa.server/ipa/ui/reset_password.html?redirect=http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging > > > https://fedorahosted.org/freeipa/ticket/4440 ACK. Just one thing, there is no pause between clicking the Reset button and the redirection, so the "Password reset was successful." confirmation message might only appear very briefly. A possible alternative is to show a confirmation page/message, but the user will have to click to continue to the next page. -- Endi S. Dewata From invite at feedspotmailer.com Sat Jul 26 11:53:20 2014 From: invite at feedspotmailer.com (farzad niazmand via Feedspot) Date: Sat, 26 Jul 2014 11:53:20 +0000 Subject: [Freeipa-devel] farzad niazmand is still waiting for you to join Feedspot... Message-ID: <000001477284a31a-23a44bd3-aca2-41eb-bc51-b1fed8f2aa93-000000@email.amazonses.com>
farzad niazmand is still waiting for you to join Feedspot - A place to organize and read all the sites you visit in one place. Feedspot makes checking your favorite sites as easy as checking your email.
www.feedspot.com

Start using Feedspot today to get a complimentary Feedspot Premium membership for one year for free, with even more of the features that make Feedspot great. And just for trying Feedspot, your friend will also get rewards.




- The Feedspot Team


This email was sent to freeipa-devel at redhat.com. You are receiving pending invitation emails.
You received this email because your friend farzad niazmand (farzad.niazmand at gmail.com) invited you to join Feedspot.
Click here to Unsubscribe if you wish not to receive pending invitation from farzad niazmand via Feedspot.
Feedspot.com, 303 Cape Court, Mill Valley, CA 94941
-------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Jul 28 08:17:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:17:05 +0200 Subject: [Freeipa-devel] [PATCH] webui: 696 support wildcard attribute level rights In-Reply-To: <53D2BD3F.5090009@redhat.com> References: <53BE85DC.5070207@redhat.com> <53C8482E.6020806@redhat.com> <53CCFAFF.8040306@redhat.com> <53D2BD3F.5090009@redhat.com> Message-ID: <53D60701.7080309@redhat.com> On 25.7.2014 22:25, Endi Sukma Dewata wrote: > On 7/21/2014 6:35 AM, Petr Vobornik wrote: >>>> https://fedorahosted.org/freeipa/ticket/4380 >> >> You're right, there is an error. Attaching new version. The code is >> rewritten to be more comprehensible - use cases are in separate >> variables. > > ACK. The code now makes more sense. > Pushed to: master: 855c59c7fcbeaa8f1caff6c3e5c61b0524eab53d ipa-4-1: 855c59c7fcbeaa8f1caff6c3e5c61b0524eab53d ipa-4-0: 8d4653537665ee7a9323e79eacbc3468df0ba394 -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 08:19:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:19:21 +0200 Subject: [Freeipa-devel] [PATCH] 709 webui: fix nested items creation in dropdown list In-Reply-To: <53D2BD46.2040402@redhat.com> References: <53CCFECD.2080208@redhat.com> <53D2BD46.2040402@redhat.com> Message-ID: <53D60789.7010703@redhat.com> On 25.7.2014 22:25, Endi Sukma Dewata wrote: > On 7/21/2014 6:51 AM, Petr Vobornik wrote: >> Items nested in other items were created in root list instead of nested >> list. >> >> Note: this feature is not used in current UI but it's likely to be used >> by a plugin > > ACK. > Pushed to: ipa-4-0: 4bdc7a44e051a712995a0af44b798b72c8f9714a ipa-4-1: 4059aa12a4487c925472751b132842bdb0b16a02 master: 4059aa12a4487c925472751b132842bdb0b16a0 -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 08:20:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:20:59 +0200 Subject: [Freeipa-devel] [PATCH] 711 webui: internet explorer fixes In-Reply-To: <53D2BD8B.205@redhat.com> References: <53CFB5EA.7070904@redhat.com> <53D13617.2070204@redhat.com> <53D2BD8B.205@redhat.com> Message-ID: <53D607EB.3030506@redhat.com> On 25.7.2014 22:26, Endi Sukma Dewata wrote: > On 7/24/2014 11:36 AM, Petr Vobornik wrote: >> On 23.7.2014 15:17, Petr Vobornik wrote: >>> Fixed: >>> 1. IE doesn't support value 'initial' in CSS rule. >>> 2. setting innerHTML='' also destroys content of child nodes in >>> LoginScreen in IE -> reattached buttons have no text. >>> >>> Should go into 4.0 Milestone >> >> Found an issue in the implementation, new version attached. > > ACK. > Pushed to: ipa-4-0: f1b4dfcfe1b734520c6c3e950696735919317a16 ipa-4-1: fb975bba2076758f0615dae042aed2cde705a1b0 master: fb975bba2076758f0615dae042aed2cde705a1b0 -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 08:23:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:23:19 +0200 Subject: [Freeipa-devel] [PATCH] 712 webui: detach facet nodes In-Reply-To: <53D2BD9D.70909@redhat.com> References: <53CFB7BB.3090206@redhat.com> <53D2BD9D.70909@redhat.com> Message-ID: <53D60877.2080909@redhat.com> On 25.7.2014 22:27, Endi Sukma Dewata wrote: > On 7/23/2014 8:25 AM, Petr Vobornik wrote: >> Detach/attach facet nodes when switching facets instead of >> hiding/showing. >> >> Keeps dom-tree more simple. >> >> >> This patch is not really needed. I implemented it while testing >> something in IE. But it might have positive effect for poorly written >> parts of Web UI(if there are any :) ) or plugins. Basically it >> simplifies DOM tree to contain nodes only for the active facet. >> Therefore ugly expressions like $('button .foobar') are much more >> performant. > > ACK. In the future the entire facet itself probably can even be loaded > dynamically, so this is a step in that direction. The "facet" element > itself probably can be merged with the "content" element since there's > only one facet/content at any time. > Pushed to: ipa-4-0: ee61651bc9667462dec8e6dd2e64dbfeb249deed ipa-4-1: 9aed114d822efb0eaa01d93624bc0ea6612c4169 master: 9aed114d822efb0eaa01d93624bc0ea6612c4169 -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 08:25:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:25:09 +0200 Subject: [Freeipa-devel] [PATCH] 713-714 webui: replace action_buttons with action_widget In-Reply-To: <53D2BDA5.10000@redhat.com> References: <53CFB81D.50609@redhat.com> <53D2BDA5.10000@redhat.com> Message-ID: <53D608E5.60205@redhat.com> On 25.7.2014 22:27, Endi Sukma Dewata wrote: > On 7/23/2014 8:26 AM, Petr Vobornik wrote: >> [PATCH] 713 webui: replace action_buttons with action_widget >> >> Simplify code base by reuse of 'disable' feature of button_widget. All >> occurrences of action-button which were disabled/enabled were replaced >> by button-widget. >> >> https://fedorahosted.org/freeipa/ticket/4258 >> >> [PATCH] 714 webui: remove remaining action-button-disabled occurrences >> >> Buttons in hbactest check for 'action-button-disabled' but it's never >> set. >> >> https://fedorahosted.org/freeipa/ticket/4258 > > ACK. > pushed to: master: * 3966417779910a7f8ced411cbcdac4cb04145038 webui: replace action_buttons with action_widget * ac7df79a43732cead50f83e31220b0bf2d0230f4 webui: remove remaining action-button-disabled occurrences ipa-4-1: * 3966417779910a7f8ced411cbcdac4cb04145038 webui: replace action_buttons with action_widget * ac7df79a43732cead50f83e31220b0bf2d0230f4 webui: remove remaining action-button-disabled occurrences ipa-4-0: * 9cbe6b16c7c5cb63ab2dd6da4a7103ef5ba3e4cb webui: replace action_buttons with action_widget * bf9c254c9780e3bc485e9a8fb613a3dd31b3a568 webui: remove remaining action-button-disabled occurrences -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 08:58:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 10:58:20 +0200 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html In-Reply-To: <53D2BDB5.5080109@redhat.com> References: <53CFCDD2.3000606@redhat.com> <53D2BDB5.5080109@redhat.com> Message-ID: <53D610AC.6020505@redhat.com> On 25.7.2014 22:27, Endi Sukma Dewata wrote: > On 7/23/2014 9:59 AM, Petr Vobornik wrote: >> reset_password.html now redirects browser to URL specified in 'redirect' >> uri component (if present). >> >> The component has to be URI encoded. ie (in browser console): >> >> $ >> encodeURIComponent('http://pvoborni.fedorapeople.org/doc/#!/guide/Debugging') >> >> >> >> --> >> "http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging" >> >> --> >> >> https://my.freeipa.server/ipa/ui/reset_password.html?redirect=http%3A%2F%2Fpvoborni.fedorapeople.org%2Fdoc%2F%23!%2Fguide%2FDebugging >> >> >> >> https://fedorahosted.org/freeipa/ticket/4440 > > ACK. Pushed to: master: 8288135b5b218cd63d5f5bfba59f6d1f9657af2d ipa-4-1: 8288135b5b218cd63d5f5bfba59f6d1f9657af2d Not closing the ticket yet. > Just one thing, there is no pause between clicking the Reset button > and the redirection, so the "Password reset was successful." > confirmation message might only appear very briefly. A possible > alternative is to show a confirmation page/message, but the user will > have to click to continue to the next page. > I don't believe there is a universal solution. I would say that it depends on personal preferences and a use case. I.e., if it's part of a login procedure I would prefer immediate redirection back to login page. If it's invoked from a user action - just to change the password, some delay might be good. We might add a URL param(s) to configure the delay/link. -- Petr Vobornik From simo at redhat.com Mon Jul 28 09:04:04 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Jul 2014 05:04:04 -0400 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53D2935B.8070706@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> Message-ID: <1406538244.25911.9.camel@willson.usersys.redhat.com> On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote: > > I have updated design page and diagrams: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema Excellent page, I took a full read and it all seem reasonable. However I would like a page like this with the detailed summary of key material handling. This is important to get right and have documented anyway so if someone could summarize in detail all the key handling I would be happy to do a detailed review and think carefully about the security stance of the final solution we agreed on. If we can do this early it would be better to avoid costly rewrites should we have forgotten/underestimated some implementation detail that requires changes. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Jul 28 10:19:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 12:19:26 +0200 Subject: [Freeipa-devel] [PATCH 0243] ipalib: idrange: Make non-implemented range types fail the In-Reply-To: <53CCC84D.7010106@redhat.com> References: <53C66A91.5030203@redhat.com> <53CCC84D.7010106@redhat.com> Message-ID: <53D623AE.3000804@redhat.com> On 07/21/2014 09:59 AM, Jan Cholasta wrote: > Hi, > > On 16.7.2014 14:05, Tomas Babej wrote: >> Hi, >> >> The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to >> pass the validation tests, however, they are not implemented nor >> checked by the 389 server plugin. >> >> https://fedorahosted.org/freeipa/ticket/4323 > > ACK. > Pushed to: master: e74307caa6daf1e7e261ff481f6c5b089df82f57 ipa-4-1: e74307caa6daf1e7e261ff481f6c5b089df82f57 ipa-4-0: fb89a774e331c3b3eb70950911e4136a7e1f141b -- Petr? From pvoborni at redhat.com Mon Jul 28 11:06:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 13:06:13 +0200 Subject: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session In-Reply-To: <53D2BD82.4070700@redhat.com> References: <53CFB596.4080003@redhat.com> <53D2BD82.4070700@redhat.com> Message-ID: <53D62EA5.7010808@redhat.com> On 25.7.2014 22:26, Endi Sukma Dewata wrote: > On 7/23/2014 8:16 AM, Petr Vobornik wrote: >> Disable automatic re-execution of command after pending authentication. >> >> It's possible to enable it again globally by >> 'freeipa/config':`rpc_retry_auth`. >> >> https://fedorahosted.org/freeipa/ticket/4374 >> >> # Additional info: >> This ticket is in 4.0 stabilization milestone. I don't think it's the >> best fit. It has a potential to break things. It's also harder to test >> because integration tests don't test it - one has to remove session >> cookie every time and then react appropriately. >> >> It's also first usage of ./config module (other items there are not >> used). This module was originally implemented to contain global webui >> config which could be overwritten by config configured on server, ie for >> disabling paging in large deployments. The server part doesn't exist >> yet. Other reason is to split ipa.js into more single-purpose files. > > It works a little bit differently than expected. > > Right now suppose I'm trying to delete a user, I have the delete dialog > open and I let it sit until the session expires, then when I click > Delete it will show me a login screen. Once I re-login, the dialog box > is gone. It still has the user to be deleted selected, but there's no > indication what the operation I was trying to do before. > > I was thinking the session expiration would work like desktop > screensaver lock. So when I re-login I would see same screen as I left > it, i.e. the delete dialog is still waiting for action. > Components have not been made with this feature in mind. Take for example the delete issue. Deleter dialog is a subclass of confirm dialog. Confirm dialog is closed right after confirmation/cancellation. It doesn't wait for the result of the operation because it's handled by other components. The behavior was OK so far because we showed error dialog on "normal" error. On auth error, the command was re-executed. Now we don't show any error on auth error nor we leave the dialog open. Seems like that we should change all usages of confirm dialog to try to do the operation first and close the dialog after the operation was successful or canceled. But this is only one set of use cases. There might/will be others we don't know about atm. Proper solution is to test all Web UI features (or feature sets) with expired session (deletion of cookie) and identify the issues. Then address the identified issues - much bigger task then this simple patch. I think it is not good to push this patch without fixing the issues and definitely not into stabilization release (4.0). I propose to move this ticket into 4.1 or maybe even 4.2. Fix other tickets in the milestone and then return to this one. I'm giving it lower priority because I didn't see many people complaining about current behavior. > The patch itself is fine, so it's ACKed, but I'll let you decide if this > is sufficient to close the bug. > I'll postpone the push until solution for the issue above is made. -- Petr Vobornik From pvoborni at redhat.com Mon Jul 28 12:11:51 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 28 Jul 2014 14:11:51 +0200 Subject: [Freeipa-devel] [PATCH] 712 webui: detach facet nodes In-Reply-To: <53D2BD9D.70909@redhat.com> References: <53CFB7BB.3090206@redhat.com> <53D2BD9D.70909@redhat.com> Message-ID: <53D63E07.4040604@redhat.com> On 25.7.2014 22:27, Endi Sukma Dewata wrote: > On 7/23/2014 8:25 AM, Petr Vobornik wrote: >> Detach/attach facet nodes when switching facets instead of >> hiding/showing. >> >> Keeps dom-tree more simple. >> >> >> This patch is not really needed. I implemented it while testing >> something in IE. But it might have positive effect for poorly written >> parts of Web UI(if there are any :) ) or plugins. Basically it >> simplifies DOM tree to contain nodes only for the active facet. >> Therefore ugly expressions like $('button .foobar') are much more >> performant. > > ACK. In the future the entire facet itself probably can even be loaded > dynamically, so this is a step in that direction. The "facet" element > itself probably can be merged with the "content" element since there's > only one facet/content at any time. > Btw, what do you mean by "loaded dynamically"? Loading of source files on demand or just instantiating of facets or something else? The latter is partially implemented (facets of given entity are instantiated when one of them is requested). Loading of source files might be little bit more difficult since we have entity-centered sources and some information from all entities are required right at the start of the app, e.g. for menu. -- Petr Vobornik From pviktori at redhat.com Mon Jul 28 12:11:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 14:11:51 +0200 Subject: [Freeipa-devel] [PATCH 0101] Allow to add host if AAAA record exists In-Reply-To: <53BD6DD4.8060903@redhat.com> References: <53BD6DD4.8060903@redhat.com> Message-ID: <53D63E07.4060400@redhat.com> On 07/09/2014 06:29 PM, Martin Basti wrote: > Patch attached. > Ticket: https://fedorahosted.org/freeipa/ticket/4164 > Looks & works fine for me. Can you also add a test for this? -- Petr? From pviktori at redhat.com Mon Jul 28 13:03:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 15:03:34 +0200 Subject: [Freeipa-devel] [PATCH 0242] Set the default attributes for RootDSE In-Reply-To: <53C4D49F.5010908@redhat.com> References: <53C4D49F.5010908@redhat.com> Message-ID: <53D64A26.70106@redhat.com> On 07/15/2014 09:13 AM, Tomas Babej wrote: > Hi, > > With 389 DS 1.3.3 upwards we can leverage the nsslapd-return-default-opattr > attribute to enumerate the list of attributes that should be returned > even if not specified explicitly. Use the behaviour to get the same > attributes > returned from searches on rootDSE as in 1.3.1. > > https://fedorahosted.org/freeipa/ticket/4288 This fails with an older DS version. Running transaction (shutdown inhibited) Updating : freeipa-python-4.0.0GITa2b91d7-0.fc20.x86_64 1/14 Updating : freeipa-client-4.0.0GITa2b91d7-0.fc20.x86_64 2/14 Could not load host key: /etc/ssh/ssh_host_dsa_key Updating : freeipa-admintools-4.0.0GITa2b91d7-0.fc20.x86_64 3/14 Updating : freeipa-server-4.0.0GITa2b91d7-0.fc20.x86_64 4/14 Updating : freeipa-server-trust-ad-4.0.0GITa2b91d7-0.fc20.x86_64 5/14 Updating : freeipa-tests-4.0.0GITa2b91d7-0.fc20.x86_64 6/14 Updating : freeipa-debuginfo-4.0.0GITa2b91d7-0.fc20.x86_64 7/14 Cleanup : freeipa-tests-4.0.0GIT06aa522-0.fc20.x86_64 8/14 Cleanup : freeipa-debuginfo-4.0.0GIT06aa522-0.fc20.x86_64 9/14 Cleanup : freeipa-server-trust-ad-4.0.0GIT06aa522-0.fc20.x86_64 10/14 Cleanup : freeipa-server-4.0.0GIT06aa522-0.fc20.x86_64 11/14 Cleanup : freeipa-admintools-4.0.0GIT06aa522-0.fc20.x86_64 12/14 Cleanup : freeipa-client-4.0.0GIT06aa522-0.fc20.x86_64 13/14 Cleanup : freeipa-python-4.0.0GIT06aa522-0.fc20.x86_64 14/14 Upgrade failed with attribute "nsslapd-return-default-opattr" not allowed IPA upgrade failed. You'll need to update the spec file too, at least. -- Petr? From pviktori at redhat.com Mon Jul 28 13:22:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 15:22:30 +0200 Subject: [Freeipa-devel] [PATCH 0243] ipalib: idrange: Make non-implemented range types fail the In-Reply-To: <53D623AE.3000804@redhat.com> References: <53C66A91.5030203@redhat.com> <53CCC84D.7010106@redhat.com> <53D623AE.3000804@redhat.com> Message-ID: <53D64E96.6030008@redhat.com> On 07/28/2014 12:19 PM, Petr Viktorin wrote: > On 07/21/2014 09:59 AM, Jan Cholasta wrote: >> Hi, >> >> On 16.7.2014 14:05, Tomas Babej wrote: >>> Hi, >>> >>> The ipa-ipa-trust and ipa-ad-winsync ID Range types were allowed to >>> pass the validation tests, however, they are not implemented nor >>> checked by the 389 server plugin. >>> >>> https://fedorahosted.org/freeipa/ticket/4323 >> >> ACK. >> > > Pushed to: > master: e74307caa6daf1e7e261ff481f6c5b089df82f57 > ipa-4-1: e74307caa6daf1e7e261ff481f6c5b089df82f57 > ipa-4-0: fb89a774e331c3b3eb70950911e4136a7e1f141b > You forgot to update API.txt. Fixed with the attached patch, pushed as a one-liner to: master: ab5edd0e450fdd926b7c49535424149413c3f956 ipa-4-1: ab5edd0e450fdd926b7c49535424149413c3f956 ipa-4-0: 4baf1531581bbc5d075d46a832ca139edc8e75d3 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0623-Update-API.txt.patch Type: text/x-patch Size: 2622 bytes Desc: not available URL: From pviktori at redhat.com Mon Jul 28 15:43:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 17:43:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0102-0103 DNS upgrade: add missing tests if DNS is installed In-Reply-To: <53CFB366.6090000@redhat.com> References: <53CFB366.6090000@redhat.com> Message-ID: <53D66FA8.2040804@redhat.com> On 07/23/2014 03:06 PM, Martin Basti wrote: > This should be applied in 4.0.x, 4.1, master > > Patches attached > Thanks! ACK, pushed to: master: 42d035f64c4d41bbae5fe061805b2de6febe2c7e ipa-4-0: 1f5ad2e2cea55d6e059ee406822a30202e2bc0c6 ipa-4-1: 42d035f64c4d41bbae5fe061805b2de6febe2c7e -- Petr? From pviktori at redhat.com Mon Jul 28 15:47:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 17:47:55 +0200 Subject: [Freeipa-devel] [PATCH 0026][DOC] Type in sudocmd in documentation In-Reply-To: References: Message-ID: <53D670AB.1070800@redhat.com> On 07/24/2014 12:30 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4451 > > Thanks, > > Gabe Thank you! Pushed to docs master: 16f7ff509147c46b1b7188e131e948432ca9bfaf -- Petr? From pviktori at redhat.com Mon Jul 28 16:41:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 18:41:24 +0200 Subject: [Freeipa-devel] [PATCH] 0007 test group: remove group from protected group In-Reply-To: <53D105F1.8080907@redhat.com> References: <53D105F1.8080907@redhat.com> Message-ID: <53D67D34.8000202@redhat.com> On 07/24/2014 03:11 PM, David Kupka wrote: > Simple test scenario from ticket #4448. > > Last test will fail until patch freeipa-dkupka-0006 gets accepted. > Thanks! These look fine, but since the new tests don't require that the rest of `test_group` is run first, I encourage you to put them in a separate class. This would ensure we don't add new inderdependencies between old and new tests in the future, making future test refactoring more straightforward. Also, you can select to run just a single test class from a module, so testing a targeted fix is faster. (And you can reuse group1, since the other test cleans it up) See test_permission_plugin for an example. -- Petr? From edewata at redhat.com Mon Jul 28 17:01:12 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 28 Jul 2014 12:01:12 -0500 Subject: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session In-Reply-To: <53D62EA5.7010808@redhat.com> References: <53CFB596.4080003@redhat.com> <53D2BD82.4070700@redhat.com> <53D62EA5.7010808@redhat.com> Message-ID: <53D681D8.2040805@redhat.com> On 7/28/2014 6:06 AM, Petr Vobornik wrote: >> Right now suppose I'm trying to delete a user, I have the delete dialog >> open and I let it sit until the session expires, then when I click >> Delete it will show me a login screen. Once I re-login, the dialog box >> is gone. It still has the user to be deleted selected, but there's no >> indication what the operation I was trying to do before. >> >> I was thinking the session expiration would work like desktop >> screensaver lock. So when I re-login I would see same screen as I left >> it, i.e. the delete dialog is still waiting for action. > > Components have not been made with this feature in mind. Take for > example the delete issue. Deleter dialog is a subclass of confirm > dialog. Confirm dialog is closed right after confirmation/cancellation. > It doesn't wait for the result of the operation because it's handled by > other components. The behavior was OK so far because we showed error > dialog on "normal" error. On auth error, the command was re-executed. > Now we don't show any error on auth error nor we leave the dialog open. > Seems like that we should change all usages of confirm dialog to try to > do the operation first and close the dialog after the operation was > successful or canceled. Not sure about that. If you're adding a user that already exists, you'll get an error dialog, but then if you click Cancel you'll go back to the same add dialog. That allows you to revise the info you entered. Can we use the same concept for session expiration? So instead of an error dialog you'll get a login screen. If you relogin as the same person, you'll go back to the same dialog with whatever info you already entered. This is a low priority regardless. -- Endi S. Dewata From edewata at redhat.com Mon Jul 28 17:08:53 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 28 Jul 2014 12:08:53 -0500 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html In-Reply-To: <53D610AC.6020505@redhat.com> References: <53CFCDD2.3000606@redhat.com> <53D2BDB5.5080109@redhat.com> <53D610AC.6020505@redhat.com> Message-ID: <53D683A5.7080606@redhat.com> On 7/28/2014 3:58 AM, Petr Vobornik wrote: >> Just one thing, there is no pause between clicking the Reset button >> and the redirection, so the "Password reset was successful." >> confirmation message might only appear very briefly. A possible >> alternative is to show a confirmation page/message, but the user will >> have to click to continue to the next page. > > I don't believe there is a universal solution. I would say that it > depends on personal preferences and a use case. I.e., if it's part of a > login procedure I would prefer immediate redirection back to login page. > If it's invoked from a user action - just to change the password, some > delay might be good. > > We might add a URL param(s) to configure the delay/link. How about 2 URL params? 1. the link to the next page 2. an option whether to a) redirect to the link immediately b) show a confirmation page with the link Just my preference, but I don't really like a 'delay' on a web page. It's either too short or too long, and we can't put important info during the delay because there's no guarantee people will see it. -- Endi S. Dewata From pviktori at redhat.com Mon Jul 28 17:29:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 19:29:08 +0200 Subject: [Freeipa-devel] [PATCH] 309 Check if /root/ipa.csr exists when installing server with external CA In-Reply-To: <53D11B43.80100@redhat.com> References: <53D11B43.80100@redhat.com> Message-ID: <53D68864.3040300@redhat.com> On 07/24/2014 04:42 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Thanks! ACK, pushed to: master: 131353773643c5a7e0b155486759e6f6103cbee4 ipa-4-1: 131353773643c5a7e0b155486759e6f6103cbee4 ipa-4-0: 28aed7b89597ee54a7b3de9b17ca426b712761ce -- Petr? From pviktori at redhat.com Mon Jul 28 17:59:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Jul 2014 19:59:24 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap In-Reply-To: <53D12736.9000409@redhat.com> References: <53D12736.9000409@redhat.com> Message-ID: <53D68F7C.5040006@redhat.com> On 07/24/2014 05:33 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > NACK If the value *is* a str, with this patch it ends up undefined. -- Petr? From rcritten at redhat.com Mon Jul 28 19:39:40 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Jul 2014 15:39:40 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53CFAA02.9050607@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> Message-ID: <53D6A6FC.6020908@redhat.com> Jan Cholasta wrote: > On 22.7.2014 15:21, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 2.7.2014 19:37, Jan Cholasta wrote: >>>>> On 2.7.2014 19:08, Rob Crittenden wrote: >>>>>> Trimming to respond to your questions. >>>>>>>> Not sure if this is related: >>>>>>>> # pki cert-find >>>>>>>> PKIException: Internal Server Error >>>>>> >>>>>> I'm pretty sure the cert-find error is related to the fact that I >>>>>> had a >>>>>> test build of dogtag installed, so that can be ignored. >>>>> >>>>> It does not work for me as well, with the current F20 dogtag packages, >>>>> but like I said, it worked some time ago. >>>> >>>> Still haven't figured this out, unfortunately. > > Fixed. Part of the problem was that the validation code I used on CA > certificates was too tolerant (fixed in patches 249 and 251). Another > part was the NSS validation code that Dogtag uses requires the issuing > CA to be present in the NSS database (fixed in patch 306). Finally, > Dogtag uses default NSS certificate path validation, which means you > have to either keep all versions of the CA certificate in the NSS > database, or enable PKIX path validation in NSS. Certmonger does not > like having multiple versions of a certificate it is tracking in the > database, so I have gone the PKIX route (patch 307). > >>>> >>>> Added patches 304 and 305 to fix /etc/ipa/ca.crt not having all the CA >>>> certificates on master. >>>> >>>> Updated rebased patches attached. The correct order to apply is >>>> 295-294, >>>> 303-305, 295-299. >>>> >>> >>> 251 I'm a little confused about the profile names. I see you changed the >>> renewal profile from ipaCACertRenewal to caCACert which I guess makes >>> sense. I don't see a ipaCACertRenewal profile. There is still a >>> reference to a ipaRetrieval profile, what is that? > > Oops, I forgot to mention that, I guess I shouldn't post patches at such > late hour :) Sorry. > > ipaCACertRenewal should be used only for automatic renewal, not for > manual. It calls caCACert and ipaRetrieval internally, but there are > some conditions, which don't apply to manual renewal. It's a change I > forgot to make before, so I made it now when I noticed it. ipaRetrieval > fetches the certificate from cn=ca_renewal, i.e. what > dogtag-ipa-retrieve-agent-submit used to do. > >>> >>> ACK to the changes in 291 >>> >>> 299 I guess you added the check for existing certs to avoid conflicts? I >>> guess it means that a user is hosed if they chose the same name for >>> their CA that we use? I think you're missing a sys.exit(1) here. > > Yes. It is a poor man's solution, but it would take time to make > something better. (I can deal with nickname conflicts rather easy by > renaming the certificates, but handling subject conflict would require > removing the old certificate from the certificate store, which is not > yet supported.) > > Fixed missing exit. > >>> >>> 303 Looks good. The man page is still a little thin >>> >>> 304 Not to be too pedantic but if removing the old CACERT fails >>> (SELinux, immutable file) then the install will blow up and this is the >>> very end. I think the removal should happen earlier, before anything >>> else happens. That way at least you don't wait 10 minuts to find out the >>> install failed. > > I switched to overwriting the file instead. It is created/written a few > lines above, so if it shall fail, it will fail there. > >>> >>> 305 ACK >>> >>> I didn't have a ton of time to test but a basic install fails with: >>> >>> 2014-07-03T21:44:49Z DEBUG stderr= >>> 2014-07-03T21:44:49Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 640, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-server-install", line 1046, in main >>> dm_password, subject_base=options.subject) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>> 489, in configure_instance >>> self.start_creation(runtime=210) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 382, in start_creation >>> method() >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>> 1041, in __import_ca_chain >>> (rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", >>> line 79, in get_cert_nickname >>> nsscert = x509.load_certificate(cert) >>> >>> File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 119, in >>> load_certificate >>> return nss.Certificate(buffer(data)) >>> >>> 2014-07-03T21:44:49Z DEBUG The ipa-server-install command failed, >>> exception: NSPRError: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are >>> attempting to import a cert with the same issuer/serial as an existing >>> cert, but that is not the same cert. >> >> I haven't gotten much further than this. I spent some time trying to >> find the a change that would cause it and came up empty. Once this bug >> shows, it always shows, but it can go away at times too which is just >> blowing my little mind. >> >> For example, I tried rolling the patches back one at a time (revert, >> build, install, repeat). It failed even back to the point where I knew >> things should be working. I installed 3.3.5, then tried the current >> build, which had failed before, and it worked. So there is some odd >> transient thing going on that I can't wrap my head around. > > I have not yet seen this failure myself. > > It looks like NSS internally imports the certificate, which conflicts > with the database NSS is initialized with. Perhaps a well placed > nss_shutdown() might fix this? Maybe using NSS contexts instead of > global initialization could help. > >> >> rob >> > > I have taken your advice and don't touch trust flags on unknown CA certs > on upgrades anymore. I have also made a number of little tweaks. > > Updated rebased patches attached. > This is oh-so close. AFAICT it generally does what it should, I think it is ready for a wider audience. Just a few more things: 306: A while True loop is used for something which AFAICT can only ever execute once. I'd think something like this is more readable: for ca_nick, ca_flags in db.list_certs(): if db.has_nickname(ca_cert): try: db.delete_cert(ca_nick) except ipautil.CalledProcessError: syslog.syslog( syslog.LOG_ERR, "Failed to remove certificate %s" % ca_nick) +1 on the additional syslogs. It will help figure out what's going on if things go sideways. Otherwise things seem to be working. I think that fixing the above is enough for a +57 with the promise of unit tests to back up some of these new functions. rob rob From jcholast at redhat.com Tue Jul 29 06:27:56 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 08:27:56 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap In-Reply-To: <53D68F7C.5040006@redhat.com> References: <53D12736.9000409@redhat.com> <53D68F7C.5040006@redhat.com> Message-ID: <53D73EEC.6090607@redhat.com> Dne 28.7.2014 v 19:59 Petr Viktorin napsal(a): > On 07/24/2014 05:33 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > NACK > If the value *is* a str, with this patch it ends up undefined. > Right, fixed. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-310.1-Exclude-attributelevelrights-from-raw-result-process.patch Type: text/x-patch Size: 1276 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 29 06:46:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 08:46:57 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1406538244.25911.9.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> Message-ID: <53D74361.1060001@redhat.com> Dne 28.7.2014 v 11:04 Simo Sorce napsal(a): > On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote: >> >> I have updated design page and diagrams: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema > > Excellent page, I took a full read and it all seem reasonable. > > However I would like a page like this with the detailed summary of key > material handling. > > This is important to get right and have documented anyway so if someone > could summarize in detail all the key handling I would be happy to do a > detailed review and think carefully about the security stance of the > final solution we agreed on. If we can do this early it would be better > to avoid costly rewrites should we have forgotten/underestimated some > implementation detail that requires changes. > > Simo. > Do you need more detail than ? -- Jan Cholasta From simo at redhat.com Tue Jul 29 06:56:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Jul 2014 02:56:02 -0400 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53D74361.1060001@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> Message-ID: <1406616962.3412.1.camel@willson.usersys.redhat.com> On Tue, 2014-07-29 at 08:46 +0200, Jan Cholasta wrote: > Dne 28.7.2014 v 11:04 Simo Sorce napsal(a): > > On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote: > >> > >> I have updated design page and diagrams: > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema > > > > Excellent page, I took a full read and it all seem reasonable. > > > > However I would like a page like this with the detailed summary of key > > material handling. > > > > This is important to get right and have documented anyway so if someone > > could summarize in detail all the key handling I would be happy to do a > > detailed review and think carefully about the security stance of the > > final solution we agreed on. If we can do this early it would be better > > to avoid costly rewrites should we have forgotten/underestimated some > > implementation detail that requires changes. > > > > Simo. > > > > Do you need more detail than > ? It's almost there but the wraping/unwrapping steps are a bit handwavy. I would like more details on algorithms we are going to use and exactly what parts do the wrapping and unwrapping. For example we say all these operations happen in SoftHSM at the start, but then the steps that describe how these keys are inserted into or extracted from SoftHSM are vague enough they can be interpreted as these operations are being performed outside of SoftHSM. It should be made much clearer exactly what component on the system will perform each and any of the key (un)wrapping operations and with which keys and algorithms. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Jul 29 08:21:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 10:21:44 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D6A6FC.6020908@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> Message-ID: <53D75998.2040701@redhat.com> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): > This is oh-so close. AFAICT it generally does what it should, I think it > is ready for a wider audience. Just a few more things: > > 306: A while True loop is used for something which AFAICT can only ever > execute once. I'd think something like this is more readable: > > for ca_nick, ca_flags in db.list_certs(): > if db.has_nickname(ca_cert): > try: > db.delete_cert(ca_nick) > except ipautil.CalledProcessError: > syslog.syslog( > syslog.LOG_ERR, > "Failed to remove certificate %s" % ca_nick) Actually the while loop is necessary, because certutil -D (and in turn CertDB.delete_cert) deletes just a single cert with the nickname, but there may be more versions of it and we need to delete them all. > > +1 on the additional syslogs. It will help figure out what's going on if > things go sideways. > > Otherwise things seem to be working. I think that fixing the above is > enough for a +57 with the promise of unit tests to back up some of these > new functions. I'm working on that. > > rob > rob > I have made a slight adjustment to patch 246 because of , see . Updated rebased patches attached. (once again, the correct order to apply them is 241-253, 262-294, 303-305, 295-299, 306-307) -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.8-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.8-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.8-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.8-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.8-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.8-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.8-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.8-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.8-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 1824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.8-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 3887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.8-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.8-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.8-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.7-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.6-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.6-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.6-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.5-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.5-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.5-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.5-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.5-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 8975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.5-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 3979 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.5-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3439 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.5-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.5-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.5-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 12821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.5-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.5-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.5-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 15471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.5-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.5-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 4282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.5-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.5-Add-new-add_cert-method-for-adding-certificates-to-N.patch Type: text/x-patch Size: 3843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.5-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.5-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.5-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.5-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.5-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.5-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 4357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.5-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.5-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.5-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.5-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.5-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.5-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.5-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296.5-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 4556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297.5-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298.5-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5873 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299.5-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 15881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-303.3-Add-client-certificate-update-tool-ipa-certupdate.patch Type: text/x-patch Size: 12141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-304.2-Export-full-CA-chain-to-etc-ipa-ca.crt-in-ipa-server.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-305.2-Allow-multiple-CA-certificates-in-replica-info-files.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-306.1-Update-external-CA-cert-in-Dogtag-NSS-DB-on-IPA-CA-c.patch Type: text/x-patch Size: 4211 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-307.1-Enable-NSS-PKIX-certificate-path-discovery-and-valid.patch Type: text/x-patch Size: 4267 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 29 09:49:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 11:49:06 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1406616962.3412.1.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> <53A91DF6.6050604@redhat.com> <53C6968E.8050508@redhat.com> <53C78991.1020708@redhat.com> <53D2935B.8070706@redhat.com> <1406538244.25911.9.camel@willson.usersys.redhat.com> <53D74361.1060001@redhat.com> <1406616962.3412.1.camel@willson.usersys.redhat.com> Message-ID: <53D76E12.9090002@redhat.com> Dne 29.7.2014 v 08:56 Simo Sorce napsal(a): > On Tue, 2014-07-29 at 08:46 +0200, Jan Cholasta wrote: >> Dne 28.7.2014 v 11:04 Simo Sorce napsal(a): >>> On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote: >>>> >>>> I have updated design page and diagrams: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema >>> >>> Excellent page, I took a full read and it all seem reasonable. >>> >>> However I would like a page like this with the detailed summary of key >>> material handling. >>> >>> This is important to get right and have documented anyway so if someone >>> could summarize in detail all the key handling I would be happy to do a >>> detailed review and think carefully about the security stance of the >>> final solution we agreed on. If we can do this early it would be better >>> to avoid costly rewrites should we have forgotten/underestimated some >>> implementation detail that requires changes. >>> >>> Simo. >>> >> >> Do you need more detail than >> ? > > It's almost there but the wraping/unwrapping steps are a bit handwavy. > > I would like more details on algorithms we are going to use and exactly > what parts do the wrapping and unwrapping. For example we say all these > operations happen in SoftHSM at the start, but then the steps that > describe how these keys are inserted into or extracted from SoftHSM are > vague enough they can be interpreted as these operations are being > performed outside of SoftHSM. It should be made much clearer exactly > what component on the system will perform each and any of the key > (un)wrapping operations and with which keys and algorithms. > > Simo. > I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going to comment the steps from the link above here: > First server installation (replica1) > > This operation needs to be detected and guarded so only one replica will become DNSSEC master. It can be done by writing who is DNSSEC master to cn=masters. > > 1. Generate symmetric "master key" for DNSSEC The master key is generated on the token by C_GenerateKey call using the CKM_AES_KEY_GEN mechanism, it is 128b AES, it can be used for wrapping and unwrapping keys, it can be extracted from the token by wrapping, but not in plaintext. > > 2. Generate replica key pair: The replica key pair is generated on the token by C_GenerateKeyPair call using the CKM_RSA_PKCS_KEY_PAIR_GEN mechanism, it is 2048b RSA, the public part can be used for wrapping keys and can be extracted from the token in plaintext, the private part can be used for unwrapping keys and can't be extracted from the token. > > * Store public key to LDAP: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example sub-tree in LDAP. > > * Store private key to SoftHSM (on disk). This is already achieved above by generating the replica key pair on the token. > > 3. Wrap master key with replica key: The master key is wrapped on the token by C_WrapKey using the CKM_RSA_PKCS mechanism and the replica public key as the wrapping key. > > * Store resulting blob in cn=master, cn=keys, cn=sec, cn=dns, dc=example sub-tree in LDAP. > > > Replica installation (replica2) > > This is done by ipa-replica-install: > > 1. Generate replica key pair: The replica key pair is generated in the same manner as in first server installation. > > 2. Store public key to LDAP: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example sub-tree in LDAP. > > 3. Store private key in SoftHSM (on disk). This is already achieved above by generating the replica key pair on the token. > > This is done by little daemon running on replica 1: > > 1. DNSSEC master-replica will detect (SyncRepl) a new public key in cn=masters sub-tree and will use own private key (replica1's) to re-encrypt master key using public key of the new replica (replica2) The master key is wrapped in the same manner as in first server installation. > > 2. Store resulting master-key-blob to cn=master, cn=keys, cn=sec, cn=dns, dc=example sub-tree in LDAP. > > This is done by little daemon running on replica 2: > > 1. Download blob with master key from LDAP. The master key is rotated when a replica is deleted, so there may be more than one master keys in LDAP, but there will be only one which is allowed to wrap keys. This particular master key is downloaded in this step. > > 2. Unwrap blob with replica2's private key. The master key is unwrapped on the token by C_UnwrapKey call using CKM_RSA_PKCS mechanism with the replica private key as the unwrapping key, it can be used for wrapping and unwrapping keys, it can be extracted from the token by wrapping, but not in plaintext. > > 3. Store raw master key to local SoftHSM. This is already achieved above by unwrapping the master key on the token. > > > Replica uninstallation (replica2) > > NOTE: replica1 cannot be uninstalled at the moment. Support for this scenario requires more work. > > NOTE: Old master keys remain in LDAP and old DNSSEC keys are not touched at all. After all, all keys used before replica removal are on replica2's disk anyway. > > This step is done by ipa-replica-manage: > > 1. Delete replica entry in cn=masters. > > All operations with keys are done by little daemon running on replica1: > > 1. Detect that replica2's public key was deleted and initiate master key rotation. > > 2. Generate a new master key. The master key is generated in the same manner as in first server installation. After the new master key is generated, wrapping keys using the old master key is disabled. > > 3. Wrap new master key with all currently published replica-public keys (from cn=masters) and store it to LDAP The master key is wrapped in the same manner as in first server installation. > > > DNSSEC key generation (replica1) > > Key wrapping is done only by replica1 which is running OpenDNSSEC Enforcer daemon. > > 1. Let OpenDNSSEC Enforcer to generate a key according to time schedule. (OpenDNSSEC Enforcer calls OpenDNSSEC Signer daemon which is replaced by our script.) OpenDNSSEC generates a key pair on the token by C_GenerateKeyPair call, the details are OpenDNSSEC-specific, the private part can be extracted from the token by wrapping, but not in plaintext. > > 2. Wrap DNSSEC key with newest master key (stored in local SoftHSM) and store resulting blob to cn=keys, cn=sec, cn=dns. The private key is wrapped on the token by C_WrapKey call using the CKM_AES_KEY_WRAP_PAD mechanism and the current master key as the wrapping key. > > 3. Store key metadata to cn=keys, idnsname=example.net, cn=dns > > > DNSSEC key unwrapping (replica2) > > This is done by little daemons running on all replicas with DNS. > > 1. Detect a new key in LDAP (SyncRepl). > > 2. Download blob from LDAP. > > 3. Unwrap blob with master key described by ipaWrappingKey attribute. The private key is unwrapped on the token by C_UnwrapKey call using the CKM_AES_KEY_WRAP_PAD mechanism and the master key specified by ipaWrappingKey as the unwrapping key, the private part can be extracted from the token by wrapping, but not in plaintext. > > 4. Store raw DNSSEC key in local SoftHSM. This is already achieved above by unwrapping the private key on the token. -- Jan Cholasta From pviktori at redhat.com Tue Jul 29 10:00:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 12:00:51 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap In-Reply-To: <53D73EEC.6090607@redhat.com> References: <53D12736.9000409@redhat.com> <53D68F7C.5040006@redhat.com> <53D73EEC.6090607@redhat.com> Message-ID: <53D770D3.5020007@redhat.com> On 07/29/2014 08:27 AM, Jan Cholasta wrote: > Dne 28.7.2014 v 19:59 Petr Viktorin napsal(a): >> On 07/24/2014 05:33 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >> >> NACK >> If the value *is* a str, with this patch it ends up undefined. >> > > Right, fixed. > ACK, pushed to: master: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b ipa-4-1: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b ipa-4-0: 2eee6060f3237cc4cf23f4044e67e95d7fad195d Could you also write a test for this, though? -- Petr? From pvoborni at redhat.com Tue Jul 29 10:22:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Jul 2014 12:22:46 +0200 Subject: [Freeipa-devel] [PATCH] 710 webui: review pending operation after expired session In-Reply-To: <53D681D8.2040805@redhat.com> References: <53CFB596.4080003@redhat.com> <53D2BD82.4070700@redhat.com> <53D62EA5.7010808@redhat.com> <53D681D8.2040805@redhat.com> Message-ID: <53D775F6.1030301@redhat.com> On 28.7.2014 19:01, Endi Sukma Dewata wrote: > On 7/28/2014 6:06 AM, Petr Vobornik wrote: >>> Right now suppose I'm trying to delete a user, I have the delete dialog >>> open and I let it sit until the session expires, then when I click >>> Delete it will show me a login screen. Once I re-login, the dialog box >>> is gone. It still has the user to be deleted selected, but there's no >>> indication what the operation I was trying to do before. >>> >>> I was thinking the session expiration would work like desktop >>> screensaver lock. So when I re-login I would see same screen as I left >>> it, i.e. the delete dialog is still waiting for action. >> >> Components have not been made with this feature in mind. Take for >> example the delete issue. Deleter dialog is a subclass of confirm >> dialog. Confirm dialog is closed right after confirmation/cancellation. >> It doesn't wait for the result of the operation because it's handled by >> other components. The behavior was OK so far because we showed error >> dialog on "normal" error. On auth error, the command was re-executed. >> Now we don't show any error on auth error nor we leave the dialog open. >> Seems like that we should change all usages of confirm dialog to try to >> do the operation first and close the dialog after the operation was >> successful or canceled. > > Not sure about that. If you're adding a user that already exists, you'll > get an error dialog, but then if you click Cancel you'll go back to the > same add dialog. Yes because the adder dialog remained opened (it was hidden while the error dialog was open because only one dialog can be visible at the same time). > That allows you to revise the info you entered. Can we > use the same concept for session expiration? So instead of an error > dialog you'll get a login screen. If you relogin as the same person, > you'll go back to the same dialog with whatever info you already entered. I think we are in agreement. By the previous text I wanted to point out that not every component behaves as adder dialogs and that they should be identified and fixed. I.e. it's not just about session expiration. > > This is a low priority regardless. > -- Petr Vobornik From pvoborni at redhat.com Tue Jul 29 10:53:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Jul 2014 12:53:53 +0200 Subject: [Freeipa-devel] [PATCH] 715 webui: add bounce url to reset_password.html In-Reply-To: <53D683A5.7080606@redhat.com> References: <53CFCDD2.3000606@redhat.com> <53D2BDB5.5080109@redhat.com> <53D610AC.6020505@redhat.com> <53D683A5.7080606@redhat.com> Message-ID: <53D77D41.2050400@redhat.com> On 28.7.2014 19:08, Endi Sukma Dewata wrote: > On 7/28/2014 3:58 AM, Petr Vobornik wrote: >>> Just one thing, there is no pause between clicking the Reset button >>> and the redirection, so the "Password reset was successful." >>> confirmation message might only appear very briefly. A possible >>> alternative is to show a confirmation page/message, but the user will >>> have to click to continue to the next page. >> >> I don't believe there is a universal solution. I would say that it >> depends on personal preferences and a use case. I.e., if it's part of a >> login procedure I would prefer immediate redirection back to login page. >> If it's invoked from a user action - just to change the password, some >> delay might be good. >> >> We might add a URL param(s) to configure the delay/link. > > How about 2 URL params? > 1. the link to the next page > 2. an option whether to > a) redirect to the link immediately > b) show a confirmation page with the link > > Just my preference, but I don't really like a 'delay' on a web page. > It's either too short or too long, and we can't put important info > during the delay because there's no guarantee people will see it. > Yes, how about this: 1. redirection=url_to_the_page 2. in=x, where x is number of seconds or a string - redirect immediately if only `redirection` is supplied or `in=0` - show "Continue to next page" link if `in` is present - show count-down timer if `in` is > 1 with "You will be redirected in `x`s" text. - don't redirect if `in` is negative or NaN (your scenario), e.g.: `in=no` up to user - ignore `in` if `redirection` is not present Then we will support all described scenarios and the decision will be on web-site admin. Feel free to propose better name for `in`. -- Petr Vobornik From dkupka at redhat.com Tue Jul 29 10:58:04 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Jul 2014 12:58:04 +0200 Subject: [Freeipa-devel] [PATCH] 0007 test group: remove group from protected group In-Reply-To: <53D67D34.8000202@redhat.com> References: <53D105F1.8080907@redhat.com> <53D67D34.8000202@redhat.com> Message-ID: <53D77E3C.2030201@redhat.com> On 07/28/2014 06:41 PM, Petr Viktorin wrote: > On 07/24/2014 03:11 PM, David Kupka wrote: >> Simple test scenario from ticket #4448. >> >> Last test will fail until patch freeipa-dkupka-0006 gets accepted. >> > > Thanks! These look fine, but since the new tests don't require that the > rest of `test_group` is run first, I encourage you to put them in a > separate class. Put to separate class, as suggested. Looks better now. > This would ensure we don't add new inderdependencies between old and new > tests in the future, making future test refactoring more straightforward. > Also, you can select to run just a single test class from a module, so > testing a targeted fix is faster. > (And you can reuse group1, since the other test cleans it up) > > See test_permission_plugin for an example. > The test still fails on current master but works fine with patch freeipa-dkupka-0006-2. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0007-2-test-group-remove-group-from-protected-group.patch Type: text/x-patch Size: 3201 bytes Desc: not available URL: From mkosek at redhat.com Tue Jul 29 11:14:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Jul 2014 13:14:21 +0200 Subject: [Freeipa-devel] [PATCH] 0006 Fix group-remove-member crash when group is removed from a protected group In-Reply-To: <53CFC779.3090100@redhat.com> References: <53CFC1E9.5050209@redhat.com> <53CFC375.4010102@redhat.com> <53CFC779.3090100@redhat.com> Message-ID: <53D7820D.5070509@redhat.com> On 07/23/2014 04:32 PM, David Kupka wrote: > On 07/23/2014 04:15 PM, Martin Kosek wrote: >> On 07/23/2014 04:08 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4448 >> >> Alternatively, we could also update the "if" condition to avoid running this >> section at all when options['user'] does not exist or is empty. This would save >> us at least from api.Command.group_show call. >> >> Martin >> > You're right as always, Martin :-) Works fine, ACK. Pushed to: master: 6119c21441747a1f2dd49df204effe1f2a3240dc ipa-4-1: 6119c21441747a1f2dd49df204effe1f2a3240dc ipa-4-0: 97565cf8ffa8741dac3629e8989d747faa24ddf0 I will not close the ticket until the test that Petr looks on is finished. Martin From jcholast at redhat.com Tue Jul 29 11:21:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 13:21:32 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D0BD21.4000805@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> Message-ID: <53D783BC.4070203@redhat.com> Dne 24.7.2014 v 10:00 David Kupka napsal(a): > > > On 07/23/2014 05:07 PM, Jan Cholasta wrote: >> Hi, >> >> On 23.7.2014 15:46, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4244 >> >> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". > > Thanks for advice, will try to remember. >> >> 2) When is "type(not_before) is str" or "type(not_after) is str" true? >> The values coming from command options or LDAP should always be >> datetime, never str. > > Actually, it is never true. I don't know why I thought that there is > such option. >> >> 3) There are some misindentations: >> >> + raise ValidationError(name='not_after', >> + error='is before not_before!') >> >> + raise ValidationError(name='not_after', >> + error='is before not_before!') >> >> + raise ValidationError(name='not_before', >> + error='is after not_after!') >> >> 4) We don't do exclamation marks in errors messages. > > You re right, it's probably better not to shout at customer :) >> >> 5) Generally, when you want to validate command options, you should look >> into "options", not "entry_attrs". >> >> 6) This is not right: >> >> + result = self.api.Command.otptoken_find(ipatokenuniqueid= >> + entry_attrs.get('ipatokenuniqueid', None))['result'] >> >> This is: >> >> + result = self.api.Command.otptoken_show(keys[-1])['result'] > > Both works, but Martin explained me why is otptoken_show better and how > it actually works. >> >> Honza >> > Few more nitpicks: 1) You can make _check_interval a little bit shorter by removing a redundant if statement: +def _check_interval(not_before, not_after): + if not_before and not_after: + return not_before <= not_after + return True 2) Please keep the 2 line space between the last global function and first class in the module. 3) Error messages are for users' eyes, please don't use internal identifiers in them. 4) You don't need to check if the result of otptoken_show is empty, it never is. -- Jan Cholasta From dkupka at redhat.com Tue Jul 29 12:11:39 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Jul 2014 14:11:39 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D783BC.4070203@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> <53D783BC.4070203@redhat.com> Message-ID: <53D78F7B.9080801@redhat.com> On 07/29/2014 01:21 PM, Jan Cholasta wrote: > Dne 24.7.2014 v 10:00 David Kupka napsal(a): >> >> >> On 07/23/2014 05:07 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 23.7.2014 15:46, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4244 >>> >>> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". >> >> Thanks for advice, will try to remember. >>> >>> 2) When is "type(not_before) is str" or "type(not_after) is str" true? >>> The values coming from command options or LDAP should always be >>> datetime, never str. >> >> Actually, it is never true. I don't know why I thought that there is >> such option. >>> >>> 3) There are some misindentations: >>> >>> + raise ValidationError(name='not_after', >>> + error='is before not_before!') >>> >>> + raise ValidationError(name='not_after', >>> + error='is before not_before!') >>> >>> + raise ValidationError(name='not_before', >>> + error='is after not_after!') >>> >>> 4) We don't do exclamation marks in errors messages. >> >> You re right, it's probably better not to shout at customer :) >>> >>> 5) Generally, when you want to validate command options, you should look >>> into "options", not "entry_attrs". >>> >>> 6) This is not right: >>> >>> + result = self.api.Command.otptoken_find(ipatokenuniqueid= >>> + entry_attrs.get('ipatokenuniqueid', None))['result'] >>> >>> This is: >>> >>> + result = self.api.Command.otptoken_show(keys[-1])['result'] >> >> Both works, but Martin explained me why is otptoken_show better and how >> it actually works. >>> >>> Honza >>> >> > > Few more nitpicks: > > 1) You can make _check_interval a little bit shorter by removing a > redundant if statement: > > +def _check_interval(not_before, not_after): > + if not_before and not_after: > + return not_before <= not_after > + return True Nice :) > > 2) Please keep the 2 line space between the last global function and > first class in the module. It's good to know that there is one less rule to discover. > > 3) Error messages are for users' eyes, please don't use internal > identifiers in them. Done. > > 4) You don't need to check if the result of otptoken_show is empty, it > never is. > Removed. Although, needless check can't hurt. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0005-3-Verify-otptoken-timespan-is-valid.patch Type: text/x-patch Size: 3535 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 29 13:28:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 15:28:35 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D78F7B.9080801@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> <53D783BC.4070203@redhat.com> <53D78F7B.9080801@redhat.com> Message-ID: <53D7A183.8020601@redhat.com> Dne 29.7.2014 v 14:11 David Kupka napsal(a): > On 07/29/2014 01:21 PM, Jan Cholasta wrote: >> Dne 24.7.2014 v 10:00 David Kupka napsal(a): >>> >>> >>> On 07/23/2014 05:07 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 23.7.2014 15:46, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4244 >>>> >>>> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". >>> >>> Thanks for advice, will try to remember. >>>> >>>> 2) When is "type(not_before) is str" or "type(not_after) is str" true? >>>> The values coming from command options or LDAP should always be >>>> datetime, never str. >>> >>> Actually, it is never true. I don't know why I thought that there is >>> such option. >>>> >>>> 3) There are some misindentations: >>>> >>>> + raise ValidationError(name='not_after', >>>> + error='is before not_before!') >>>> >>>> + raise ValidationError(name='not_after', >>>> + error='is before not_before!') >>>> >>>> + raise ValidationError(name='not_before', >>>> + error='is after not_after!') >>>> >>>> 4) We don't do exclamation marks in errors messages. >>> >>> You re right, it's probably better not to shout at customer :) >>>> >>>> 5) Generally, when you want to validate command options, you should >>>> look >>>> into "options", not "entry_attrs". >>>> >>>> 6) This is not right: >>>> >>>> + result = self.api.Command.otptoken_find(ipatokenuniqueid= >>>> + entry_attrs.get('ipatokenuniqueid', None))['result'] >>>> >>>> This is: >>>> >>>> + result = >>>> self.api.Command.otptoken_show(keys[-1])['result'] >>> >>> Both works, but Martin explained me why is otptoken_show better and how >>> it actually works. >>>> >>>> Honza >>>> >>> >> >> Few more nitpicks: >> >> 1) You can make _check_interval a little bit shorter by removing a >> redundant if statement: >> >> +def _check_interval(not_before, not_after): >> + if not_before and not_after: >> + return not_before <= not_after >> + return True > Nice :) >> >> 2) Please keep the 2 line space between the last global function and >> first class in the module. > It's good to know that there is one less rule to discover. >> >> 3) Error messages are for users' eyes, please don't use internal >> identifiers in them. > Done. >> >> 4) You don't need to check if the result of otptoken_show is empty, it >> never is. >> > Removed. Although, needless check can't hurt. > One more thing, sorry I didn't notice it earlier: You must check if 'ipatokennotbefore' and 'ipatokennotafter' keys are in opttoken-show result before using them, otherwise you might end up with: ipa: ERROR: non-public: KeyError: 'ipatokennotbefore' Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 348, in wsgi_execute result = self.Command[name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1384, in execute *keys, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 356, in pre_callback notbefore = result['ipatokennotbefore'][0] KeyError: 'ipatokennotbefore' -- Jan Cholasta From dkupka at redhat.com Tue Jul 29 13:52:55 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Jul 2014 15:52:55 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D7A183.8020601@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> <53D783BC.4070203@redhat.com> <53D78F7B.9080801@redhat.com> <53D7A183.8020601@redhat.com> Message-ID: <53D7A737.7050108@redhat.com> On 07/29/2014 03:28 PM, Jan Cholasta wrote: > Dne 29.7.2014 v 14:11 David Kupka napsal(a): >> On 07/29/2014 01:21 PM, Jan Cholasta wrote: >>> Dne 24.7.2014 v 10:00 David Kupka napsal(a): >>>> >>>> >>>> On 07/23/2014 05:07 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 23.7.2014 15:46, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4244 >>>>> >>>>> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". >>>> >>>> Thanks for advice, will try to remember. >>>>> >>>>> 2) When is "type(not_before) is str" or "type(not_after) is str" true? >>>>> The values coming from command options or LDAP should always be >>>>> datetime, never str. >>>> >>>> Actually, it is never true. I don't know why I thought that there is >>>> such option. >>>>> >>>>> 3) There are some misindentations: >>>>> >>>>> + raise ValidationError(name='not_after', >>>>> + error='is before not_before!') >>>>> >>>>> + raise ValidationError(name='not_after', >>>>> + error='is before not_before!') >>>>> >>>>> + raise ValidationError(name='not_before', >>>>> + error='is after not_after!') >>>>> >>>>> 4) We don't do exclamation marks in errors messages. >>>> >>>> You re right, it's probably better not to shout at customer :) >>>>> >>>>> 5) Generally, when you want to validate command options, you should >>>>> look >>>>> into "options", not "entry_attrs". >>>>> >>>>> 6) This is not right: >>>>> >>>>> + result = self.api.Command.otptoken_find(ipatokenuniqueid= >>>>> + entry_attrs.get('ipatokenuniqueid', None))['result'] >>>>> >>>>> This is: >>>>> >>>>> + result = >>>>> self.api.Command.otptoken_show(keys[-1])['result'] >>>> >>>> Both works, but Martin explained me why is otptoken_show better and how >>>> it actually works. >>>>> >>>>> Honza >>>>> >>>> >>> >>> Few more nitpicks: >>> >>> 1) You can make _check_interval a little bit shorter by removing a >>> redundant if statement: >>> >>> +def _check_interval(not_before, not_after): >>> + if not_before and not_after: >>> + return not_before <= not_after >>> + return True >> Nice :) >>> >>> 2) Please keep the 2 line space between the last global function and >>> first class in the module. >> It's good to know that there is one less rule to discover. >>> >>> 3) Error messages are for users' eyes, please don't use internal >>> identifiers in them. >> Done. >>> >>> 4) You don't need to check if the result of otptoken_show is empty, it >>> never is. >>> >> Removed. Although, needless check can't hurt. >> > > One more thing, sorry I didn't notice it earlier: You must check if > 'ipatokennotbefore' and 'ipatokennotafter' keys are in opttoken-show > result before using them, otherwise you might end up with: > > ipa: ERROR: non-public: KeyError: 'ipatokennotbefore' > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", > line 348, in wsgi_execute > result = self.Command[name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 439, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > 754, in run > return self.execute(*args, **options) > File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line > 1384, in execute > *keys, **options) > File > "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 356, > in pre_callback > notbefore = result['ipatokennotbefore'][0] > KeyError: 'ipatokennotbefore' > Sorry for sending fifth wersion of the patch. I must test my patches more carefully. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0005-4-Verify-otptoken-timespan-is-valid.patch Type: text/x-patch Size: 3559 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 29 13:58:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Jul 2014 15:58:17 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D7A737.7050108@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> <53D783BC.4070203@redhat.com> <53D78F7B.9080801@redhat.com> <53D7A183.8020601@redhat.com> <53D7A737.7050108@redhat.com> Message-ID: <53D7A879.8030405@redhat.com> Dne 29.7.2014 v 15:52 David Kupka napsal(a): > On 07/29/2014 03:28 PM, Jan Cholasta wrote: >> Dne 29.7.2014 v 14:11 David Kupka napsal(a): >>> On 07/29/2014 01:21 PM, Jan Cholasta wrote: >>>> Dne 24.7.2014 v 10:00 David Kupka napsal(a): >>>>> >>>>> >>>>> On 07/23/2014 05:07 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 23.7.2014 15:46, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4244 >>>>>> >>>>>> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". >>>>> >>>>> Thanks for advice, will try to remember. >>>>>> >>>>>> 2) When is "type(not_before) is str" or "type(not_after) is str" >>>>>> true? >>>>>> The values coming from command options or LDAP should always be >>>>>> datetime, never str. >>>>> >>>>> Actually, it is never true. I don't know why I thought that there is >>>>> such option. >>>>>> >>>>>> 3) There are some misindentations: >>>>>> >>>>>> + raise ValidationError(name='not_after', >>>>>> + error='is before not_before!') >>>>>> >>>>>> + raise ValidationError(name='not_after', >>>>>> + error='is before not_before!') >>>>>> >>>>>> + raise ValidationError(name='not_before', >>>>>> + error='is after not_after!') >>>>>> >>>>>> 4) We don't do exclamation marks in errors messages. >>>>> >>>>> You re right, it's probably better not to shout at customer :) >>>>>> >>>>>> 5) Generally, when you want to validate command options, you should >>>>>> look >>>>>> into "options", not "entry_attrs". >>>>>> >>>>>> 6) This is not right: >>>>>> >>>>>> + result = >>>>>> self.api.Command.otptoken_find(ipatokenuniqueid= >>>>>> + entry_attrs.get('ipatokenuniqueid', None))['result'] >>>>>> >>>>>> This is: >>>>>> >>>>>> + result = >>>>>> self.api.Command.otptoken_show(keys[-1])['result'] >>>>> >>>>> Both works, but Martin explained me why is otptoken_show better and >>>>> how >>>>> it actually works. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> >>>> Few more nitpicks: >>>> >>>> 1) You can make _check_interval a little bit shorter by removing a >>>> redundant if statement: >>>> >>>> +def _check_interval(not_before, not_after): >>>> + if not_before and not_after: >>>> + return not_before <= not_after >>>> + return True >>> Nice :) >>>> >>>> 2) Please keep the 2 line space between the last global function and >>>> first class in the module. >>> It's good to know that there is one less rule to discover. >>>> >>>> 3) Error messages are for users' eyes, please don't use internal >>>> identifiers in them. >>> Done. >>>> >>>> 4) You don't need to check if the result of otptoken_show is empty, it >>>> never is. >>>> >>> Removed. Although, needless check can't hurt. >>> >> >> One more thing, sorry I didn't notice it earlier: You must check if >> 'ipatokennotbefore' and 'ipatokennotafter' keys are in opttoken-show >> result before using them, otherwise you might end up with: >> >> ipa: ERROR: non-public: KeyError: 'ipatokennotbefore' >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >> line 348, in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >> 439, in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >> 754, in run >> return self.execute(*args, **options) >> File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >> 1384, in execute >> *keys, **options) >> File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 356, >> in pre_callback >> notbefore = result['ipatokennotbefore'][0] >> KeyError: 'ipatokennotbefore' >> > Sorry for sending fifth wersion of the patch. I must test my patches > more carefully. > No problem. I must review more carefully. ACK. -- Jan Cholasta From rcritten at redhat.com Tue Jul 29 14:32:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2014 10:32:20 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D75998.2040701@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> Message-ID: <53D7B074.2020608@redhat.com> Jan Cholasta wrote: > Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >> This is oh-so close. AFAICT it generally does what it should, I think it >> is ready for a wider audience. Just a few more things: >> >> 306: A while True loop is used for something which AFAICT can only ever >> execute once. I'd think something like this is more readable: >> >> for ca_nick, ca_flags in db.list_certs(): >> if db.has_nickname(ca_cert): >> try: >> db.delete_cert(ca_nick) >> except ipautil.CalledProcessError: >> syslog.syslog( >> syslog.LOG_ERR, >> "Failed to remove certificate %s" % ca_nick) > > Actually the while loop is necessary, because certutil -D (and in turn > CertDB.delete_cert) deletes just a single cert with the nickname, but > there may be more versions of it and we need to delete them all. Aha, excellent point. This would be a great comment in the code! >> >> +1 on the additional syslogs. It will help figure out what's going on if >> things go sideways. >> >> Otherwise things seem to be working. I think that fixing the above is >> enough for a +57 with the promise of unit tests to back up some of these >> new functions. > > I'm working on that. > >> >> rob >> rob >> > > I have made a slight adjustment to patch 246 because of > , see > . > > Updated rebased patches attached. > > (once again, the correct order to apply them is 241-253, 262-294, > 303-305, 295-299, 306-307) > ACK on 246. IMHO this is ready to be pushed if you can add the comment on 306. A slight rebase on 251 is needed for freeipa.spec.in. rob From rcritten at redhat.com Tue Jul 29 14:33:07 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2014 10:33:07 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D7B074.2020608@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> <53D7B074.2020608@redhat.com> Message-ID: <53D7B0A3.5000407@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >>> This is oh-so close. AFAICT it generally does what it should, I think it >>> is ready for a wider audience. Just a few more things: >>> >>> 306: A while True loop is used for something which AFAICT can only ever >>> execute once. I'd think something like this is more readable: >>> >>> for ca_nick, ca_flags in db.list_certs(): >>> if db.has_nickname(ca_cert): >>> try: >>> db.delete_cert(ca_nick) >>> except ipautil.CalledProcessError: >>> syslog.syslog( >>> syslog.LOG_ERR, >>> "Failed to remove certificate %s" % ca_nick) >> >> Actually the while loop is necessary, because certutil -D (and in turn >> CertDB.delete_cert) deletes just a single cert with the nickname, but >> there may be more versions of it and we need to delete them all. > > Aha, excellent point. This would be a great comment in the code! > >>> >>> +1 on the additional syslogs. It will help figure out what's going on if >>> things go sideways. >>> >>> Otherwise things seem to be working. I think that fixing the above is >>> enough for a +57 with the promise of unit tests to back up some of these >>> new functions. >> >> I'm working on that. >> >>> >>> rob >>> rob >>> >> >> I have made a slight adjustment to patch 246 because of >> , see >> . >> >> Updated rebased patches attached. >> >> (once again, the correct order to apply them is 241-253, 262-294, >> 303-305, 295-299, 306-307) >> > > ACK on 246. > > IMHO this is ready to be pushed if you can add the comment on 306. > > A slight rebase on 251 is needed for freeipa.spec.in. Oh, or maybe not since you sent the whole shebang. I just did an interdiff of the current and old 246. rob From pviktori at redhat.com Tue Jul 29 15:02:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 17:02:18 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} Message-ID: <53D7B77A.5010802@redhat.com> Hello, The first patch here consolidates our system user creation code a bit. The second patch fixes an oversight in the restore script. The third changes the backup script to not include /etc/{passwd,group}, and the restore script to create the PKI user if a CA is being restored. Note that the DS user is already created early in the restore process. (In the future we may want a nice generic framework for restoring users, but I'd like to extrapolate from more than one data point when designing it.) The fourth patch adds a log entry I find very useful in testing backup/restore. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0624-ipaserver.install-Consolidate-system-user-creation.patch Type: text/x-patch Size: 10237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0625-ipa_restore-Split-the-services-list.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0626-backup-restore-Don-t-overwrite-etc-passwd-group.patch Type: text/x-patch Size: 2275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0627-ipa_backup-Log-where-the-backup-is-be-stored.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From mkosek at redhat.com Tue Jul 29 15:03:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Jul 2014 17:03:43 +0200 Subject: [Freeipa-devel] [PATCH] 480 Do not crash client basedn discovery when SSF not met Message-ID: <53D7B7CF.7050309@redhat.com> ipa-client-install runs anonymous search in non-rootdse space which may raise UNWILLING_TO_PERFORM error. This case was only covered for BIND, but not for the actual LDAP queries. https://fedorahosted.org/freeipa/ticket/4459 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-480-do-not-crash-client-basedn-discovery-when-ssf-not-me.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: From pviktori at redhat.com Tue Jul 29 15:07:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 17:07:41 +0200 Subject: [Freeipa-devel] [PATCH] 0007 test group: remove group from protected group In-Reply-To: <53D77E3C.2030201@redhat.com> References: <53D105F1.8080907@redhat.com> <53D67D34.8000202@redhat.com> <53D77E3C.2030201@redhat.com> Message-ID: <53D7B8BD.9060500@redhat.com> On 07/29/2014 12:58 PM, David Kupka wrote: > On 07/28/2014 06:41 PM, Petr Viktorin wrote: >> On 07/24/2014 03:11 PM, David Kupka wrote: >>> Simple test scenario from ticket #4448. >>> >>> Last test will fail until patch freeipa-dkupka-0006 gets accepted. >>> >> >> Thanks! These look fine, but since the new tests don't require that the >> rest of `test_group` is run first, I encourage you to put them in a >> separate class. > Put to separate class, as suggested. Looks better now. > >> This would ensure we don't add new inderdependencies between old and new >> tests in the future, making future test refactoring more straightforward. >> Also, you can select to run just a single test class from a module, so >> testing a targeted fix is faster. >> (And you can reuse group1, since the other test cleans it up) >> >> See test_permission_plugin for an example. >> > The test still fails on current master but works fine with patch > freeipa-dkupka-0006-2. > Thanks! ACK, pushed to: master: f7e00b9ad626e48a3e78a5ff68512642312a6d3d ipa-4-1: f7e00b9ad626e48a3e78a5ff68512642312a6d3d ipa-4-0: 19dd0c67bba41cd76fb1600a3d5f0293ec6f7c75 -- Petr? From pviktori at redhat.com Tue Jul 29 15:10:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 17:10:16 +0200 Subject: [Freeipa-devel] [PATCH] 0005 Verify otptoken timespan is valid In-Reply-To: <53D7A879.8030405@redhat.com> References: <53CFBCC1.70907@redhat.com> <53CFCF9B.7080302@redhat.com> <53D0BD21.4000805@redhat.com> <53D783BC.4070203@redhat.com> <53D78F7B.9080801@redhat.com> <53D7A183.8020601@redhat.com> <53D7A737.7050108@redhat.com> <53D7A879.8030405@redhat.com> Message-ID: <53D7B958.10906@redhat.com> On 07/29/2014 03:58 PM, Jan Cholasta wrote: > Dne 29.7.2014 v 15:52 David Kupka napsal(a): >> On 07/29/2014 03:28 PM, Jan Cholasta wrote: >>> Dne 29.7.2014 v 14:11 David Kupka napsal(a): >>>> On 07/29/2014 01:21 PM, Jan Cholasta wrote: >>>>> Dne 24.7.2014 v 10:00 David Kupka napsal(a): >>>>>> >>>>>> >>>>>> On 07/23/2014 05:07 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 23.7.2014 15:46, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4244 >>>>>>> >>>>>>> 1) Use "isinstance(X, Y)" instead of "type(X) is Y". >>>>>> >>>>>> Thanks for advice, will try to remember. >>>>>>> >>>>>>> 2) When is "type(not_before) is str" or "type(not_after) is str" >>>>>>> true? >>>>>>> The values coming from command options or LDAP should always be >>>>>>> datetime, never str. >>>>>> >>>>>> Actually, it is never true. I don't know why I thought that there is >>>>>> such option. >>>>>>> >>>>>>> 3) There are some misindentations: >>>>>>> >>>>>>> + raise ValidationError(name='not_after', >>>>>>> + error='is before not_before!') >>>>>>> >>>>>>> + raise ValidationError(name='not_after', >>>>>>> + error='is before not_before!') >>>>>>> >>>>>>> + raise ValidationError(name='not_before', >>>>>>> + error='is after not_after!') >>>>>>> >>>>>>> 4) We don't do exclamation marks in errors messages. >>>>>> >>>>>> You re right, it's probably better not to shout at customer :) >>>>>>> >>>>>>> 5) Generally, when you want to validate command options, you should >>>>>>> look >>>>>>> into "options", not "entry_attrs". >>>>>>> >>>>>>> 6) This is not right: >>>>>>> >>>>>>> + result = >>>>>>> self.api.Command.otptoken_find(ipatokenuniqueid= >>>>>>> + entry_attrs.get('ipatokenuniqueid', >>>>>>> None))['result'] >>>>>>> >>>>>>> This is: >>>>>>> >>>>>>> + result = >>>>>>> self.api.Command.otptoken_show(keys[-1])['result'] >>>>>> >>>>>> Both works, but Martin explained me why is otptoken_show better and >>>>>> how >>>>>> it actually works. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>> >>>>> Few more nitpicks: >>>>> >>>>> 1) You can make _check_interval a little bit shorter by removing a >>>>> redundant if statement: >>>>> >>>>> +def _check_interval(not_before, not_after): >>>>> + if not_before and not_after: >>>>> + return not_before <= not_after >>>>> + return True >>>> Nice :) >>>>> >>>>> 2) Please keep the 2 line space between the last global function and >>>>> first class in the module. >>>> It's good to know that there is one less rule to discover. >>>>> >>>>> 3) Error messages are for users' eyes, please don't use internal >>>>> identifiers in them. >>>> Done. >>>>> >>>>> 4) You don't need to check if the result of otptoken_show is empty, it >>>>> never is. >>>>> >>>> Removed. Although, needless check can't hurt. >>>> >>> >>> One more thing, sorry I didn't notice it earlier: You must check if >>> 'ipatokennotbefore' and 'ipatokennotafter' keys are in opttoken-show >>> result before using them, otherwise you might end up with: >>> >>> ipa: ERROR: non-public: KeyError: 'ipatokennotbefore' >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>> line 348, in wsgi_execute >>> result = self.Command[name](*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>> 439, in __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>> 754, in run >>> return self.execute(*args, **options) >>> File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >>> 1384, in execute >>> *keys, **options) >>> File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 356, >>> in pre_callback >>> notbefore = result['ipatokennotbefore'][0] >>> KeyError: 'ipatokennotbefore' >>> >> Sorry for sending fifth wersion of the patch. I must test my patches >> more carefully. >> > > No problem. I must review more carefully. ACK. > Pushed to: master: 724391a71b018c94aca71b588a24983e228cf2a7 ipa-4-1: 724391a71b018c94aca71b588a24983e228cf2a7 ipa-4-0: 928c87f5c89916e7bb1a6e1e5def45302a2ea8ec -- Petr? From pviktori at redhat.com Tue Jul 29 15:48:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 17:48:20 +0200 Subject: [Freeipa-devel] [PATCH] 480 Do not crash client basedn discovery when SSF not met In-Reply-To: <53D7B7CF.7050309@redhat.com> References: <53D7B7CF.7050309@redhat.com> Message-ID: <53D7C244.5050903@redhat.com> On 07/29/2014 05:03 PM, Martin Kosek wrote: > ipa-client-install runs anonymous search in non-rootdse space which > may raise UNWILLING_TO_PERFORM error. This case was only covered for > BIND, but not for the actual LDAP queries. > > https://fedorahosted.org/freeipa/ticket/4459 ACK, pushed to: master: aa0639284c233d10b1bb4c02317155436685dc38 ipa-4-1: aa0639284c233d10b1bb4c02317155436685dc38 ipa-4-0: b104179e0313358ad3f72b3abde6095dd2a24ac1 -- Petr? From pviktori at redhat.com Tue Jul 29 16:03:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Jul 2014 18:03:42 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} In-Reply-To: <53D7B77A.5010802@redhat.com> References: <53D7B77A.5010802@redhat.com> Message-ID: <53D7C5DE.6000004@redhat.com> On 07/29/2014 05:02 PM, Petr Viktorin wrote: > Hello, > > The first patch here consolidates our system user creation code a bit. > > The second patch fixes an oversight in the restore script. > > The third changes the backup script to not include /etc/{passwd,group}, > and the restore script to create the PKI user if a CA is being restored. > Note that the DS user is already created early in the restore process. > (In the future we may want a nice generic framework for restoring users, > but I'd like to extrapolate from more than one data point when designing > it.) Another note: tar uses owner user/group names by default, so no additional chowning is required even if the IDs change between backup & restore. > > The fourth patch adds a log entry I find very useful in testing > backup/restore. > -- Petr? From edewata at redhat.com Tue Jul 29 17:01:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 29 Jul 2014 12:01:26 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53C53711.8020307@redhat.com> References: <53C53711.8020307@redhat.com> Message-ID: <53D7D366.6090608@redhat.com> On 7/15/2014 9:13 AM, Endi Sukma Dewata wrote: > Hi, > > I've been working on the implementation details of password vault: > http://www.freeipa.org/page/V4/Password_Vault_Implementation > > There are some issues (i.e. vault password and vault key) that aren't > specifically defined in the design, so we need to make some decisions. > > Please let me know if you have any comments or questions. Thanks! Hi, I have made a number of changes to the above page including: * using a vault as a container of secrets * using a single encryption key per vault instead of per secret * using one escrow officer per vault * adding escrow, access control, & configuration * adding client API & web services * adding database & transaction * adding FAQ The options that I presented in the original version were removed because as I worked on the details it appeared that the alternatives don't actually make sense. Please take a look and let me know if you have any comments or questions. There are more details to be fleshed out, so I'll keep updating the page. Thanks. -- Endi S. Dewata From jcholast at redhat.com Wed Jul 30 07:25:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Jul 2014 09:25:57 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D7B0A3.5000407@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> <53D7B074.2020608@redhat.com> <53D7B0A3.5000407@redhat.com> Message-ID: <53D89E05.4030606@redhat.com> Dne 29.7.2014 v 16:33 Rob Crittenden napsal(a): > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >>>> This is oh-so close. AFAICT it generally does what it should, I think it >>>> is ready for a wider audience. Just a few more things: >>>> >>>> 306: A while True loop is used for something which AFAICT can only ever >>>> execute once. I'd think something like this is more readable: >>>> >>>> for ca_nick, ca_flags in db.list_certs(): >>>> if db.has_nickname(ca_cert): >>>> try: >>>> db.delete_cert(ca_nick) >>>> except ipautil.CalledProcessError: >>>> syslog.syslog( >>>> syslog.LOG_ERR, >>>> "Failed to remove certificate %s" % ca_nick) >>> >>> Actually the while loop is necessary, because certutil -D (and in turn >>> CertDB.delete_cert) deletes just a single cert with the nickname, but >>> there may be more versions of it and we need to delete them all. >> >> Aha, excellent point. This would be a great comment in the code! >> >>>> >>>> +1 on the additional syslogs. It will help figure out what's going on if >>>> things go sideways. >>>> >>>> Otherwise things seem to be working. I think that fixing the above is >>>> enough for a +57 with the promise of unit tests to back up some of these >>>> new functions. >>> >>> I'm working on that. >>> >>>> >>>> rob >>>> rob >>>> >>> >>> I have made a slight adjustment to patch 246 because of >>> , see >>> . >>> >>> Updated rebased patches attached. >>> >>> (once again, the correct order to apply them is 241-253, 262-294, >>> 303-305, 295-299, 306-307) >>> >> >> ACK on 246. >> >> IMHO this is ready to be pushed if you can add the comment on 306. Added. Updated patch attached. >> >> A slight rebase on 251 is needed for freeipa.spec.in. > > Oh, or maybe not since you sent the whole shebang. I just did an > interdiff of the current and old 246. Yep, I remember fixing this particular merge conflict. > > rob > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-306.2-Update-external-CA-cert-in-Dogtag-NSS-DB-on-IPA-CA-c.patch Type: text/x-patch Size: 4278 bytes Desc: not available URL: From pviktori at redhat.com Wed Jul 30 08:17:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Jul 2014 10:17:58 +0200 Subject: [Freeipa-devel] [PATCH] 0628 test_ipagetkeytab: Fix assertion in negative test Message-ID: <53D8AA36.5080903@redhat.com> Hello, This fixes a test that was broken by a recent ipa-getkeytab fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0628-test_ipagetkeytab-Fix-assertion-in-negative-test.patch Type: text/x-patch Size: 1296 bytes Desc: not available URL: From mkosek at redhat.com Wed Jul 30 09:04:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Jul 2014 11:04:00 +0200 Subject: [Freeipa-devel] [PATCH] 0628 test_ipagetkeytab: Fix assertion in negative test In-Reply-To: <53D8AA36.5080903@redhat.com> References: <53D8AA36.5080903@redhat.com> Message-ID: <53D8B500.7090902@redhat.com> On 07/30/2014 10:17 AM, Petr Viktorin wrote: > Hello, > This fixes a test that was broken by a recent ipa-getkeytab fix. /me sighs. Yup, this fixes the problem, ACK. Pushed to: master: 410da23aeccbf932493af86a9150d4fb02c01a01 ipa-4-1: 410da23aeccbf932493af86a9150d4fb02c01a01 ipa-4-0: 85493fa386ebf29e4fc3517644073f291f661803 Martin From rcritten at redhat.com Wed Jul 30 12:47:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Jul 2014 08:47:18 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D89E05.4030606@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> <53D7B074.2020608@redhat.com> <53D7B0A3.5000407@redhat.com> <53D89E05.4030606@redhat.com> Message-ID: <53D8E956.5070400@redhat.com> Jan Cholasta wrote: > Dne 29.7.2014 v 16:33 Rob Crittenden napsal(a): >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >>>>> This is oh-so close. AFAICT it generally does what it should, I >>>>> think it >>>>> is ready for a wider audience. Just a few more things: >>>>> >>>>> 306: A while True loop is used for something which AFAICT can only >>>>> ever >>>>> execute once. I'd think something like this is more readable: >>>>> >>>>> for ca_nick, ca_flags in db.list_certs(): >>>>> if db.has_nickname(ca_cert): >>>>> try: >>>>> db.delete_cert(ca_nick) >>>>> except ipautil.CalledProcessError: >>>>> syslog.syslog( >>>>> syslog.LOG_ERR, >>>>> "Failed to remove certificate %s" % ca_nick) >>>> >>>> Actually the while loop is necessary, because certutil -D (and in turn >>>> CertDB.delete_cert) deletes just a single cert with the nickname, but >>>> there may be more versions of it and we need to delete them all. >>> >>> Aha, excellent point. This would be a great comment in the code! >>> >>>>> >>>>> +1 on the additional syslogs. It will help figure out what's going >>>>> on if >>>>> things go sideways. >>>>> >>>>> Otherwise things seem to be working. I think that fixing the above is >>>>> enough for a +57 with the promise of unit tests to back up some of >>>>> these >>>>> new functions. >>>> >>>> I'm working on that. >>>> >>>>> >>>>> rob >>>>> rob >>>>> >>>> >>>> I have made a slight adjustment to patch 246 because of >>>> , see >>>> . >>>> >>>> Updated rebased patches attached. >>>> >>>> (once again, the correct order to apply them is 241-253, 262-294, >>>> 303-305, 295-299, 306-307) >>>> >>> >>> ACK on 246. >>> >>> IMHO this is ready to be pushed if you can add the comment on 306. > > Added. Updated patch attached. > >>> >>> A slight rebase on 251 is needed for freeipa.spec.in. >> >> Oh, or maybe not since you sent the whole shebang. I just did an >> interdiff of the current and old 246. > > Yep, I remember fixing this particular merge conflict. ACK rob From jcholast at redhat.com Wed Jul 30 12:51:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Jul 2014 14:51:32 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D8E956.5070400@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> <53D7B074.2020608@redhat.com> <53D7B0A3.5000407@redhat.com> <53D89E05.4030606@redhat.com> <53D8E956.5070400@redhat.com> Message-ID: <53D8EA54.6030407@redhat.com> Dne 30.7.2014 v 14:47 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 29.7.2014 v 16:33 Rob Crittenden napsal(a): >>> Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >>>>>> This is oh-so close. AFAICT it generally does what it should, I >>>>>> think it >>>>>> is ready for a wider audience. Just a few more things: >>>>>> >>>>>> 306: A while True loop is used for something which AFAICT can only >>>>>> ever >>>>>> execute once. I'd think something like this is more readable: >>>>>> >>>>>> for ca_nick, ca_flags in db.list_certs(): >>>>>> if db.has_nickname(ca_cert): >>>>>> try: >>>>>> db.delete_cert(ca_nick) >>>>>> except ipautil.CalledProcessError: >>>>>> syslog.syslog( >>>>>> syslog.LOG_ERR, >>>>>> "Failed to remove certificate %s" % ca_nick) >>>>> >>>>> Actually the while loop is necessary, because certutil -D (and in turn >>>>> CertDB.delete_cert) deletes just a single cert with the nickname, but >>>>> there may be more versions of it and we need to delete them all. >>>> >>>> Aha, excellent point. This would be a great comment in the code! >>>> >>>>>> >>>>>> +1 on the additional syslogs. It will help figure out what's going >>>>>> on if >>>>>> things go sideways. >>>>>> >>>>>> Otherwise things seem to be working. I think that fixing the above is >>>>>> enough for a +57 with the promise of unit tests to back up some of >>>>>> these >>>>>> new functions. >>>>> >>>>> I'm working on that. >>>>> >>>>>> >>>>>> rob >>>>>> rob >>>>>> >>>>> >>>>> I have made a slight adjustment to patch 246 because of >>>>> , see >>>>> . >>>>> >>>>> Updated rebased patches attached. >>>>> >>>>> (once again, the correct order to apply them is 241-253, 262-294, >>>>> 303-305, 295-299, 306-307) >>>>> >>>> >>>> ACK on 246. >>>> >>>> IMHO this is ready to be pushed if you can add the comment on 306. >> >> Added. Updated patch attached. >> >>>> >>>> A slight rebase on 251 is needed for freeipa.spec.in. >>> >>> Oh, or maybe not since you sent the whole shebang. I just did an >>> interdiff of the current and old 246. >> >> Yep, I remember fixing this particular merge conflict. > > ACK > > rob > Thank you for the review. (please push in this order: 241-253, 262-294, 303-305, 295-299, 306-307) -- Jan Cholasta From mkosek at redhat.com Wed Jul 30 12:53:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Jul 2014 14:53:02 +0200 Subject: [Freeipa-devel] FreeIPA&OpenLMI Message-ID: <53D8EAAE.6020300@redhat.com> Hello all, As discussed before, FreeIPA could take advantage of a remote management system to allow easier deployment/modification of servers, replicas or clients. OpenLMI seems to be the right tool for the job, I started a discussion about the use cases on their list, openlmi-devel: https://lists.fedorahosted.org/pipermail/openlmi-devel/2014-July/002281.html Please feel free to subscribe there and/or comment. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From dkupka at redhat.com Wed Jul 30 13:51:08 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 30 Jul 2014 15:51:08 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <20140723134507.GB1400@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> Message-ID: <53D8F84C.1020706@redhat.com> On 07/23/2014 03:45 PM, Nalin Dahyabhai wrote: > On Wed, Jul 23, 2014 at 10:12:39AM +0200, Martin Kosek wrote: >> Certmonger API looked complete enough to pull this off: >> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >> >> If I am wrong, please tell me. > > No, it's meant to be complete -- the getcert command only uses the APIs > to talk to the daemon, so they provide at least what it needs. > > Two words of caution: > * That file's manually maintained, so it might not completely reflect > what's available. The introspection data's generated at runtime, so > if you poke the service with an introspection request, or using > d-feet, which does so under the covers, you might spot discrepancies. > It probably goes without saying, but please report any that you find. > * The majority of properties are currently marked read-only, and you > currently have to use the 'modify' API request to change them. Mostly > this is a result of 'getcert' not having needed anything more than > that, and properties having been added after the initial versions, so > it's not set in stone. > > HTH, > > Nalin > In fact it is almost enough complete for us. The only operation I can't find is 'write ca_external_helper'. add_principal_to_cas and remove_principal_from_cas are modifying this entry in ca file. Certmonger provide 'get_location' DBus method that returns value of this entry but I can't find any 'set_location' method, writable property or other way to modify it over DBus. Am I searching wrong? If not I looked in certmonger code and think that I will be able to add the missing functionality. But I'm unsure what is the preferred way, I can think of two: 1. set_location method 2. read-write location/ca_external_helper property -- David Kupka From pviktori at redhat.com Wed Jul 30 14:14:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Jul 2014 16:14:14 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53D8EA54.6030407@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> <53B1A017.4080802@redhat.com> <53B42C7E.9040808@redhat.com> <53B43C95.1080907@redhat.com> <53B44356.2040004@redhat.com> <53B59BF5.6080404@redhat.com> <53B5D0B1.7070706@redhat.com> <53CE656C.1060909@redhat.com> <53CFAA02.9050607@redhat.com> <53D6A6FC.6020908@redhat.com> <53D75998.2040701@redhat.com> <53D7B074.2020608@redhat.com> <53D7B0A3.5000407@redhat.com> <53D89E05.4030606@redhat.com> <53D8E956.5070400@redhat.com> <53D8EA54.6030407@redhat.com> Message-ID: <53D8FDB6.3020908@redhat.com> On 07/30/2014 02:51 PM, Jan Cholasta wrote: > Dne 30.7.2014 v 14:47 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 29.7.2014 v 16:33 Rob Crittenden napsal(a): >>>> Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 28.7.2014 v 21:39 Rob Crittenden napsal(a): >>>>>>> This is oh-so close. AFAICT it generally does what it should, I >>>>>>> think it >>>>>>> is ready for a wider audience. Just a few more things: >>>>>>> >>>>>>> 306: A while True loop is used for something which AFAICT can only >>>>>>> ever >>>>>>> execute once. I'd think something like this is more readable: >>>>>>> >>>>>>> for ca_nick, ca_flags in db.list_certs(): >>>>>>> if db.has_nickname(ca_cert): >>>>>>> try: >>>>>>> db.delete_cert(ca_nick) >>>>>>> except ipautil.CalledProcessError: >>>>>>> syslog.syslog( >>>>>>> syslog.LOG_ERR, >>>>>>> "Failed to remove certificate %s" % ca_nick) >>>>>> >>>>>> Actually the while loop is necessary, because certutil -D (and in >>>>>> turn >>>>>> CertDB.delete_cert) deletes just a single cert with the nickname, but >>>>>> there may be more versions of it and we need to delete them all. >>>>> >>>>> Aha, excellent point. This would be a great comment in the code! >>>>> >>>>>>> >>>>>>> +1 on the additional syslogs. It will help figure out what's going >>>>>>> on if >>>>>>> things go sideways. >>>>>>> >>>>>>> Otherwise things seem to be working. I think that fixing the >>>>>>> above is >>>>>>> enough for a +57 with the promise of unit tests to back up some of >>>>>>> these >>>>>>> new functions. >>>>>> >>>>>> I'm working on that. >>>>>> >>>>>>> >>>>>>> rob >>>>>>> rob >>>>>>> >>>>>> >>>>>> I have made a slight adjustment to patch 246 because of >>>>>> , see >>>>>> . >>>>>> >>>>>> >>>>>> Updated rebased patches attached. >>>>>> >>>>>> (once again, the correct order to apply them is 241-253, 262-294, >>>>>> 303-305, 295-299, 306-307) >>>>>> >>>>> >>>>> ACK on 246. >>>>> >>>>> IMHO this is ready to be pushed if you can add the comment on 306. >>> >>> Added. Updated patch attached. >>> >>>>> >>>>> A slight rebase on 251 is needed for freeipa.spec.in. >>>> >>>> Oh, or maybe not since you sent the whole shebang. I just did an >>>> interdiff of the current and old 246. >>> >>> Yep, I remember fixing this particular merge conflict. >> >> ACK >> >> rob >> > > Thank you for the review. > > (please push in this order: 241-253, 262-294, 303-305, 295-299, 306-307) > Pushed to: master: 044c5c833a83a541f97785279acfe8e113035b3d ipa-4-1: 044c5c833a83a541f97785279acfe8e113035b3d -- Petr? From pviktori at redhat.com Wed Jul 30 14:26:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Jul 2014 16:26:22 +0200 Subject: [Freeipa-devel] [PATCHES] 0264-0267 backup, restore: Don't overwrite /etc/{passwd, group} In-Reply-To: <53D7C5DE.6000004@redhat.com> References: <53D7B77A.5010802@redhat.com> <53D7C5DE.6000004@redhat.com> Message-ID: <53D9008E.7060404@redhat.com> On 07/29/2014 06:03 PM, Petr Viktorin wrote: > On 07/29/2014 05:02 PM, Petr Viktorin wrote: >> Hello, >> >> The first patch here consolidates our system user creation code a bit. >> >> The second patch fixes an oversight in the restore script. >> >> The third changes the backup script to not include /etc/{passwd,group}, >> and the restore script to create the PKI user if a CA is being restored. >> Note that the DS user is already created early in the restore process. >> (In the future we may want a nice generic framework for restoring users, >> but I'd like to extrapolate from more than one data point when designing >> it.) > > Another note: tar uses owner user/group names by default, so no > additional chowning is required even if the IDs change between backup & > restore. > >> >> The fourth patch adds a log entry I find very useful in testing >> backup/restore. Rebased onto current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0624.2-ipaserver.install-Consolidate-system-user-creation.patch Type: text/x-patch Size: 10301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0625.2-ipa_restore-Split-the-services-list.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0626.2-backup-restore-Don-t-overwrite-etc-passwd-group.patch Type: text/x-patch Size: 2275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0627.2-ipa_backup-Log-where-the-backup-is-be-stored.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 30 14:28:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Jul 2014 16:28:50 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53D8F84C.1020706@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> <53D8F84C.1020706@redhat.com> Message-ID: <53D90122.5090505@redhat.com> Dne 30.7.2014 v 15:51 David Kupka napsal(a): > On 07/23/2014 03:45 PM, Nalin Dahyabhai wrote: >> On Wed, Jul 23, 2014 at 10:12:39AM +0200, Martin Kosek wrote: >>> Certmonger API looked complete enough to pull this off: >>> https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/api.txt >>> >>> If I am wrong, please tell me. >> >> No, it's meant to be complete -- the getcert command only uses the APIs >> to talk to the daemon, so they provide at least what it needs. >> >> Two words of caution: >> * That file's manually maintained, so it might not completely reflect >> what's available. The introspection data's generated at runtime, so >> if you poke the service with an introspection request, or using >> d-feet, which does so under the covers, you might spot discrepancies. >> It probably goes without saying, but please report any that you find. >> * The majority of properties are currently marked read-only, and you >> currently have to use the 'modify' API request to change them. Mostly >> this is a result of 'getcert' not having needed anything more than >> that, and properties having been added after the initial versions, so >> it's not set in stone. >> >> HTH, >> >> Nalin >> > In fact it is almost enough complete for us. The only operation I can't > find is 'write ca_external_helper'. > add_principal_to_cas and remove_principal_from_cas are modifying this > entry in ca file. Certmonger provide 'get_location' DBus method that > returns value of this entry but I can't find any 'set_location' method, > writable property or other way to modify it over DBus. > Am I searching wrong? If not I looked in certmonger code and think that > I will be able to add the missing functionality. But I'm unsure what is > the preferred way, I can think of two: > 1. set_location method > 2. read-write location/ca_external_helper property > These two functions are used to force local hostname in certmonger. IMO the right thing to do here would be to drop these two functions and fix ipa-submit so that it reads the required configuration from /etc/ipa/default.conf. -- Jan Cholasta From nalin at redhat.com Wed Jul 30 14:39:29 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 30 Jul 2014 10:39:29 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53D90122.5090505@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> <53D8F84C.1020706@redhat.com> <53D90122.5090505@redhat.com> Message-ID: <20140730143928.GA26871@redhat.com> On Wed, Jul 30, 2014 at 04:28:50PM +0200, Jan Cholasta wrote: > These two functions are used to force local hostname in certmonger. IMO the > right thing to do here would be to drop these two functions and fix > ipa-submit so that it reads the required configuration from > /etc/ipa/default.conf. Can you elaborate on that? Either here or in a trac ticket or in bugzilla? The only hostname I see in the default.conf(5) man page is the name of the server, which it should already be using when there's no xmlrpc_uri set. Nalin From nalin at redhat.com Wed Jul 30 17:45:28 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 30 Jul 2014 13:45:28 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53D8F84C.1020706@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> <53D8F84C.1020706@redhat.com> Message-ID: <20140730174527.GB26871@redhat.com> On Wed, Jul 30, 2014 at 03:51:08PM +0200, David Kupka wrote: > In fact it is almost enough complete for us. The only operation I can't find > is 'write ca_external_helper'. > add_principal_to_cas and remove_principal_from_cas are modifying this entry > in ca file. Certmonger provide 'get_location' DBus method that returns value > of this entry but I can't find any 'set_location' method, writable property > or other way to modify it over DBus. Yeah, it wasn't originally expected that those'd need to be edited after they were added. > Am I searching wrong? If not I looked in certmonger code and think that I > will be able to add the missing functionality. But I'm unsure what is the > preferred way, I can think of two: > 1. set_location method > 2. read-write location/ca_external_helper property Probably the latter, since it's slightly less code and I think more in keeping with the way D-Bus clients generally expect to be doing things. That's assuming you don't need to kill any in-progress attempts to contact a CA and restart them with the new value. Cheers, Nalin From jcholast at redhat.com Thu Jul 31 07:19:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 31 Jul 2014 09:19:28 +0200 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <20140730143928.GA26871@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> <53D8F84C.1020706@redhat.com> <53D90122.5090505@redhat.com> <20140730143928.GA26871@redhat.com> Message-ID: <53D9EE00.9040008@redhat.com> Dne 30.7.2014 v 16:39 Nalin Dahyabhai napsal(a): > On Wed, Jul 30, 2014 at 04:28:50PM +0200, Jan Cholasta wrote: >> These two functions are used to force local hostname in certmonger. IMO the >> right thing to do here would be to drop these two functions and fix >> ipa-submit so that it reads the required configuration from >> /etc/ipa/default.conf. > > Can you elaborate on that? Either here or in a trac ticket or in > bugzilla? > > The only hostname I see in the default.conf(5) man page is the name of > the server, which it should already be using when there's no xmlrpc_uri > set. > > Nalin > If you mean "host", yes, the man page says it's the server's hostname, but I don't think that's entirely true - it is currently set during server install, but it defaults to local hostname even on clients. IMO we could set it in ipa-client-install as well (at least when --hostname is used) and then ipa-submit could use it to construct the principal name. -- Jan Cholasta From pvoborni at redhat.com Thu Jul 31 08:04:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 31 Jul 2014 10:04:31 +0200 Subject: [Freeipa-devel] [PATCH] 717 webui-ci: fix reset password check Message-ID: <53D9F88F.9020002@redhat.com> This patch should fix recent CI failures. After login, CI checks if password needs a reset by checking if reset password fields are displayed. This check failed since login facet was removed from DOM after successful auth. Weakening the selector fixes it. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0717-webui-ci-fix-reset-password-check.patch Type: text/x-patch Size: 1590 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 31 08:24:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 31 Jul 2014 10:24:43 +0200 Subject: [Freeipa-devel] [PATCH] 310 Exclude attributelevelrights from --raw result processing in baseldap In-Reply-To: <53D770D3.5020007@redhat.com> References: <53D12736.9000409@redhat.com> <53D68F7C.5040006@redhat.com> <53D73EEC.6090607@redhat.com> <53D770D3.5020007@redhat.com> Message-ID: <53D9FD4B.5050608@redhat.com> Dne 29.7.2014 v 12:00 Petr Viktorin napsal(a): > On 07/29/2014 08:27 AM, Jan Cholasta wrote: >> Dne 28.7.2014 v 19:59 Petr Viktorin napsal(a): >>> On 07/24/2014 05:33 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>> >>> NACK >>> If the value *is* a str, with this patch it ends up undefined. >>> >> >> Right, fixed. >> > > ACK, pushed to: > master: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b > ipa-4-1: 785e13dd1e16ad03d4ef03edcb672d6f9d8b457b > ipa-4-0: 2eee6060f3237cc4cf23f4044e67e95d7fad195d > > Could you also write a test for this, though? Sure. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-311-Add-test-for-baseldap.entry_to_dict.patch Type: text/x-patch Size: 2558 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 31 08:47:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 31 Jul 2014 10:47:37 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> Message-ID: <53DA02A9.9040603@redhat.com> Dne 24.7.2014 v 00:15 Gabe Alford napsal(a): > Nope. Somehow in my head it felt cleaner. Updated patched attached. > > > On Wed, Jul 23, 2014 at 1:18 AM, Jan Cholasta > wrote: > > On 23.7.2014 01:01, Gabe Alford wrote: > > Forgot about --trust-secret. Here is an updated patch. > > > On Mon, Jul 21, 2014 at 2:31 AM, Jan Cholasta > > >> wrote: > > On 21.7.2014 10:28, Martin Kosek wrote: > > On 07/21/2014 09:56 AM, Jan Cholasta wrote: > > Hi, > > On 16.7.2014 05:48, Gabe Alford wrote: > > Hello, > > Adds AD admin and password to interactive commands. > https://fedorahosted.org/____freeipa/ticket/3034 > > > > > > Thanks, > > Gabe > > > I think that instead of making the parameters > mandatory, you > should instead set > alwaysask=True on them. > > Honza > > > Trust can be established either with user+password > options OR with > --trust-secret option - i.e. you cannot use mandatory > options > nor alwaysask. > > > Ah, right. > > > > This would rather lead to interactive_prompt_callback > checking > if any of > authentication method is passed and asking for them if > they aren't. > > > +1 > > > Martin > > > > -- > Jan Cholasta > > > > I don't think using an extra function to update a value in a > dictionary is very beneficial, is there a reason not to use "kw[X] = > self.prompt_param(self.params[__X])" directly? > > -- > Jan Cholasta > > Thanks, ACK. -- Jan Cholasta From mkosek at redhat.com Thu Jul 31 09:11:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 31 Jul 2014 11:11:31 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53DA02A9.9040603@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> Message-ID: <53DA0843.3020801@redhat.com> On 07/31/2014 10:47 AM, Jan Cholasta wrote: > Dne 24.7.2014 v 00:15 Gabe Alford napsal(a): >> Nope. Somehow in my head it felt cleaner. Updated patched attached. >> >> >> On Wed, Jul 23, 2014 at 1:18 AM, Jan Cholasta > > wrote: >> >> On 23.7.2014 01:01, Gabe Alford wrote: >> >> Forgot about --trust-secret. Here is an updated patch. >> >> >> On Mon, Jul 21, 2014 at 2:31 AM, Jan Cholasta >> >> >> wrote: >> >> On 21.7.2014 10:28, Martin Kosek wrote: >> >> On 07/21/2014 09:56 AM, Jan Cholasta wrote: >> >> Hi, >> >> On 16.7.2014 05:48, Gabe Alford wrote: >> >> Hello, >> >> Adds AD admin and password to interactive commands. >> https://fedorahosted.org/____freeipa/ticket/3034 >> >> >> > > >> >> Thanks, >> >> Gabe >> >> >> I think that instead of making the parameters >> mandatory, you >> should instead set >> alwaysask=True on them. >> >> Honza >> >> >> Trust can be established either with user+password >> options OR with >> --trust-secret option - i.e. you cannot use mandatory >> options >> nor alwaysask. >> >> >> Ah, right. >> >> >> >> This would rather lead to interactive_prompt_callback >> checking >> if any of >> authentication method is passed and asking for them if >> they aren't. >> >> >> +1 >> >> >> Martin >> >> >> >> -- >> Jan Cholasta >> >> >> >> I don't think using an extra function to update a value in a >> dictionary is very beneficial, is there a reason not to use "kw[X] = >> self.prompt_param(self.params[__X])" directly? >> >> -- >> Jan Cholasta >> >> > > Thanks, ACK. Sorry for going late in the game, just a quick question - why do we want to add this part: + if trust_type is None: + kw['trust_type'] = self.prompt_param(self.params['trust_type']) ? I do not see a reason for adding a special interactive prompt callback for that - trust_type has a default value "ad". CCing Alexander to double check. Thanks, Martin From abokovoy at redhat.com Thu Jul 31 09:18:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 31 Jul 2014 12:18:00 +0300 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53DA0843.3020801@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> Message-ID: <20140731091800.GV3492@redhat.com> On Thu, 31 Jul 2014, Martin Kosek wrote: >Sorry for going late in the game, just a quick question - why do we want to add >this part: > >+ if trust_type is None: >+ kw['trust_type'] = self.prompt_param(self.params['trust_type']) > >? I do not see a reason for adding a special interactive prompt callback for >that - trust_type has a default value "ad". CCing Alexander to double check. I also don't understand why you need to ask interactively for the trust_type as it defaults to non-empty value and this value is the only one we currently support. -- / Alexander Bokovoy From pviktori at redhat.com Thu Jul 31 10:03:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 31 Jul 2014 12:03:30 +0200 Subject: [Freeipa-devel] [PATCH] 717 webui-ci: fix reset password check In-Reply-To: <53D9F88F.9020002@redhat.com> References: <53D9F88F.9020002@redhat.com> Message-ID: <53DA1472.1020105@redhat.com> On 07/31/2014 10:04 AM, Petr Vobornik wrote: > This patch should fix recent CI failures. > > > After login, CI checks if password needs a reset by checking if > reset password fields are displayed. This check failed since > login facet was removed from DOM after successful auth. Weakening > the selector fixes it. Thanks, this fixes most of the failures. ACK, pushed to: ipa-4-0: 834af3533a63f6ea3d23f089ca9d7d122ab6bc71 ipa-4-1: 80733bff15a764bab45f5a9b468072e9636ef1d3 master: 80733bff15a764bab45f5a9b468072e9636ef1d3 -- Petr? From nalin at redhat.com Thu Jul 31 12:15:20 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 31 Jul 2014 08:15:20 -0400 Subject: [Freeipa-devel] Reasons for not using certmonger DBus API In-Reply-To: <53D9EE00.9040008@redhat.com> References: <53CF6AA5.7040909@redhat.com> <53CF6E77.5000101@redhat.com> <20140723134507.GB1400@redhat.com> <53D8F84C.1020706@redhat.com> <53D90122.5090505@redhat.com> <20140730143928.GA26871@redhat.com> <53D9EE00.9040008@redhat.com> Message-ID: <20140731121520.GA30772@redhat.com> On Thu, Jul 31, 2014 at 09:19:28AM +0200, Jan Cholasta wrote: > If you mean "host", yes, the man page says it's the server's hostname, but I > don't think that's entirely true - it is currently set during server > install, but it defaults to local hostname even on clients. IMO we could set > it in ipa-client-install as well (at least when --hostname is used) and then > ipa-submit could use it to construct the principal name. Sounds workable to me (though, yikes, that means it's unsuitable for use as a fallback when xmlrpc_uri isn't set, so that'll probably have to get changed at the same time). If there's a ticket for the client-install change in IPA that I should follow and/or one for certmonger for the rest of it, I can try to land it around the same time. Thanks, Nalin From redhatrises at gmail.com Thu Jul 31 13:17:08 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 31 Jul 2014 07:17:08 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <20140731091800.GV3492@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> Message-ID: Right. The reason I added it in there is that I could see that in the future trust_type could be more than just 'ad' (maybe 'ipa', 'krb', etc?) which at that point I'm not sure a default makes sense. So, I thought to go ahead and add the check for future use cases so that it doesn't have to be remembered later. However, maybe that was just a bad idea as right now it is a pointless check? Gabe On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy wrote: > On Thu, 31 Jul 2014, Martin Kosek wrote: > >> Sorry for going late in the game, just a quick question - why do we want >> to add >> this part: >> >> + if trust_type is None: >> + kw['trust_type'] = self.prompt_param(self.params[ >> 'trust_type']) >> >> ? I do not see a reason for adding a special interactive prompt callback >> for >> that - trust_type has a default value "ad". CCing Alexander to double >> check. >> > I also don't understand why you need to ask interactively for the > trust_type as it defaults to non-empty value and this value is the only > one we currently support. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Jul 31 13:18:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 31 Jul 2014 15:18:51 +0200 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> Message-ID: <53DA423B.2050607@redhat.com> Ah, right. But I still think that's a too-early optimization. We can add this callback when this necessity arises. Until then, I would rather prefer to keep the code clean. Martin On 07/31/2014 03:17 PM, Gabe Alford wrote: > Right. The reason I added it in there is that I could see that in the > future trust_type could be more than just 'ad' (maybe 'ipa', 'krb', etc?) > which at that point I'm not sure a default makes sense. So, I thought to go > ahead and add the check for future use cases so that it doesn't have to be > remembered later. However, maybe that was just a bad idea as right now it > is a pointless check? > > Gabe > > > On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy > wrote: > >> On Thu, 31 Jul 2014, Martin Kosek wrote: >> >>> Sorry for going late in the game, just a quick question - why do we want >>> to add >>> this part: >>> >>> + if trust_type is None: >>> + kw['trust_type'] = self.prompt_param(self.params[ >>> 'trust_type']) >>> >>> ? I do not see a reason for adding a special interactive prompt callback >>> for >>> that - trust_type has a default value "ad". CCing Alexander to double >>> check. >>> >> I also don't understand why you need to ask interactively for the >> trust_type as it defaults to non-empty value and this value is the only >> one we currently support. >> >> >> -- >> / Alexander Bokovoy >> > From redhatrises at gmail.com Thu Jul 31 13:57:09 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 31 Jul 2014 07:57:09 -0600 Subject: [Freeipa-devel] [PATCH] ipa trust-add command should be interactive In-Reply-To: <53DA423B.2050607@redhat.com> References: <53CCC7A1.2090201@redhat.com> <53CCCF1F.6040707@redhat.com> <53CCCFD2.3040306@redhat.com> <53CF61AB.7080706@redhat.com> <53DA02A9.9040603@redhat.com> <53DA0843.3020801@redhat.com> <20140731091800.GV3492@redhat.com> <53DA423B.2050607@redhat.com> Message-ID: Okay. Sounds good. Update patch attached. On Thu, Jul 31, 2014 at 7:18 AM, Martin Kosek wrote: > Ah, right. But I still think that's a too-early optimization. We can add > this > callback when this necessity arises. Until then, I would rather prefer to > keep > the code clean. > > Martin > > On 07/31/2014 03:17 PM, Gabe Alford wrote: > > Right. The reason I added it in there is that I could see that in the > > future trust_type could be more than just 'ad' (maybe 'ipa', 'krb', etc?) > > which at that point I'm not sure a default makes sense. So, I thought to > go > > ahead and add the check for future use cases so that it doesn't have to > be > > remembered later. However, maybe that was just a bad idea as right now it > > is a pointless check? > > > > Gabe > > > > > > On Thu, Jul 31, 2014 at 3:18 AM, Alexander Bokovoy > > wrote: > > > >> On Thu, 31 Jul 2014, Martin Kosek wrote: > >> > >>> Sorry for going late in the game, just a quick question - why do we > want > >>> to add > >>> this part: > >>> > >>> + if trust_type is None: > >>> + kw['trust_type'] = self.prompt_param(self.params[ > >>> 'trust_type']) > >>> > >>> ? I do not see a reason for adding a special interactive prompt > callback > >>> for > >>> that - trust_type has a default value "ad". CCing Alexander to double > >>> check. > >>> > >> I also don't understand why you need to ask interactively for the > >> trust_type as it defaults to non-empty value and this value is the only > >> one we currently support. > >> > >> > >> -- > >> / Alexander Bokovoy > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0024-4-ipa-trust-add-command-should-be-interactive.patch Type: text/x-patch Size: 2151 bytes Desc: not available URL: From simo at redhat.com Thu Jul 31 15:58:39 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 31 Jul 2014 11:58:39 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53C53711.8020307@redhat.com> References: <53C53711.8020307@redhat.com> Message-ID: <1406822319.30289.42.camel@willson.usersys.redhat.com> On Tue, 2014-07-15 at 09:13 -0500, Endi Sukma Dewata wrote: > Hi, > > I've been working on the implementation details of password vault: > http://www.freeipa.org/page/V4/Password_Vault_Implementation > > There are some issues (i.e. vault password and vault key) that aren't > specifically defined in the design, so we need to make some decisions. > > Please let me know if you have any comments or questions. Thanks! I am reading this document and there are some things I need to ask clarification for: * In "Vault password and secret key" you describe a mechanism where you store a hash of the password used to generate the secret key, why ? What's the purpose ? * Why shared vaults need to be in a /shared/ namespace ? Can't a user create a vault and then share it with other users ? Ie should the fact a vault is shared just a property that can be changed at any time ? If not, why not ? * In "Listing secrets in a vault " it seem that the metadata about various secrets is obtainable in the clear, is that so ? I am not sure it is a good idea to give blatant hints about what is being encrypted in the vault. * In "Modifying a secret" you use "ipa vault-secret-del" but you mean -mod I guess. * Why services are in the /shared/ namespace ? * The paragraph "Changing service vault password" confuses me, is it correct ? I have not fully internalized all there is there, but most of it looks quite good. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Thu Jul 31 18:05:38 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 Jul 2014 13:05:38 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <1406822319.30289.42.camel@willson.usersys.redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> Message-ID: <53DA8572.5050603@redhat.com> On 7/31/2014 10:58 AM, Simo Sorce wrote: >> http://www.freeipa.org/page/V4/Password_Vault_Implementation > I am reading this document and there are some things I need to ask > clarification for: > > * In "Vault password and secret key" you describe a mechanism where you > store a hash of the password used to generate the secret key, why ? > What's the purpose ? The hash is for password verification. The encryption/secret key is for encrypting the secrets. The hash will be different from the secret key because they are generated with different salts. The hash is stored on the server, but since it's different it cannot be used to decrypt the secrets. We need a password verification to make sure all secrets in the same vault are encrypted with the same password. If we allow different passwords for different secrets, the password change command wouldn't make sense because it will only work on some secrets and corrupt the others. I'm open to other ways for password verification without hash. Any suggestions? > * Why shared vaults need to be in a /shared/ namespace ? > Can't a user create a vault and then share it with other users ? > Ie should the fact a vault is shared just a property that can be changed > at any time ? If not, why not ? We want to avoid conflicting names of private vaults created by different people, so we put private vaults under the owner's namespace. Yes, the owner can share the private vaults in their namespace, but the ownership can change, or it can be owned by multiple people, or probably the original owner will not be the owner anymore. So the /shared namespace is provided for a global, non-user-specific vaults. The owner can move a private vault into /shared, and vice versa, as long as it doesn't conflict with an existing vault. > * In "Listing secrets in a vault " it seem that the metadata about > various secrets is obtainable in the clear, is that so ? > I am not sure it is a good idea to give blatant hints about what is > being encrypted in the vault. The list of secrets are available to vault members/owners/escrow officer/admin only, but they don't need to specify a password to view the secret metadata. Non-members will not be able to see anything in the vault including the list of secrets. If a member is not allowed to see the list of secrets in a vault, the secrets probably should be split into different vaults. If we want to protect the secret metadata with password, does it mean we need to encrypt it too? Or we can make the access control more granular. Only owners can see the list of secrets. > * In "Modifying a secret" you use "ipa vault-secret-del" but you mean > -mod I guess. Yes, that's a copy & paste error. It has been fixed now. > * Why services are in the /shared/ namespace ? Services don't seem to be something that you want to associate with a specific user. So in that case it's put under the /shared namespace. Even so, the vault membership can still be limited to certain users/service instances. Being in /shared doesn't mean it's open for public. > * The paragraph "Changing service vault password" confuses me, is it > correct ? I revised the wordings in this section, please take a look again: http://www.freeipa.org/page/V4/Password_Vault_Implementation#Service_Operations Please also see the design page: http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows > I have not fully internalized all there is there, but most of it looks > quite good. > > Simo. Thanks for your feedback! Please let me know if you have other questions or comments. -- Endi S. Dewata From simo at redhat.com Thu Jul 31 18:30:57 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 31 Jul 2014 14:30:57 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53DA8572.5050603@redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> Message-ID: <1406831457.19681.4.camel@willson.usersys.redhat.com> On Thu, 2014-07-31 at 13:05 -0500, Endi Sukma Dewata wrote: > On 7/31/2014 10:58 AM, Simo Sorce wrote: > >> http://www.freeipa.org/page/V4/Password_Vault_Implementation > > > I am reading this document and there are some things I need to ask > > clarification for: > > > > * In "Vault password and secret key" you describe a mechanism where you > > store a hash of the password used to generate the secret key, why ? > > What's the purpose ? > > The hash is for password verification. The encryption/secret key is for > encrypting the secrets. The hash will be different from the secret key > because they are generated with different salts. The hash is stored on > the server, but since it's different it cannot be used to decrypt the > secrets. > > We need a password verification to make sure all secrets in the same > vault are encrypted with the same password. If we allow different > passwords for different secrets, the password change command wouldn't > make sense because it will only work on some secrets and corrupt the others. > > I'm open to other ways for password verification without hash. Any > suggestions? I was thinking whether we should use a single attribute for each vault, and format the data within the vault as a json blob, to organize the data within the blob. This would allow us to encrypt everything including names and descriptions of the single secrets. This way we also do not need to verify the password, as there is a single encrypted blob and not multiple ones. > > * Why shared vaults need to be in a /shared/ namespace ? > > Can't a user create a vault and then share it with other users ? > > Ie should the fact a vault is shared just a property that can be changed > > at any time ? If not, why not ? > > We want to avoid conflicting names of private vaults created by > different people, so we put private vaults under the owner's namespace. > Yes, the owner can share the private vaults in their namespace, but the > ownership can change, or it can be owned by multiple people, or probably > the original owner will not be the owner anymore. So the /shared > namespace is provided for a global, non-user-specific vaults. The owner > can move a private vault into /shared, and vice versa, as long as it > doesn't conflict with an existing vault. Ok > The list of secrets are available to vault members/owners/escrow > officer/admin only, but they don't need to specify a password to view > the secret metadata. Non-members will not be able to see anything in the > vault including the list of secrets. If a member is not allowed to see > the list of secrets in a vault, the secrets probably should be split > into different vaults. I am more concerned about an admin just seeing the secrets descriptions, or someone finding a backup etc... I was considering the vault as a unit to which either you have or not access based on encryption, not on access control done in LDAP. See above my proposal also that goes in this direction. > If we want to protect the secret metadata with password, does it mean we > need to encrypt it too? Yes. > Or we can make the access control more granular. Only owners can see the > list of secrets. I am not sure listing the secrets within the vault w/o decrypting the vault is necessarily valuable. > > * In "Modifying a secret" you use "ipa vault-secret-del" but you mean > > -mod I guess. > > Yes, that's a copy & paste error. It has been fixed now. > > > * Why services are in the /shared/ namespace ? > > Services don't seem to be something that you want to associate with a > specific user. Not with a user, with a service. /services/openvpn at foo.example.com/ > So in that case it's put under the /shared namespace. > Even so, the vault membership can still be limited to certain > users/service instances. Being in /shared doesn't mean it's open for public. Understood, but if you have the same "service" on multiple machines then it quickly becomes difficult to sort it out, I would prefer a logic similar that of the user, just with fully qualified service names under a /services/ namespace > > * The paragraph "Changing service vault password" confuses me, is it > > correct ? > > I revised the wordings in this section, please take a look again: > http://www.freeipa.org/page/V4/Password_Vault_Implementation#Service_Operations > > Please also see the design page: > http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Thu Jul 31 21:13:03 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 Jul 2014 16:13:03 -0500 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <1406831457.19681.4.camel@willson.usersys.redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> Message-ID: <53DAB15F.8030003@redhat.com> On 7/31/2014 1:30 PM, Simo Sorce wrote: >>>> http://www.freeipa.org/page/V4/Password_Vault_Implementation > I was thinking whether we should use a single attribute for each vault, > and format the data within the vault as a json blob, to organize the > data within the blob. > > This would allow us to encrypt everything including names and > descriptions of the single secrets. This way we also do not need to > verify the password, as there is a single encrypted blob and not > multiple ones. > I am more concerned about an admin just seeing the secrets descriptions, > or someone finding a backup etc... > I was considering the vault as a unit to which either you have or not > access based on encryption, not on access control done in LDAP. See > above my proposal also that goes in this direction. The "compartment" concept was actually proposed by Dmitri to help manage the secrets. I translated that into "vault" since a vault is essentially a compartment. We can certainly change the design to use separate password for each secret. But suppose you have many secrets, you will be responsible to remember the password for each secret. Would that be a reasonable requirement for people in general? Encrypting the secret metadata is a separate issue, we can do that either way. See comments below. Vault as a compartment will help reduce that burden by using the same password for multiple secrets. It also can help if you're sharing multiple secrets with the same group of people. You can also create separate vaults for each secret if necessary, or the server can be configured to limit the number of secrets in each vault. >> Or we can make the access control more granular. Only owners can see the >> list of secrets. > > I am not sure listing the secrets within the vault w/o decrypting the > vault is necessarily valuable. Any concern about the crypto operations being computationally expensive, or retrieving the whole blob just to see the metadata would waste bandwidth? Even if we encrypt individual secrets with the metadata, the secret name itself will still be visible to the admin, and it might give out clues as to what is in the secret. You can use cryptic names for the secrets, but you'll have to maintain it on your own. Let's see if the analogy with safe deposit box in a bank makes sense: 1. Use one box (vault) to store multiple items (secrets). You will have one key (vault password) and you will need it to see what's inside. 2. Like #1, but the bank keeps a list of items (metadata) in the box and only share it with authorized people (vault members). You can identify yourself as a member with an ID (Kerberos principal), but you still need a key (vault password) to get the items. 3. Use a separate box to store each item (separate password for each secret). You will have to manually keep track which key for which box/item. >>> * Why services are in the /shared/ namespace ? >> >> Services don't seem to be something that you want to associate with a >> specific user. > > Not with a user, with a service. > /services/openvpn at foo.example.com/ We probably can add new commands (or repurpose the commands) to manage the namespace. So initially there will be /users and /shared, but you can add others such as /services. >> So in that case it's put under the /shared namespace. >> Even so, the vault membership can still be limited to certain >> users/service instances. Being in /shared doesn't mean it's open for public. > > Understood, but if you have the same "service" on multiple machines then > it quickly becomes difficult to sort it out, I would prefer a logic > similar that of the user, just with fully qualified service names under > a /services/ namespace The vault namespace is hierarchical, so you can organize it in any way you want: * /services/@ * /shared/services// In the current wiki page the service admin can pick the vault name (/shared/services is just an example), but the secret names in it are generated from the service principal (to make sure the service admin and the service instance use the same secret name). -- Endi S. Dewata From simo at redhat.com Thu Jul 31 22:34:08 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 31 Jul 2014 18:34:08 -0400 Subject: [Freeipa-devel] Password Vault Implementation In-Reply-To: <53DAB15F.8030003@redhat.com> References: <53C53711.8020307@redhat.com> <1406822319.30289.42.camel@willson.usersys.redhat.com> <53DA8572.5050603@redhat.com> <1406831457.19681.4.camel@willson.usersys.redhat.com> <53DAB15F.8030003@redhat.com> Message-ID: <1406846048.19681.6.camel@willson.usersys.redhat.com> On Thu, 2014-07-31 at 16:13 -0500, Endi Sukma Dewata wrote: > On 7/31/2014 1:30 PM, Simo Sorce wrote: > >>>> http://www.freeipa.org/page/V4/Password_Vault_Implementation > > > I was thinking whether we should use a single attribute for each vault, > > and format the data within the vault as a json blob, to organize the > > data within the blob. > > > > This would allow us to encrypt everything including names and > > descriptions of the single secrets. This way we also do not need to > > verify the password, as there is a single encrypted blob and not > > multiple ones. > > > I am more concerned about an admin just seeing the secrets descriptions, > > or someone finding a backup etc... > > I was considering the vault as a unit to which either you have or not > > access based on encryption, not on access control done in LDAP. See > > above my proposal also that goes in this direction. > > The "compartment" concept was actually proposed by Dmitri to help manage > the secrets. I translated that into "vault" since a vault is essentially > a compartment. > > We can certainly change the design to use separate password for each > secret. But suppose you have many secrets, you will be responsible to > remember the password for each secret. Would that be a reasonable > requirement for people in general? Encrypting the secret metadata is a > separate issue, we can do that either way. See comments below. > > Vault as a compartment will help reduce that burden by using the same > password for multiple secrets. It also can help if you're sharing > multiple secrets with the same group of people. You can also create > separate vaults for each secret if necessary, or the server can be > configured to limit the number of secrets in each vault. I think you misunderstood what I was proposing. I was proposing the vault is the unit of encryption, as a single blob of data. But the vault would still contain multiple secrets, simply formatted into a json object. Something like: plaintext: { { id: "email", data: "Passw0rd", description: "my email password" }, { id: "redhat.com", data: "Secret5", description: "redhat.com website password" }, ... } > >> Or we can make the access control more granular. Only owners can see the > >> list of secrets. > > > > I am not sure listing the secrets within the vault w/o decrypting the > > vault is necessarily valuable. > > Any concern about the crypto operations being computationally expensive, > or retrieving the whole blob just to see the metadata would waste bandwidth? How big do you think the vault would be ? It is not meant to contain anything more than a bunch of passwords, do we really have a problem if the blob is a few tens of kilobytes ? > Even if we encrypt individual secrets with the metadata, the secret name > itself will still be visible to the admin, and it might give out clues > as to what is in the secret. You can use cryptic names for the secrets, > but you'll have to maintain it on your own. Only if you have separate objects per secret which is what I was arguing against. > Let's see if the analogy with safe deposit box in a bank makes sense: > > 1. Use one box (vault) to store multiple items (secrets). You will have > one key (vault password) and you will need it to see what's inside. This is what I am proposing indeed. > 2. Like #1, but the bank keeps a list of items (metadata) in the box and > only share it with authorized people (vault members). You can identify > yourself as a member with an ID (Kerberos principal), but you still need > a key (vault password) to get the items. I do not like this much :) > 3. Use a separate box to store each item (separate password for each > secret). You will have to manually keep track which key for which box/item. This is really bad, not advocating at all. > >>> * Why services are in the /shared/ namespace ? > >> > >> Services don't seem to be something that you want to associate with a > >> specific user. > > > > Not with a user, with a service. > > /services/openvpn at foo.example.com/ > > We probably can add new commands (or repurpose the commands) to manage > the namespace. So initially there will be /users and /shared, but you > can add others such as /services. > > >> So in that case it's put under the /shared namespace. > >> Even so, the vault membership can still be limited to certain > >> users/service instances. Being in /shared doesn't mean it's open for public. > > > > Understood, but if you have the same "service" on multiple machines then > > it quickly becomes difficult to sort it out, I would prefer a logic > > similar that of the user, just with fully qualified service names under > > a /services/ namespace > > The vault namespace is hierarchical, so you can organize it in any way > you want: > * /services/@ > * /shared/services// > > In the current wiki page the service admin can pick the vault name > (/shared/services is just an example), but the secret names in it are > generated from the service principal (to make sure the service admin and > the service instance use the same secret name). Given service passwords is an actual use case I think /services should be a top level namespace available by default. Simo. -- Simo Sorce * Red Hat, Inc * New York