From pviktori at redhat.com Sun Dec 1 22:46:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Sun, 01 Dec 2013 23:46:46 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system Message-ID: <529BBC56.6080103@redhat.com> This seems to work now. Please tell me what I missed. Design: http://www.freeipa.org/page/V3/Permissions_V2 Ticket: https://fedorahosted.org/freeipa/ticket/4034 0322 Allow sets for initialization of frozenset-typed Param keywords because my OCD compels me to use sets instead of lists when the order does not matter. 0323 Allow Declarative test classes to specify the API version For the next patch, I want to test how the rewrite handles old clients. To make that easy I made the default API version a testclass attribute 0324 Add tests for permission plugin with older clients These tests will not pass yet, but comparing this file with the old test_permission_plugin.py will can serve as a nice summary of API changes. A summary of the summary: - Lots of new attributes will be added for output - The `type` and `subtree` options now interact in a different way: setting one affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. (Some change here was necessary for https://fedorahosted.org/freeipa/ticket/2355) - Validation will be stricter (and/or done in different order) - Some error messages will change (hopefully for the better) - `subtree` must now point to an existing entry - Permission names may now contain '.' (this is to allow names of DNS permissions that were previously internal) P.S. a handy command for listing the changes (once this patch is applied): git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py ipatests/test_xmlrpc/test_old_permission_plugin.py 0325 Add new permission schema Introducing the new OIDs 0326 Rewrite the Permission plugin See the design for what this does. The new permission plugin does not use aci plugin at all. The plan is to retire the aci plugin when the time comes to also refactor delegation & selfservice. It does use ipalib's ACI class, mainly for parsing (needed for upgrading/showing old ACIs). The permission-find command is a bit faster than the old one, but still painfully slow (5s instead of 7s on my box). The good news is that it now scales with the number of *old* permissions, so as you upgrade it'll get faster. Tests are updated, including privilege and DNS tests that worked with permissions. 0327 Verify ACIs are added correctly in tests Right after saying I want to get rid of it, I found a new use for the aci plugin: an tested code path for getting at ACIs (Declaratrive tests can only use the API, they don't play well with LDAP connections). Now we can be sure the ACIs are actually changed when we play with permissions. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0322-Allow-sets-for-initialization-of-frozenset-typed-Par.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0323-Allow-Declarative-test-classes-to-specify-the-API-ve.patch Type: text/x-patch Size: 1268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0324-Add-tests-for-permission-plugin-with-older-clients.patch Type: text/x-patch Size: 44630 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0325-Add-new-permission-schema.patch Type: text/x-patch Size: 4364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0326-Rewrite-the-Permission-plugin.patch Type: text/x-patch Size: 136117 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0327-Verify-ACIs-are-added-correctly-in-tests.patch Type: text/x-patch Size: 20000 bytes Desc: not available URL: From dpal at redhat.com Mon Dec 2 03:38:18 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 01 Dec 2013 22:38:18 -0500 Subject: [Freeipa-devel] [PATCH] 0128 subdomains: Use AD admin credentials when trust is being established In-Reply-To: <20131129114521.GU21264@redhat.com> References: <20131127102755.GK21264@redhat.com> <20131128130449.GR21264@redhat.com> <20131129095420.GV3414@localhost.localdomain> <20131129114521.GU21264@redhat.com> Message-ID: <529C00AA.6040205@redhat.com> On 11/29/2013 06:45 AM, Alexander Bokovoy wrote: > So if we want to open a ticket, it should be a ticket to implement > syncrepl protocol support in the DAL driver rather than any research. If we open such ticket we need to tell the whole story and explain why. Just having the RFE to switch DAL to syncrepl would not be enough information during triage and later prioritization. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Mon Dec 2 04:36:37 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Dec 2013 06:36:37 +0200 Subject: [Freeipa-devel] [PATCH] 0128 subdomains: Use AD admin credentials when trust is being established In-Reply-To: <529C00AA.6040205@redhat.com> References: <20131127102755.GK21264@redhat.com> <20131128130449.GR21264@redhat.com> <20131129095420.GV3414@localhost.localdomain> <20131129114521.GU21264@redhat.com> <529C00AA.6040205@redhat.com> Message-ID: <20131202043637.GB3200@redhat.com> On Sun, 01 Dec 2013, Dmitri Pal wrote: >On 11/29/2013 06:45 AM, Alexander Bokovoy wrote: >> So if we want to open a ticket, it should be a ticket to implement >> syncrepl protocol support in the DAL driver rather than any research. > >If we open such ticket we need to tell the whole story and explain why. >Just having the RFE to switch DAL to syncrepl would not be enough >information during triage and later prioritization. There is actually one ticket: https://fedorahosted.org/freeipa/ticket/1302 It was filed before syncrepl appeared, I think. -- / Alexander Bokovoy From pviktori at redhat.com Mon Dec 2 11:14:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 12:14:07 +0100 Subject: [Freeipa-devel] [PATCHES] 204-205 Spec file fixes In-Reply-To: <5295F8BC.7050604@redhat.com> References: <5295F2FC.9090601@redhat.com> <5295F8BC.7050604@redhat.com> Message-ID: <529C6B7F.6020301@redhat.com> On 11/27/2013 02:50 PM, Martin Kosek wrote: > On 11/27/2013 02:26 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . This fixes points 2) & 3) in the ticket; point 1) is not applicable; 4) are false positives. The checks mentioned in the ticket pass. $ hardening-check --color --verbose /usr/libexec/ipa-otpd /usr/libexec/ipa-otpd: Position Independent Executable: yes Stack protected: yes Fortify Source functions: yes (some protected functions found) unprotected: gethostname unprotected: read protected: vfprintf protected: asprintf protected: memcpy protected: fprintf Read-only relocations: yes Immediate binding: yes pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -d /usr/libexec/ipa-otpd | grep BIND_NOW 0x0000000000000018 (BIND_NOW) pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -h /usr/libexec/ipa-otpd | grep Type Type: DYN (Shared object file) (Note, redhat-rpm-config is part of Fedora's minimal build environment: https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2) >> Honza > > Do we want to define > > +%if (0%{?fedora} > 15 || 0%{?rhel} >= 7) > +%define _hardened_build 1 > +%endif > > globally? Wouldn't it trigger the hardening also for all our C utilities or > internal SLAPI plugins? Wouldn't it have performance implication for the SLAPI > plugins? > > I am not sure, I would like to hear what the experts say. > > Martin On 11/27/2013 03:37 PM, Jakub Hrozek wrote:> I'm sorry, I removed Martin's e-mail by accident so I'll reply here. I > think defining the hardened build globally is fine, the only performance > impact is during startup and only small. > > AFAIR, the C utilities in IPA are mostly daemons and you really want to > have full RELRO enabled there. > > The only gotcha we found so far (well, Nalin did) was that SELinux was > not happy with full RELRO on some exotic architectures, like s390x Is that a SELinux bug? Should we care about it? -- Petr? From jhrozek at redhat.com Mon Dec 2 11:26:23 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Dec 2013 12:26:23 +0100 Subject: [Freeipa-devel] [PATCHES] 204-205 Spec file fixes In-Reply-To: <529C6B7F.6020301@redhat.com> References: <5295F2FC.9090601@redhat.com> <5295F8BC.7050604@redhat.com> <529C6B7F.6020301@redhat.com> Message-ID: <20131202112623.GE1958@hendrix.redhat.com> On Mon, Dec 02, 2013 at 12:14:07PM +0100, Petr Viktorin wrote: > On 11/27/2013 02:50 PM, Martin Kosek wrote: > >On 11/27/2013 02:26 PM, Jan Cholasta wrote: > >>Hi, > >> > >>the attached patches fix . > > This fixes points 2) & 3) in the ticket; point 1) is not applicable; > 4) are false positives. > > The checks mentioned in the ticket pass. > > $ hardening-check --color --verbose /usr/libexec/ipa-otpd > /usr/libexec/ipa-otpd: > Position Independent Executable: yes > Stack protected: yes > Fortify Source functions: yes (some protected functions found) > unprotected: gethostname > unprotected: read > protected: vfprintf > protected: asprintf > protected: memcpy > protected: fprintf > Read-only relocations: yes > Immediate binding: yes > pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -d > /usr/libexec/ipa-otpd | grep BIND_NOW > 0x0000000000000018 (BIND_NOW) > pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -h > /usr/libexec/ipa-otpd | grep Type > Type: DYN (Shared object file) > > (Note, redhat-rpm-config is part of Fedora's minimal build > environment: > https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2) > > >>Honza > > > >Do we want to define > > > >+%if (0%{?fedora} > 15 || 0%{?rhel} >= 7) > >+%define _hardened_build 1 > >+%endif > > > >globally? Wouldn't it trigger the hardening also for all our C utilities or > >internal SLAPI plugins? Wouldn't it have performance implication for the SLAPI > >plugins? > > > >I am not sure, I would like to hear what the experts say. > > > >Martin > > On 11/27/2013 03:37 PM, Jakub Hrozek wrote:> I'm sorry, I removed > Martin's e-mail by accident so I'll reply here. I > > think defining the hardened build globally is fine, the only performance > > impact is during startup and only small. > > > > AFAIR, the C utilities in IPA are mostly daemons and you really want to > > have full RELRO enabled there. > > > > The only gotcha we found so far (well, Nalin did) was that SELinux was > > not happy with full RELRO on some exotic architectures, like s390x > > Is that a SELinux bug? I'm not actually sure, as I said, Nalin worked on this bugzilla. FWIW, I never saw any problems with hardened builds of SSSD or any other package I'm involved with. > Should we care about it? I think that such change in build flags warrants at least basic smoke testing on all architectures. From mkosek at redhat.com Mon Dec 2 11:43:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Dec 2013 12:43:34 +0100 Subject: [Freeipa-devel] [PATCHES] 204-205 Spec file fixes In-Reply-To: <20131202112623.GE1958@hendrix.redhat.com> References: <5295F2FC.9090601@redhat.com> <5295F8BC.7050604@redhat.com> <529C6B7F.6020301@redhat.com> <20131202112623.GE1958@hendrix.redhat.com> Message-ID: <529C7266.4000108@redhat.com> On 12/02/2013 12:26 PM, Jakub Hrozek wrote: > On Mon, Dec 02, 2013 at 12:14:07PM +0100, Petr Viktorin wrote: >> On 11/27/2013 02:50 PM, Martin Kosek wrote: >>> On 11/27/2013 02:26 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix . >> >> This fixes points 2) & 3) in the ticket; point 1) is not applicable; >> 4) are false positives. >> >> The checks mentioned in the ticket pass. >> >> $ hardening-check --color --verbose /usr/libexec/ipa-otpd >> /usr/libexec/ipa-otpd: >> Position Independent Executable: yes >> Stack protected: yes >> Fortify Source functions: yes (some protected functions found) >> unprotected: gethostname >> unprotected: read >> protected: vfprintf >> protected: asprintf >> protected: memcpy >> protected: fprintf >> Read-only relocations: yes >> Immediate binding: yes >> pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -d >> /usr/libexec/ipa-otpd | grep BIND_NOW >> 0x0000000000000018 (BIND_NOW) >> pviktori at vm-183:~/freeipa{master}16e60f7$ readelf -h >> /usr/libexec/ipa-otpd | grep Type >> Type: DYN (Shared object file) >> >> (Note, redhat-rpm-config is part of Fedora's minimal build >> environment: >> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2) >> >>>> Honza >>> >>> Do we want to define >>> >>> +%if (0%{?fedora} > 15 || 0%{?rhel} >= 7) >>> +%define _hardened_build 1 >>> +%endif >>> >>> globally? Wouldn't it trigger the hardening also for all our C utilities or >>> internal SLAPI plugins? Wouldn't it have performance implication for the SLAPI >>> plugins? >>> >>> I am not sure, I would like to hear what the experts say. >>> >>> Martin >> >> On 11/27/2013 03:37 PM, Jakub Hrozek wrote:> I'm sorry, I removed >> Martin's e-mail by accident so I'll reply here. I >>> think defining the hardened build globally is fine, the only performance >>> impact is during startup and only small. >>> >>> AFAIR, the C utilities in IPA are mostly daemons and you really want to >>> have full RELRO enabled there. >>> >>> The only gotcha we found so far (well, Nalin did) was that SELinux was >>> not happy with full RELRO on some exotic architectures, like s390x >> >> Is that a SELinux bug? > > I'm not actually sure, as I said, Nalin worked on this bugzilla. FWIW, I > never saw any problems with hardened builds of SSSD or any other package > I'm involved with. > >> Should we care about it? > > I think that such change in build flags warrants at least basic smoke > testing on all architectures. I talked to Jakub, we will deal with it in the similar way as nss-pam-ldapd did. In case of issues, we would turn off the hardening for the specific architectures. Anyway, I think current state of the patch is OK for now. So ACK, pushed both patches to master, ipa-3-3. Martin From pviktori at redhat.com Mon Dec 2 11:51:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 12:51:22 +0100 Subject: [Freeipa-devel] [PATCH] 203 Remove mod_ssl port workaround In-Reply-To: <20131129145001.GX21264@redhat.com> References: <52948339.1020106@redhat.com> <52949932.3030808@redhat.com> <20131126131557.GD21264@redhat.com> <5294A107.1070507@redhat.com> <20131126133555.GE21264@redhat.com> <5298A4ED.5020900@redhat.com> <5298A57A.3070300@redhat.com> <20131129145001.GX21264@redhat.com> Message-ID: <529C743A.70407@redhat.com> On 11/29/2013 03:50 PM, Alexander Bokovoy wrote: > On Fri, 29 Nov 2013, Martin Kosek wrote: >> On 11/29/2013 03:30 PM, Petr Viktorin wrote: >>> On 11/26/2013 02:35 PM, Alexander Bokovoy wrote: >>>> On Tue, 26 Nov 2013, Petr Viktorin wrote: >>>>> On 11/26/2013 02:15 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 26 Nov 2013, Petr Viktorin wrote: >>>>>>> On 11/26/2013 12:17 PM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patch fixes >>>>>>>> . >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> I assume a build of httpd >= 2.4.6-6 is not planned for Fedora >>>>>>> 19, so >>>>>>> master is now f20+ only. Is that right? >>>>>> Is this bad? >>>>>> >>>>>> Given that we are close to F20 release, I'd prefer to concentrate on >>>>>> polishing and testing F20. >>>>> >>>>> Well, for me it means updating the infrastructure I use for >>>>> development, including internal CI. It'll cost me some time, which I >>>>> currently don't have a lot of. >>>> Could we switch CI to track 3.3 branch for pre-F20? >>> >>> I just realized we have a problem here: this patch also went to ipa-3-3. >>> That means 3.3 is currently also f20+ only. >>> >> >> I see two options here: >> >> 1) Update the CI FreeIPA build instruction and remove the F20 httpd >> Requires. >> All tests should still work as long as mod_ssl is not installed. > 3.3 shouldn't need this require, so we should back out the patch from > there. > That makes sense. Reverted in ipa-3-3: c6a15335b0406c9d7d57378cbdd9b20252438f65 -- Petr? From mkosek at redhat.com Mon Dec 2 12:04:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Dec 2013 13:04:16 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <529BBC56.6080103@redhat.com> References: <529BBC56.6080103@redhat.com> Message-ID: <529C7740.7090601@redhat.com> On 12/01/2013 11:46 PM, Petr Viktorin wrote: > This seems to work now. Please tell me what I missed. > > Design: http://www.freeipa.org/page/V3/Permissions_V2 > Ticket: https://fedorahosted.org/freeipa/ticket/4034 > > > 0322 Allow sets for initialization of frozenset-typed Param keywords > because my OCD compels me to use sets instead of lists when the order does not > matter. > > > 0323 Allow Declarative test classes to specify the API version > For the next patch, I want to test how the rewrite handles old clients. To make > that easy I made the default API version a testclass attribute > > > 0324 Add tests for permission plugin with older clients > These tests will not pass yet, but comparing this file with the old > test_permission_plugin.py will can serve as a nice summary of API changes. A > summary of the summary: > - Lots of new attributes will be added for output > - The `type` and `subtree` options now interact in a different way: setting one > affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. > (Some change here was necessary for https://fedorahosted.org/freeipa/ticket/2355) > - Validation will be stricter (and/or done in different order) > - Some error messages will change (hopefully for the better) > - `subtree` must now point to an existing entry > - Permission names may now contain '.' (this is to allow names of DNS > permissions that were previously internal) > > P.S. a handy command for listing the changes (once this patch is applied): > git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py > ipatests/test_xmlrpc/test_old_permission_plugin.py > > > 0325 Add new permission schema > Introducing the new OIDs > > > 0326 Rewrite the Permission plugin > See the design for what this does. > > The new permission plugin does not use aci plugin at all. The plan is to retire > the aci plugin when the time comes to also refactor delegation & selfservice. > It does use ipalib's ACI class, mainly for parsing (needed for > upgrading/showing old ACIs). > > The permission-find command is a bit faster than the old one, but still > painfully slow (5s instead of 7s on my box). The good news is that it now > scales with the number of *old* permissions, so as you upgrade it'll get faster. > > Tests are updated, including privilege and DNS tests that worked with permissions. > > > 0327 Verify ACIs are added correctly in tests > Right after saying I want to get rid of it, I found a new use for the aci > plugin: an tested code path for getting at ACIs (Declaratrive tests can only > use the API, they don't play well with LDAP connections). > Now we can be sure the ACIs are actually changed when we play with permissions. > Great job! I read through the code and did few tests, this is what I've found so far: 1) When I tried to move ACI to non-existent DN, I got a general error + the underlying ACI was gone: # ipa permission-mod "Write Group Description" --subtree=foo=bar ipa: ERROR: no such entry When I then tried to delete it, I got Internal Error: # ipa permission-del "Write Group Description" ipa: ERROR: an internal error has occurred ... /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in pre_callback [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] self.obj.remove_aci(entry) [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in remove_aci [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] self._replace_aci(permission_entry) [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in _replace_aci [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn # pylint: disable=E1103 [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' object has no attribute 'dn' I think we should add a check for that + at least try to rollback if we fail to move the ACI. 2) In filter check: + # Rough filter validation by a search + if self.env.in_server and 'ipapermtargetfilter' in options: + ldap = self.Backend.ldap2 + try: + ldap.find_entries( + filter=options['ipapermtargetfilter'], + base_dn=self.env.basedn, + size_limit=0) This is great for starters, but I would make it less costly and only search with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches across whole database. 3) I see that I can add ALL bind type permission as a member to a privilege: # ipa permission-show "Write Group Description 2" Permission name: Write Group Description 2 Permissions: write Attributes: description Bind rule type: all Subtree: cn=groups,cn=accounts,dc=example,dc=com ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com Type: group # ipa privilege-add-permission foo --permissions "Write Group Description 2" Privilege name: foo Description: foo Permissions: write group description 2 ----------------------------- Number of permissions added 1 ----------------------------- Is this a bug or do you already plan to fix it later? 4) Typo in refactored permission plugin: + errors.NotFound('ACI of to permission %s was not found' % + keys[0]) Martin From pviktori at redhat.com Mon Dec 2 12:30:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 13:30:38 +0100 Subject: [Freeipa-devel] [PATCHES] 0014, 0016 [RFE] ipa migrate-ds should have an argument to specify cert to use for DS connection In-Reply-To: <1385050497.2245.1.camel@unused-4-145.brq.redhat.com> References: <1382108445.2362.1.camel@unused-4-145.brq.redhat.com> <5264D7E5.7000407@redhat.com> <1382344152.2237.6.camel@unused-4-145.brq.redhat.com> <528B3017.6090101@redhat.com> <1385050497.2245.1.camel@unused-4-145.brq.redhat.com> Message-ID: <529C7D6E.1020208@redhat.com> On 11/21/2013 05:14 PM, Martin Basti wrote: > On Tue, 2013-11-19 at 10:32 +0100, Petr Viktorin wrote: >> On 10/21/2013 10:29 AM, Martin Basti wrote: >>> On Mon, 2013-10-21 at 09:29 +0200, Martin Kosek wrote: >>>> On 10/18/2013 05:00 PM, Martin Basti wrote: >>>>> Patch attached. >>>>> >>>>> Ticket: >>>>> https://fedorahosted.org/freeipa/ticket/3243 >>>>> >>>> >>>> I did not test the patch, just looked at the code and I have few comments: >>>> >>>> 1) Please put the ipalib/cli.py change to a sepparate change, we may want to >>>> backport it separately some day and this will make it easier. >>>> >>> Separated. >>> Patch 0014-2 -- CLI >> >> Nitpick: if you switched them around it would be easier to read*: >> if raw: >> decode >> elif required: >> raise >> *(at least for me, I need way too much concentration to process boolean >> logic) >> > Switched. >> >>> Patch 0016 -- migration >> >> We have a utility, ipautil.write_tmp_file, that should do what you need >> here. >> With this the created file is removed some time later when there are no >> more references to the file object, so no need for the try: block. >> (btw, if the try block was necessary, it should have also covered the >> write() call.) >> > Fixed > >> Also, since you changed the API, please run ./makeapi and bump the API >> version in the VERSION file. > Added > > Thank you for review > Updated patches attached > Thanks! ACK, pushed to master: efffcfdbc24ad81d48c7b65443a75928b156cc49 -- Petr? From pviktori at redhat.com Mon Dec 2 12:58:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 13:58:23 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <52988D19.5040504@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> Message-ID: <529C83EF.9010408@redhat.com> On 11/29/2013 01:48 PM, Martin Kosek wrote: > On 11/19/2013 12:35 PM, Petr Viktorin wrote: >> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>> Server and client installer should allow kernel keyring ccache when >>> supported. >> >> How do I enable the kernel keyring? On f20 I get this: >> >> 2013-11-19T11:28:07Z DEBUG Starting external process >> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >> 2013-11-19T11:28:07Z DEBUG stdout= >> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked > > It should be enabled out of the box. But there were some initial issues with > persistent keyring in the first versions of kernel with a support, hopefully > this was just a fluke which disappeared. > > This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: > > # keyctl get_persistent @s 0 > 637466038 With kernel-3.11.10-300.fc20.x86_64, I get an error again: $ keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked I don't know much about the kernel keyring, so I'm lost as to what the message is trying to tell me. -- Petr? From mkosek at redhat.com Mon Dec 2 13:01:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Dec 2013 14:01:25 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529C83EF.9010408@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> Message-ID: <529C84A5.2030805@redhat.com> On 12/02/2013 01:58 PM, Petr Viktorin wrote: > On 11/29/2013 01:48 PM, Martin Kosek wrote: >> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>> Server and client installer should allow kernel keyring ccache when >>>> supported. > >>> >>> How do I enable the kernel keyring? On f20 I get this: >>> >>> 2013-11-19T11:28:07Z DEBUG Starting external process >>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>> 2013-11-19T11:28:07Z DEBUG stdout= >>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked >> >> It should be enabled out of the box. But there were some initial issues with >> persistent keyring in the first versions of kernel with a support, hopefully >> this was just a fluke which disappeared. >> >> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >> >> # keyctl get_persistent @s 0 >> 637466038 > > With kernel-3.11.10-300.fc20.x86_64, I get an error again: > $ keyctl get_persistent @s 0 > keyctl_get_persistent: Key has been revoked Not sure if it is a typo, but you won't surely get a root's keyring as a non-root user... Martin From simo at redhat.com Mon Dec 2 13:29:33 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Dec 2013 08:29:33 -0500 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <5298B805.4080100@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> Message-ID: <1385990973.14987.56.camel@willson.li.ssimo.org> On Fri, 2013-11-29 at 16:51 +0100, Petr Viktorin wrote: > I've updated the design with > - updated schema (this time the OIDs are even reserved properly!) > - longer attribute descriptions with examples > - updated update algorithm based on discussion with Simo Hi Petr, thank you for the update. > Additionally, I've updated draft designs this one references [0, 1]. The > CLI/API parts of those aren't finished but the LDAP should be ready for > criticism. It would be very nice if you can add the resulting LDAP objects in the example, that will allow me to reason on the correctness of the translation. > For examples, I felt that anything I show as an example should also go > in the test suite, so I added the tests. (If you're into wiki design I'd > appreciate ideas about how to make that section better.) > If you need any more examples, or see some dangerous corner cases, tell > me and I'll add them. > > There is still a race condition when the subtree changes, e.g. when > you'd move an ACI from $SUFFIX to cn=users,cn=accounts,$SUFFIX, the > rights are revoked between the times the ACI is removed and re-added. > At this point I'd rather document it and file a bug (and possibly start > working on it right after this) than redo the internals in yet another > way in the same update. I think that this will be fine, *after* we change the default mode to deny everything, and rely on permissions to allow. This way the lack of an ACI will deny (not permit!) access to arbitrary attributes. > [0] http://www.freeipa.org/page/V3/Anonymous_and_All_permissions > [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > > > PS. the hack I used to generate the test plan for mediawiki is here: > https://github.com/encukou/ipa-tools/blob/master/mw-format-tests.py Haven't read all the way through thetest code, but having tests is excellent. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Dec 2 13:32:31 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Dec 2013 08:32:31 -0500 Subject: [Freeipa-devel] [PATCH] 0128 subdomains: Use AD admin credentials when trust is being established In-Reply-To: <20131129203407.GY21264@redhat.com> References: <20131127102755.GK21264@redhat.com> <20131128130449.GR21264@redhat.com> <1385749212.14987.51.camel@willson.li.ssimo.org> <20131129203407.GY21264@redhat.com> Message-ID: <1385991151.14987.57.camel@willson.li.ssimo.org> On Fri, 2013-11-29 at 22:34 +0200, Alexander Bokovoy wrote: > On Fri, 29 Nov 2013, Simo Sorce wrote: > >sorry if this has already been doced somewhere, but any reason why you > >can't use Kerberos auth with the AD user ? > I think I had some issues with that early in the development, cannot > remember right now what was it. > > Can you file a ticket so that we look at refactoring it later? > Done. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Dec 2 13:48:40 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 14:48:40 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <1385990973.14987.56.camel@willson.li.ssimo.org> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> Message-ID: <529C8FB8.9020503@redhat.com> On 12/02/2013 02:29 PM, Simo Sorce wrote: > On Fri, 2013-11-29 at 16:51 +0100, Petr Viktorin wrote: > >> I've updated the design with >> - updated schema (this time the OIDs are even reserved properly!) >> - longer attribute descriptions with examples >> - updated update algorithm based on discussion with Simo > > Hi Petr, > thank you for the update. > >> Additionally, I've updated draft designs this one references [0, 1]. The >> CLI/API parts of those aren't finished but the LDAP should be ready for >> criticism. > > It would be very nice if you can add the resulting LDAP objects in the > example, that will allow me to reason on the correctness of the > translation. OK, I'll work on that. >> For examples, I felt that anything I show as an example should also go >> in the test suite, so I added the tests. (If you're into wiki design I'd >> appreciate ideas about how to make that section better.) >> If you need any more examples, or see some dangerous corner cases, tell >> me and I'll add them. >> >> There is still a race condition when the subtree changes, e.g. when >> you'd move an ACI from $SUFFIX to cn=users,cn=accounts,$SUFFIX, the >> rights are revoked between the times the ACI is removed and re-added. >> At this point I'd rather document it and file a bug (and possibly start >> working on it right after this) than redo the internals in yet another >> way in the same update. > > I think that this will be fine, *after* we change the default mode to > deny everything, and rely on permissions to allow. This way the lack of > an ACI will deny (not permit!) access to arbitrary attributes. Permissions can only allow access. All our deny ACIs are built in, not controlled by permissions. >> [0] http://www.freeipa.org/page/V3/Anonymous_and_All_permissions >> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions -- Petr? From pviktori at redhat.com Mon Dec 2 13:51:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 14:51:53 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529C84A5.2030805@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> Message-ID: <529C9079.5010403@redhat.com> On 12/02/2013 02:01 PM, Martin Kosek wrote: > On 12/02/2013 01:58 PM, Petr Viktorin wrote: >> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>> Server and client installer should allow kernel keyring ccache when >>>>> supported. >> >>>> >>>> How do I enable the kernel keyring? On f20 I get this: >>>> >>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked >>> >>> It should be enabled out of the box. But there were some initial issues with >>> persistent keyring in the first versions of kernel with a support, hopefully >>> this was just a fluke which disappeared. >>> >>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>> >>> # keyctl get_persistent @s 0 >>> 637466038 >> >> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >> $ keyctl get_persistent @s 0 >> keyctl_get_persistent: Key has been revoked > > Not sure if it is a typo, but you won't surely get a root's keyring as a > non-root user... It is just a typo, but it looks like you got me on the right track. keyctl apparently needs a real root login: $ sudo keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked $ sudo su # keyctl get_persistent @s 0 keyctl_get_persistent: Key has been revoked # exit $ sudo su - Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 # keyctl get_persistent @s 0 968622527 # logout Unsurprisingly, when ipa-server-install is run from sudo, it complains that the key is unsupported. From a root login all is OK. Is that expected? -- Petr? From abokovoy at redhat.com Mon Dec 2 14:00:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Dec 2013 16:00:16 +0200 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529C9079.5010403@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> Message-ID: <20131202140016.GA21264@redhat.com> On Mon, 02 Dec 2013, Petr Viktorin wrote: >On 12/02/2013 02:01 PM, Martin Kosek wrote: >>On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>Server and client installer should allow kernel keyring ccache when >>>>>>supported. >>> >>>>> >>>>>How do I enable the kernel keyring? On f20 I get this: >>>>> >>>>>2013-11-19T11:28:07Z DEBUG Starting external process >>>>>2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>2013-11-19T11:28:07Z DEBUG stdout= >>>>>2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked >>>> >>>>It should be enabled out of the box. But there were some initial issues with >>>>persistent keyring in the first versions of kernel with a support, hopefully >>>>this was just a fluke which disappeared. >>>> >>>>This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>> >>>># keyctl get_persistent @s 0 >>>>637466038 >>> >>>With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>$ keyctl get_persistent @s 0 >>>keyctl_get_persistent: Key has been revoked >> >>Not sure if it is a typo, but you won't surely get a root's keyring as a >>non-root user... > >It is just a typo, but it looks like you got me on the right track. >keyctl apparently needs a real root login: > >$ sudo keyctl get_persistent @s 0 >keyctl_get_persistent: Key has been revoked > >$ sudo su ># keyctl get_persistent @s 0 >keyctl_get_persistent: Key has been revoked ># exit > >$ sudo su - >Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 ># keyctl get_persistent @s 0 >968622527 ># logout > > >Unsurprisingly, when ipa-server-install is run from sudo, it >complains that the key is unsupported. From a root login all is OK. > >Is that expected? Yes. Unless you are using 'sudo -i', sudo is not equal to 'su -'. Look to sudoers(5), section 'Command environment'. -- / Alexander Bokovoy From simo at redhat.com Mon Dec 2 14:42:02 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Dec 2013 09:42:02 -0500 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529C9079.5010403@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> Message-ID: <1385995322.14987.70.camel@willson.li.ssimo.org> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: > On 12/02/2013 02:01 PM, Martin Kosek wrote: > > On 12/02/2013 01:58 PM, Petr Viktorin wrote: > >> On 11/29/2013 01:48 PM, Martin Kosek wrote: > >>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: > >>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: > >>>>> Server and client installer should allow kernel keyring ccache when > >>>>> supported. > >> > >>>> > >>>> How do I enable the kernel keyring? On f20 I get this: > >>>> > >>>> 2013-11-19T11:28:07Z DEBUG Starting external process > >>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 > >>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 > >>>> 2013-11-19T11:28:07Z DEBUG stdout= > >>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked > >>> > >>> It should be enabled out of the box. But there were some initial issues with > >>> persistent keyring in the first versions of kernel with a support, hopefully > >>> this was just a fluke which disappeared. > >>> > >>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: > >>> > >>> # keyctl get_persistent @s 0 > >>> 637466038 > >> > >> With kernel-3.11.10-300.fc20.x86_64, I get an error again: > >> $ keyctl get_persistent @s 0 > >> keyctl_get_persistent: Key has been revoked > > > > Not sure if it is a typo, but you won't surely get a root's keyring as a > > non-root user... > > It is just a typo, but it looks like you got me on the right track. > keyctl apparently needs a real root login: > > $ sudo keyctl get_persistent @s 0 > keyctl_get_persistent: Key has been revoked > > $ sudo su > # keyctl get_persistent @s 0 > keyctl_get_persistent: Key has been revoked > # exit > > $ sudo su - > Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 > # keyctl get_persistent @s 0 > 968622527 > # logout > Please use "sudo -i" to get an interactive 'login' shell. > Unsurprisingly, when ipa-server-install is run from sudo, it complains > that the key is unsupported. From a root login all is OK. > > Is that expected? You should run ipa-server-install using a login shell I think. Should we open a bug to detect this and fail ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Dec 2 15:05:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Dec 2013 16:05:06 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <1385995322.14987.70.camel@willson.li.ssimo.org> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> Message-ID: <529CA1A2.9020509@redhat.com> On 12/02/2013 03:42 PM, Simo Sorce wrote: > On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>> supported. >>>> >>>>>> >>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>> >>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been revoked >>>>> >>>>> It should be enabled out of the box. But there were some initial issues with >>>>> persistent keyring in the first versions of kernel with a support, hopefully >>>>> this was just a fluke which disappeared. >>>>> >>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>> >>>>> # keyctl get_persistent @s 0 >>>>> 637466038 >>>> >>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>> $ keyctl get_persistent @s 0 >>>> keyctl_get_persistent: Key has been revoked >>> >>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>> non-root user... >> >> It is just a typo, but it looks like you got me on the right track. >> keyctl apparently needs a real root login: >> >> $ sudo keyctl get_persistent @s 0 >> keyctl_get_persistent: Key has been revoked >> >> $ sudo su >> # keyctl get_persistent @s 0 >> keyctl_get_persistent: Key has been revoked >> # exit >> >> $ sudo su - >> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >> # keyctl get_persistent @s 0 >> 968622527 >> # logout >> > > Please use "sudo -i" to get an interactive 'login' shell. > >> Unsurprisingly, when ipa-server-install is run from sudo, it complains >> that the key is unsupported. From a root login all is OK. >> >> Is that expected? > > You should run ipa-server-install using a login shell I think. > Should we open a bug to detect this and fail ? It's always worked with just sudo for me. So yes, if it's required I think we should enforce it. -- Petr? From mkosek at redhat.com Mon Dec 2 15:17:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Dec 2013 16:17:21 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529CA1A2.9020509@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> <529CA1A2.9020509@redhat.com> Message-ID: <529CA481.7050000@redhat.com> On 12/02/2013 04:05 PM, Petr Viktorin wrote: > On 12/02/2013 03:42 PM, Simo Sorce wrote: >> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >>> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>>> supported. >>>>> >>>>>>> >>>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>>> >>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been >>>>>>> revoked >>>>>> >>>>>> It should be enabled out of the box. But there were some initial issues with >>>>>> persistent keyring in the first versions of kernel with a support, hopefully >>>>>> this was just a fluke which disappeared. >>>>>> >>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>>> >>>>>> # keyctl get_persistent @s 0 >>>>>> 637466038 >>>>> >>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>>> $ keyctl get_persistent @s 0 >>>>> keyctl_get_persistent: Key has been revoked >>>> >>>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>>> non-root user... >>> >>> It is just a typo, but it looks like you got me on the right track. >>> keyctl apparently needs a real root login: >>> >>> $ sudo keyctl get_persistent @s 0 >>> keyctl_get_persistent: Key has been revoked >>> >>> $ sudo su >>> # keyctl get_persistent @s 0 >>> keyctl_get_persistent: Key has been revoked >>> # exit >>> >>> $ sudo su - >>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >>> # keyctl get_persistent @s 0 >>> 968622527 >>> # logout >>> >> >> Please use "sudo -i" to get an interactive 'login' shell. >> >>> Unsurprisingly, when ipa-server-install is run from sudo, it complains >>> that the key is unsupported. From a root login all is OK. >>> >>> Is that expected? >> >> You should run ipa-server-install using a login shell I think. >> Should we open a bug to detect this and fail ? > > It's always worked with just sudo for me. So yes, if it's required I think we > should enforce it. > Simo or Alexander, is there some way to find that out in a clean way? I mean if we are in an interactive login shell. Ideally, please also file a bug with this information :) Thanks, Martin From abokovoy at redhat.com Mon Dec 2 16:20:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Dec 2013 18:20:44 +0200 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <529CA481.7050000@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> <529CA1A2.9020509@redhat.com> <529CA481.7050000@redhat.com> Message-ID: <20131202162044.GC21264@redhat.com> On Mon, 02 Dec 2013, Martin Kosek wrote: >On 12/02/2013 04:05 PM, Petr Viktorin wrote: >> On 12/02/2013 03:42 PM, Simo Sorce wrote: >>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >>>> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>>>> supported. >>>>>> >>>>>>>> >>>>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>>>> >>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been >>>>>>>> revoked >>>>>>> >>>>>>> It should be enabled out of the box. But there were some initial issues with >>>>>>> persistent keyring in the first versions of kernel with a support, hopefully >>>>>>> this was just a fluke which disappeared. >>>>>>> >>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>>>> >>>>>>> # keyctl get_persistent @s 0 >>>>>>> 637466038 >>>>>> >>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>>>> $ keyctl get_persistent @s 0 >>>>>> keyctl_get_persistent: Key has been revoked >>>>> >>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>>>> non-root user... >>>> >>>> It is just a typo, but it looks like you got me on the right track. >>>> keyctl apparently needs a real root login: >>>> >>>> $ sudo keyctl get_persistent @s 0 >>>> keyctl_get_persistent: Key has been revoked >>>> >>>> $ sudo su >>>> # keyctl get_persistent @s 0 >>>> keyctl_get_persistent: Key has been revoked >>>> # exit >>>> >>>> $ sudo su - >>>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >>>> # keyctl get_persistent @s 0 >>>> 968622527 >>>> # logout >>>> >>> >>> Please use "sudo -i" to get an interactive 'login' shell. >>> >>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains >>>> that the key is unsupported. From a root login all is OK. >>>> >>>> Is that expected? >>> >>> You should run ipa-server-install using a login shell I think. >>> Should we open a bug to detect this and fail ? >> >> It's always worked with just sudo for me. So yes, if it's required I think we >> should enforce it. >> > >Simo or Alexander, is there some way to find that out in a clean way? I mean if >we are in an interactive login shell. Ideally, please also file a bug with this >information :) Interactive or login? These two are different a bit. There is no general way because not all shells implement common approach to detect this. For example, echo $- | grep -q i would work in a Bourne-style shell for interactive shell shopt -q login_shell would give you a login shell detector in bash but test $options[LOGIN] = on would work for login shell in zsh, similarly INTERACTIVE index would give you state of interactive shell. -- / Alexander Bokovoy From pviktori at redhat.com Tue Dec 3 09:52:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Dec 2013 10:52:49 +0100 Subject: [Freeipa-devel] [PATCHES] 0328-0329 test_integration: Support external names for hosts Message-ID: <529DA9F1.1050902@redhat.com> Hello, Patch 0328 fixes the problem that I filed [4038] for: CA-less tests fail when run in some setups on Beaker. What the ticket says was premature diagnosis; I'll close the ticket as invalid. See commit message for the real problem. Patch 0329 adds a bit more info to logs. [4038] https://fedorahosted.org/freeipa/ticket/4038 tests: Forwarder is not set on replicas -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0328-test_integration-Support-external-names-for-hosts.patch Type: text/x-patch Size: 3863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0329-test_integration-Log-external-hostname-in-Host.ldap_.patch Type: text/x-patch Size: 1113 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 3 13:54:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Dec 2013 14:54:30 +0100 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1385654393.14947.26.camel@localhost.localdomain> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> <1379695123.1629.10.camel@localhost> <1380142563.2046.3.camel@localhost> <527CD870.9080102@redhat.com> <1384211875.5798.18.camel@localhost.localdomain> <528606D5.8060308@redhat.com> <1385058840.28271.11.camel@localhost.localdomain> <5295D74D.3030402@redhat.com> <1385590842.14947.25.camel@localhost.localdomain> <5297268A.80405@redhat.com> <1385654393.14947.26.camel@localhost.localdomain> Message-ID: <529DE296.2010602@redhat.com> On 11/28/2013 04:59 PM, Nathaniel McCallum wrote: > Everything looks good to me. +1 Pushed to master: a1f32fa9369109235dba041de9c972da09d8448a -- Petr? From pspacek at redhat.com Tue Dec 3 14:23:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 03 Dec 2013 15:23:32 +0100 Subject: [Freeipa-devel] [PATCH 0005] Clarify error message about IPv6 socket creation in ipa-cldap plugi Message-ID: <529DE964.50309@redhat.com> Hello, Clarify error message about IPv6 socket creation in ipa-cldap plugin. https://fedorahosted.org/freeipa/ticket/4056 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0005-Clarify-error-message-about-IPv6-socket-creation-in-.patch Type: text/x-patch Size: 1074 bytes Desc: not available URL: From simo at redhat.com Tue Dec 3 14:26:46 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 Dec 2013 09:26:46 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags Message-ID: <1386080806.14987.87.camel@willson.li.ssimo.org> Some tags escaped the relicensing we did a long time ago. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-505-Fix-license-tag-in-python-setup-files.patch Type: text/x-patch Size: 1261 bytes Desc: not available URL: From mkosek at redhat.com Tue Dec 3 15:27:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Dec 2013 16:27:35 +0100 Subject: [Freeipa-devel] [PATCH 0005] Clarify error message about IPv6 socket creation in ipa-cldap plugi In-Reply-To: <529DE964.50309@redhat.com> References: <529DE964.50309@redhat.com> Message-ID: <529DF867.1050208@redhat.com> On 12/03/2013 03:23 PM, Petr Spacek wrote: > Hello, > > Clarify error message about IPv6 socket creation in ipa-cldap plugin. > > https://fedorahosted.org/freeipa/ticket/4056 ACK. Pushed to master. Martin From mkosek at redhat.com Wed Dec 4 12:11:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Dec 2013 13:11:04 +0100 Subject: [Freeipa-devel] Troubleshooting FreeIPA Message-ID: <529F1BD8.3090405@redhat.com> Hello all, I have started a Troubleshooting page which should help FreeIPA users troubleshoot and report bugs. The first attempt can be found here: http://www.freeipa.org/page/Troubleshooting This is mostly a brain dump of the most common issues I could think of. I would like to ask developers to help me extend it and add more information as it should help us a better portion of user issues before they even ask + if they ask, the page should help them attach the right data. Thanks in advance! -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From dpal at redhat.com Wed Dec 4 14:31:11 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Dec 2013 09:31:11 -0500 Subject: [Freeipa-devel] Troubleshooting FreeIPA In-Reply-To: <529F1BD8.3090405@redhat.com> References: <529F1BD8.3090405@redhat.com> Message-ID: <529F3CAF.9030404@redhat.com> On 12/04/2013 07:11 AM, Martin Kosek wrote: > Hello all, > > I have started a Troubleshooting page which should help FreeIPA users > troubleshoot and report bugs. The first attempt can be found here: > > http://www.freeipa.org/page/Troubleshooting > > This is mostly a brain dump of the most common issues I could think of. I would > like to ask developers to help me extend it and add more information as it > should help us a better portion of user issues before they even ask + if they > ask, the page should help them attach the right data. > > Thanks in advance! > This is a good start. I suggest we have a template section - a checklist that would help people to prepare an email to the list. Here is a proposed outline with example data: Distro/OS with version: Fedora 19 Component: IPA server Feature: Certificate management Package version(s): ipa_..._3.0_..._.rpm Problem description: Certificates are not renewed. What I have tried: Looked at X, here is output Looked at Y, here is output ... Corresponding sanitized logs: ... ... Urgency: I found a workaround but it would be nice to get it fixed. Recommendations: May be a message should be more clear like this "blah, blah..." Did I miss anything? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Thu Dec 5 10:15:19 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 05 Dec 2013 11:15:19 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build Message-ID: <52A05237.2030904@redhat.com> Hi, the attached patches fix . Patch 207 should fix build failures some of you were having after hardenening was enabled in the spec file. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-206-Prefer-user-CFLAGS-CPPFLAGS-over-those-provided-by-r.patch Type: text/x-patch Size: 854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-207-Include-LDFLAGS-provided-by-rpmbuild-in-global-LDFLA.patch Type: text/x-patch Size: 1367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-208-Add-stricter-default-CFLAGS-to-Makefile.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-209-Fix-compilation-error-in-ipa-cldap.patch Type: text/x-patch Size: 1010 bytes Desc: not available URL: From abokovoy at redhat.com Thu Dec 5 11:51:11 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Dec 2013 13:51:11 +0200 Subject: [Freeipa-devel] [PATCH] 0129 fix trust.get_dn to distinguish creating and re-adding trusts Message-ID: <20131205115111.GL21264@redhat.com> Latest support for subdomains introduced regression that masked difference between newly added trust and re-added one. Additionally, in case no new subdomains were found, the code was returning None instead of an empty list which later could confuse trustdomain-find command. https://fedorahosted.org/freeipa/ticket/4067 -- / Alexander Bokovoy -------------- next part -------------- >From ee9282a90da3c9802c9d9d8330f3983c479614ac Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 5 Dec 2013 13:47:37 +0200 Subject: [PATCH 2/2] trust: fix get_dn() to distinguish creating and re-adding trusts Latest support for subdomains introduced regression that masked difference between newly added trust and re-added one. Additionally, in case no new subdomains were found, the code was returning None instead of an empty list which later could confuse trustdomain-find command. https://fedorahosted.org/freeipa/ticket/4067 --- ipalib/plugins/trust.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3b1b2fc..76d609f 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -262,7 +262,7 @@ class trust(LDAPObject): result = ldap.get_entries(DN(self.container_dn, self.env.basedn), ldap.SCOPE_SUBTREE, filter, ['']) except errors.NotFound: - trust_type = u'ad' + return None else: if len(result) > 1: raise errors.OnlyOneValueAllowed(attr='trust domain') @@ -1244,7 +1244,7 @@ def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): trust_name, creds=creds) result = [] if not domains: - return None + return result for dom in domains: dom['trust_type'] = u'ad' -- 1.8.4.2 From pviktori at redhat.com Thu Dec 5 11:52:39 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Dec 2013 12:52:39 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A05237.2030904@redhat.com> References: <52A05237.2030904@redhat.com> Message-ID: <52A06907.1030308@redhat.com> On 12/05/2013 11:15 AM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Patch 207 should fix build failures some of you were having after > hardenening was enabled in the spec file. Thanks! In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero would also indicate a problem, if it somehow ended up being returned. It seems though the hardening flags get included twice. I assume that's not a problem? I get lines like: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/nspr4 -I/usr/include/nss3 -I/usr/include/nspr4 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Werror -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -DWITH_OPENLDAP -I/usr/include/nspr4 -I/usr/include/nss3 -I/usr/include/nspr4 -DUSE_OPENLDAP -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Werror -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -MT parse.o -MD -MP -MF .deps/parse.Tpo -c -o parse.o parse.c gcc -DHAVE_CONFIG_H -I. -I. -I. -I../util -DPREFIX=\""/usr"\" -DBINDIR=\""/usr/bin"\" -DLIBDIR=\""/usr/lib64"\" -DLIBEXECDIR=\""/usr/libexec"\" -DDATADIR=\""/usr/share"\" -DLOCALEDIR=\""/usr/share/locale"\" -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Werror -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -MT ipa-getkeytab.o -MD -MP -MF .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c -- Petr? From abokovoy at redhat.com Thu Dec 5 12:31:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Dec 2013 14:31:05 +0200 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A06907.1030308@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> Message-ID: <20131205123105.GM21264@redhat.com> On Thu, 05 Dec 2013, Petr Viktorin wrote: >On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>Hi, >> >>the attached patches fix . >> >>Patch 207 should fix build failures some of you were having after >>hardenening was enabled in the spec file. > >Thanks! > >In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >would also indicate a problem, if it somehow ended up being returned. no, write() returns -1 if an error has happened and amount of the data written otherwise. We specifically need to check that there was an error, not that we wrote more or less than were supposed to write. We are looking for EPIPE and EINTR mostly, since other errors make little difference for our case. In case of EINTR we need to repeat or the worker thread didn't receive our shutdown request. In case of EPIPE we will also get SIGPIPE and in general this means the other thread died.. However, even if writing to the pipe failed, we still need to wait until thread dies with pthread_join(). I think returning -1 here is premature. -- / Alexander Bokovoy From pviktori at redhat.com Thu Dec 5 12:37:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Dec 2013 13:37:34 +0100 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION Message-ID: <52A0738E.60302@redhat.com> Consider this scenario: - Nathaniel submits RADIUS patches that update the API version (from 2.69 to 2.70) - I have ACI patches that also bump the version (from 2.69 to 2.70) - Nathaniel's patches gets accepted - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change is already done, so it leaves VERSION unchanged. I can solve this locally by telling Git to not merge VERSION automatically, but I think it would be helpful to add a unique comment to each change so that everyone gets a conflict cases like this. Do you agree? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0330-Add-comment-about-last-change-to-VERSION.patch Type: text/x-patch Size: 902 bytes Desc: not available URL: From pviktori at redhat.com Thu Dec 5 13:09:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Dec 2013 14:09:51 +0100 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <1386080806.14987.87.camel@willson.li.ssimo.org> References: <1386080806.14987.87.camel@willson.li.ssimo.org> Message-ID: <52A07B1F.4000304@redhat.com> On 12/03/2013 03:26 PM, Simo Sorce wrote: > Some tags escaped the relicensing we did a long time ago. > > Simo. Looks good, ACK, pushed to: master: af26e6da4650b3a429af31bc38b546eff27e38c6 ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 I grepped for some other occurences of "GPLv2": contrib/RHEL4/ipa-client.spec:7:License: GPLv2 do we still want to carry the RHEL4 stuff anyway? ipa-client/ipa-client.spec.in:7:License: GPLv2 Is ipa-client.spec used for anything any more? install/ui/src/freeipa/package.json: "licenses": [{ "type": "GPLv3", "url": "http://www.gnu.org/licenses/gpl-3.0.html" },{ "type": "GPLv2", "url": "http://www.gnu.org/licenses/gpl-2.0.html" }], Is this package dual-licensed? -- Petr? From jcholast at redhat.com Thu Dec 5 13:37:02 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 05 Dec 2013 14:37:02 +0100 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile Message-ID: <52A0817E.2080002@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5001 bytes Desc: not available URL: From jcholast at redhat.com Thu Dec 5 13:45:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 05 Dec 2013 14:45:13 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command Message-ID: <52A08369.8020301@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-211-Fix-internal-error-in-the-user-status-command.patch Type: text/x-patch Size: 1962 bytes Desc: not available URL: From pvoborni at redhat.com Thu Dec 5 14:29:02 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 05 Dec 2013 15:29:02 +0100 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <52A07B1F.4000304@redhat.com> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> Message-ID: <52A08DAE.8050906@redhat.com> On 5.12.2013 14:09, Petr Viktorin wrote: > On 12/03/2013 03:26 PM, Simo Sorce wrote: >> Some tags escaped the relicensing we did a long time ago. >> >> Simo. > > Looks good, ACK, pushed to: > master: af26e6da4650b3a429af31bc38b546eff27e38c6 > ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 > > > > I grepped for some other occurences of "GPLv2": > > contrib/RHEL4/ipa-client.spec:7:License: GPLv2 > do we still want to carry the RHEL4 stuff anyway? > > ipa-client/ipa-client.spec.in:7:License: GPLv2 > Is ipa-client.spec used for anything any more? > > > install/ui/src/freeipa/package.json: > "licenses": [{ > "type": "GPLv3", > "url": "http://www.gnu.org/licenses/gpl-3.0.html" > },{ > "type": "GPLv2", > "url": "http://www.gnu.org/licenses/gpl-2.0.html" > }], > Is this package dual-licensed? > It's because of: git grep "Free Software Foundation; version 2" install/ui/src/freeipa/aci.js: * published by the Free Software Foundation; version 2 only install/ui/test/aci_tests.js: * published by the Free Software Foundation; version 2 only install/ui/test/widget_tests.js: * published by the Free Software Foundation; version 2 only It's most likely a mistake and should be changed. -- Petr Vobornik From simo at redhat.com Thu Dec 5 14:34:35 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Dec 2013 09:34:35 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <52A08DAE.8050906@redhat.com> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> Message-ID: <1386254075.3255.39.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: > On 5.12.2013 14:09, Petr Viktorin wrote: > > On 12/03/2013 03:26 PM, Simo Sorce wrote: > >> Some tags escaped the relicensing we did a long time ago. > >> > >> Simo. > > > > Looks good, ACK, pushed to: > > master: af26e6da4650b3a429af31bc38b546eff27e38c6 > > ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 > > > > > > > > I grepped for some other occurences of "GPLv2": > > > > contrib/RHEL4/ipa-client.spec:7:License: GPLv2 > > do we still want to carry the RHEL4 stuff anyway? > > > > ipa-client/ipa-client.spec.in:7:License: GPLv2 > > Is ipa-client.spec used for anything any more? > > > > > > install/ui/src/freeipa/package.json: > > "licenses": [{ > > "type": "GPLv3", > > "url": "http://www.gnu.org/licenses/gpl-3.0.html" > > },{ > > "type": "GPLv2", > > "url": "http://www.gnu.org/licenses/gpl-2.0.html" > > }], > > Is this package dual-licensed? > > > > It's because of: > git grep "Free Software Foundation; version 2" > install/ui/src/freeipa/aci.js: * published by the Free Software > Foundation; version 2 only > install/ui/test/aci_tests.js: * published by the Free Software > Foundation; version 2 only > install/ui/test/widget_tests.js: * published by the Free Software > Foundation; version 2 only > > > It's most likely a mistake and should be changed. Is that code really v2 only ? Or are you saying the "version 2 only" strings are mistakes ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Dec 5 14:38:07 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 05 Dec 2013 15:38:07 +0100 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <1386254075.3255.39.camel@willson.li.ssimo.org> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> Message-ID: <52A08FCF.501@redhat.com> On 5.12.2013 15:34, Simo Sorce wrote: > On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: >> On 5.12.2013 14:09, Petr Viktorin wrote: >>> On 12/03/2013 03:26 PM, Simo Sorce wrote: >>>> Some tags escaped the relicensing we did a long time ago. >>>> >>>> Simo. >>> >>> Looks good, ACK, pushed to: >>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 >>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 >>> >>> >>> >>> I grepped for some other occurences of "GPLv2": >>> >>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 >>> do we still want to carry the RHEL4 stuff anyway? >>> >>> ipa-client/ipa-client.spec.in:7:License: GPLv2 >>> Is ipa-client.spec used for anything any more? >>> >>> >>> install/ui/src/freeipa/package.json: >>> "licenses": [{ >>> "type": "GPLv3", >>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" >>> },{ >>> "type": "GPLv2", >>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" >>> }], >>> Is this package dual-licensed? >>> >> >> It's because of: >> git grep "Free Software Foundation; version 2" >> install/ui/src/freeipa/aci.js: * published by the Free Software >> Foundation; version 2 only >> install/ui/test/aci_tests.js: * published by the Free Software >> Foundation; version 2 only >> install/ui/test/widget_tests.js: * published by the Free Software >> Foundation; version 2 only >> >> >> It's most likely a mistake and should be changed. > > Is that code really v2 only ? > > Or are you saying the "version 2 only" strings are mistakes ? > > Simo. > It's our code. So IMO we should just change it to v3. -- Petr Vobornik From simo at redhat.com Thu Dec 5 15:02:54 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Dec 2013 10:02:54 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <52A08FCF.501@redhat.com> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> Message-ID: <1386255774.3255.43.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: > On 5.12.2013 15:34, Simo Sorce wrote: > > On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: > >> On 5.12.2013 14:09, Petr Viktorin wrote: > >>> On 12/03/2013 03:26 PM, Simo Sorce wrote: > >>>> Some tags escaped the relicensing we did a long time ago. > >>>> > >>>> Simo. > >>> > >>> Looks good, ACK, pushed to: > >>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 > >>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 > >>> > >>> > >>> > >>> I grepped for some other occurences of "GPLv2": > >>> > >>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 > >>> do we still want to carry the RHEL4 stuff anyway? > >>> > >>> ipa-client/ipa-client.spec.in:7:License: GPLv2 > >>> Is ipa-client.spec used for anything any more? > >>> > >>> > >>> install/ui/src/freeipa/package.json: > >>> "licenses": [{ > >>> "type": "GPLv3", > >>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" > >>> },{ > >>> "type": "GPLv2", > >>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" > >>> }], > >>> Is this package dual-licensed? > >>> > >> > >> It's because of: > >> git grep "Free Software Foundation; version 2" > >> install/ui/src/freeipa/aci.js: * published by the Free Software > >> Foundation; version 2 only > >> install/ui/test/aci_tests.js: * published by the Free Software > >> Foundation; version 2 only > >> install/ui/test/widget_tests.js: * published by the Free Software > >> Foundation; version 2 only > >> > >> > >> It's most likely a mistake and should be changed. > > > > Is that code really v2 only ? > > > > Or are you saying the "version 2 only" strings are mistakes ? > > > > Simo. > > > > It's our code. So IMO we should just change it to v3. I do not recall we ever used the v2 only variant, this is highly suspect, we should go through history and make sure it is all our code, then re-license it. If it is derived from v2 only code from an outside party though then we will need to ask for permission to change or strip the code out and rewrite it from scratch. Can someone check through git history and determine where the code comes from and how the "only" label got onto it ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Dec 5 15:31:27 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 05 Dec 2013 16:31:27 +0100 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <1386255774.3255.43.camel@willson.li.ssimo.org> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> <1386255774.3255.43.camel@willson.li.ssimo.org> Message-ID: <52A09C4F.2030903@redhat.com> On 5.12.2013 16:02, Simo Sorce wrote: > On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: >> On 5.12.2013 15:34, Simo Sorce wrote: >>> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: >>>> On 5.12.2013 14:09, Petr Viktorin wrote: >>>>> On 12/03/2013 03:26 PM, Simo Sorce wrote: >>>>>> Some tags escaped the relicensing we did a long time ago. >>>>>> >>>>>> Simo. >>>>> >>>>> Looks good, ACK, pushed to: >>>>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 >>>>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 >>>>> >>>>> >>>>> >>>>> I grepped for some other occurences of "GPLv2": >>>>> >>>>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 >>>>> do we still want to carry the RHEL4 stuff anyway? >>>>> >>>>> ipa-client/ipa-client.spec.in:7:License: GPLv2 >>>>> Is ipa-client.spec used for anything any more? >>>>> >>>>> >>>>> install/ui/src/freeipa/package.json: >>>>> "licenses": [{ >>>>> "type": "GPLv3", >>>>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" >>>>> },{ >>>>> "type": "GPLv2", >>>>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" >>>>> }], >>>>> Is this package dual-licensed? >>>>> >>>> >>>> It's because of: >>>> git grep "Free Software Foundation; version 2" >>>> install/ui/src/freeipa/aci.js: * published by the Free Software >>>> Foundation; version 2 only >>>> install/ui/test/aci_tests.js: * published by the Free Software >>>> Foundation; version 2 only >>>> install/ui/test/widget_tests.js: * published by the Free Software >>>> Foundation; version 2 only >>>> >>>> >>>> It's most likely a mistake and should be changed. >>> >>> Is that code really v2 only ? >>> >>> Or are you saying the "version 2 only" strings are mistakes ? >>> >>> Simo. >>> >> >> It's our code. So IMO we should just change it to v3. > > I do not recall we ever used the v2 only variant, this is highly > suspect, we should go through history and make sure it is all our code, > then re-license it. > If it is derived from v2 only code from an outside party though then we > will need to ask for permission to change or strip the code out and > rewrite it from scratch. > > Can someone check through git history and determine where the code comes > from and how the "only" label got onto it ? > > Simo. > - the notice in install/ui/test/aci_tests.js and install/ui/test/aci_tests.js were introduced by: - 2010-10-25 23:55:57 (GMT) - install/ui/test/widget_tests.js by - 2011-01-31 14:09:26 (GMT) In each case the notice is there since file creation. All the code looks to be original - it's highly IPA specific. One file contains creation of our ACI widgets, remaining two are widget unit tests. -- Petr Vobornik From pviktori at redhat.com Thu Dec 5 15:31:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Dec 2013 16:31:32 +0100 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <1386255774.3255.43.camel@willson.li.ssimo.org> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> <1386255774.3255.43.camel@willson.li.ssimo.org> Message-ID: <52A09C54.9040005@redhat.com> On 12/05/2013 04:02 PM, Simo Sorce wrote: > On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: >> On 5.12.2013 15:34, Simo Sorce wrote: >>> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: >>>> On 5.12.2013 14:09, Petr Viktorin wrote: >>>>> On 12/03/2013 03:26 PM, Simo Sorce wrote: >>>>>> Some tags escaped the relicensing we did a long time ago. >>>>>> >>>>>> Simo. >>>>> >>>>> Looks good, ACK, pushed to: >>>>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 >>>>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 >>>>> >>>>> >>>>> >>>>> I grepped for some other occurences of "GPLv2": >>>>> >>>>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 >>>>> do we still want to carry the RHEL4 stuff anyway? >>>>> >>>>> ipa-client/ipa-client.spec.in:7:License: GPLv2 >>>>> Is ipa-client.spec used for anything any more? >>>>> >>>>> >>>>> install/ui/src/freeipa/package.json: >>>>> "licenses": [{ >>>>> "type": "GPLv3", >>>>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" >>>>> },{ >>>>> "type": "GPLv2", >>>>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" >>>>> }], >>>>> Is this package dual-licensed? >>>>> >>>> >>>> It's because of: >>>> git grep "Free Software Foundation; version 2" >>>> install/ui/src/freeipa/aci.js: * published by the Free Software >>>> Foundation; version 2 only >>>> install/ui/test/aci_tests.js: * published by the Free Software >>>> Foundation; version 2 only >>>> install/ui/test/widget_tests.js: * published by the Free Software >>>> Foundation; version 2 only >>>> >>>> >>>> It's most likely a mistake and should be changed. >>> >>> Is that code really v2 only ? >>> >>> Or are you saying the "version 2 only" strings are mistakes ? >>> >>> Simo. >>> >> >> It's our code. So IMO we should just change it to v3. > > I do not recall we ever used the v2 only variant, this is highly > suspect, we should go through history and make sure it is all our code, > then re-license it. > If it is derived from v2 only code from an outside party though then we > will need to ask for permission to change or strip the code out and > rewrite it from scratch. > > Can someone check through git history and determine where the code comes > from and how the "only" label got onto it ? There were Red Hat? contributors only so far: $ for file in install/ui/{src/freeipa/aci.js,test/aci_tests.js,test/widget_tests.js}; do git log --follow --raw $file; done | grep ^Author: | sort | uniq Author: Adam Young Author: Endi S. Dewata Author: Endi Sukma Dewata Author: Martin Kosek Author: Petr Vobornik Author: Petr Voborn?k The files come from these commits, with the "only" label already in them: c281e786c805f400ca23d4412e29d396632d5441 widget unit tests 07ace112afeaadade0ca372fe23a9432c2c9780f aci ui or without tracking renames: b9ef6ab0c412913234f05f788b3fcd3c3277eb69 Move of core Web UI files to AMD directory b9ad279ad2d8d93dd501115a028783cf8fe7fcbd rename static to ui c281e786c805f400ca23d4412e29d396632d5441 widget unit tests -- Petr? ? I object to using "we" to mean "Red Hat" on this list. From mkosek at redhat.com Thu Dec 5 15:47:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Dec 2013 16:47:00 +0100 Subject: [Freeipa-devel] Wiki by-component documentation Message-ID: <52A09FF4.6090007@redhat.com> Hello, Just wanted to let you know that I wrote 2 new by-component articles: http://www.freeipa.org/page/Directory_Server http://www.freeipa.org/page/PKI ... and extended http://www.freeipa.org/page/Kerberos and others. Now all the components in http://www.freeipa.org/page/Documentation#By_Component should have at least some meaningful information. I would like to see links to these components used in our wiki articles. For example, when writing about PKI, please use [[PKI]] instead of plain PKI or CA to advertise these pages. Then user can get basic information what the component is about, what it does, what is it good for and also get links to other extended information, thus fostering the true Mediawiki spirit. Contributions, extensions, ideas are very welcome, there is still some work to do in this area. Thanks, Martin From simo at redhat.com Thu Dec 5 16:04:12 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Dec 2013 11:04:12 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <52A09C54.9040005@redhat.com> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> <1386255774.3255.43.camel@willson.li.ssimo.org> <52A09C54.9040005@redhat.com> Message-ID: <1386259452.3255.46.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 16:31 +0100, Petr Viktorin wrote: > On 12/05/2013 04:02 PM, Simo Sorce wrote: > > On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: > >> On 5.12.2013 15:34, Simo Sorce wrote: > >>> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: > >>>> On 5.12.2013 14:09, Petr Viktorin wrote: > >>>>> On 12/03/2013 03:26 PM, Simo Sorce wrote: > >>>>>> Some tags escaped the relicensing we did a long time ago. > >>>>>> > >>>>>> Simo. > >>>>> > >>>>> Looks good, ACK, pushed to: > >>>>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 > >>>>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 > >>>>> > >>>>> > >>>>> > >>>>> I grepped for some other occurences of "GPLv2": > >>>>> > >>>>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 > >>>>> do we still want to carry the RHEL4 stuff anyway? > >>>>> > >>>>> ipa-client/ipa-client.spec.in:7:License: GPLv2 > >>>>> Is ipa-client.spec used for anything any more? > >>>>> > >>>>> > >>>>> install/ui/src/freeipa/package.json: > >>>>> "licenses": [{ > >>>>> "type": "GPLv3", > >>>>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" > >>>>> },{ > >>>>> "type": "GPLv2", > >>>>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" > >>>>> }], > >>>>> Is this package dual-licensed? > >>>>> > >>>> > >>>> It's because of: > >>>> git grep "Free Software Foundation; version 2" > >>>> install/ui/src/freeipa/aci.js: * published by the Free Software > >>>> Foundation; version 2 only > >>>> install/ui/test/aci_tests.js: * published by the Free Software > >>>> Foundation; version 2 only > >>>> install/ui/test/widget_tests.js: * published by the Free Software > >>>> Foundation; version 2 only > >>>> > >>>> > >>>> It's most likely a mistake and should be changed. > >>> > >>> Is that code really v2 only ? > >>> > >>> Or are you saying the "version 2 only" strings are mistakes ? > >>> > >>> Simo. > >>> > >> > >> It's our code. So IMO we should just change it to v3. > > > > I do not recall we ever used the v2 only variant, this is highly > > suspect, we should go through history and make sure it is all our code, > > then re-license it. > > If it is derived from v2 only code from an outside party though then we > > will need to ask for permission to change or strip the code out and > > rewrite it from scratch. > > > > Can someone check through git history and determine where the code comes > > from and how the "only" label got onto it ? > > There were Red Hat? contributors only so far: > > $ for file in > install/ui/{src/freeipa/aci.js,test/aci_tests.js,test/widget_tests.js}; > do git log --follow --raw $file; done | grep ^Author: | sort | uniq > Author: Adam Young > Author: Endi S. Dewata > Author: Endi Sukma Dewata > Author: Martin Kosek > Author: Petr Vobornik > Author: Petr Voborn?k > > > The files come from these commits, with the "only" label already in them: > c281e786c805f400ca23d4412e29d396632d5441 widget unit tests > 07ace112afeaadade0ca372fe23a9432c2c9780f aci ui > > or without tracking renames: > b9ef6ab0c412913234f05f788b3fcd3c3277eb69 Move of core Web UI files to > AMD directory > b9ad279ad2d8d93dd501115a028783cf8fe7fcbd rename static to ui > c281e786c805f400ca23d4412e29d396632d5441 widget unit tests Bringing Adam in the loop as he seem to be the original author. Adam, can you shed some light on this license issue ? Was it just a mistake on your part when you copied in the boiler plate ? Or was the code derived (and why no attribution if it was ?) Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Thu Dec 5 17:36:08 2013 From: ayoung at redhat.com (Adam Young) Date: Thu, 05 Dec 2013 12:36:08 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <1386259452.3255.46.camel@willson.li.ssimo.org> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> <1386255774.3255.43.camel@willson.li.ssimo.org> <52A09C54.9040005@redhat.com> <1386259452.3255.46.camel@willson.li.ssimo.org> Message-ID: <52A0B988.3030308@redhat.com> On 12/05/2013 11:04 AM, Simo Sorce wrote: > On Thu, 2013-12-05 at 16:31 +0100, Petr Viktorin wrote: >> On 12/05/2013 04:02 PM, Simo Sorce wrote: >>> On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: >>>> On 5.12.2013 15:34, Simo Sorce wrote: >>>>> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: >>>>>> On 5.12.2013 14:09, Petr Viktorin wrote: >>>>>>> On 12/03/2013 03:26 PM, Simo Sorce wrote: >>>>>>>> Some tags escaped the relicensing we did a long time ago. >>>>>>>> >>>>>>>> Simo. >>>>>>> Looks good, ACK, pushed to: >>>>>>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 >>>>>>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> I grepped for some other occurences of "GPLv2": >>>>>>> >>>>>>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 >>>>>>> do we still want to carry the RHEL4 stuff anyway? >>>>>>> >>>>>>> ipa-client/ipa-client.spec.in:7:License: GPLv2 >>>>>>> Is ipa-client.spec used for anything any more? >>>>>>> >>>>>>> >>>>>>> install/ui/src/freeipa/package.json: >>>>>>> "licenses": [{ >>>>>>> "type": "GPLv3", >>>>>>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" >>>>>>> },{ >>>>>>> "type": "GPLv2", >>>>>>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" >>>>>>> }], >>>>>>> Is this package dual-licensed? >>>>>>> >>>>>> It's because of: >>>>>> git grep "Free Software Foundation; version 2" >>>>>> install/ui/src/freeipa/aci.js: * published by the Free Software >>>>>> Foundation; version 2 only >>>>>> install/ui/test/aci_tests.js: * published by the Free Software >>>>>> Foundation; version 2 only >>>>>> install/ui/test/widget_tests.js: * published by the Free Software >>>>>> Foundation; version 2 only >>>>>> >>>>>> >>>>>> It's most likely a mistake and should be changed. >>>>> Is that code really v2 only ? >>>>> >>>>> Or are you saying the "version 2 only" strings are mistakes ? >>>>> >>>>> Simo. >>>>> >>>> It's our code. So IMO we should just change it to v3. >>> I do not recall we ever used the v2 only variant, this is highly >>> suspect, we should go through history and make sure it is all our code, >>> then re-license it. >>> If it is derived from v2 only code from an outside party though then we >>> will need to ask for permission to change or strip the code out and >>> rewrite it from scratch. >>> >>> Can someone check through git history and determine where the code comes >>> from and how the "only" label got onto it ? >> There were Red Hat? contributors only so far: >> >> $ for file in >> install/ui/{src/freeipa/aci.js,test/aci_tests.js,test/widget_tests.js}; >> do git log --follow --raw $file; done | grep ^Author: | sort | uniq >> Author: Adam Young >> Author: Endi S. Dewata >> Author: Endi Sukma Dewata >> Author: Martin Kosek >> Author: Petr Vobornik >> Author: Petr Voborn?k >> >> >> The files come from these commits, with the "only" label already in them: >> c281e786c805f400ca23d4412e29d396632d5441 widget unit tests >> 07ace112afeaadade0ca372fe23a9432c2c9780f aci ui >> >> or without tracking renames: >> b9ef6ab0c412913234f05f788b3fcd3c3277eb69 Move of core Web UI files to >> AMD directory >> b9ad279ad2d8d93dd501115a028783cf8fe7fcbd rename static to ui >> c281e786c805f400ca23d4412e29d396632d5441 widget unit tests > > Bringing Adam in the loop as he seem to be the original author. > > Adam, > can you shed some light on this license issue ? > > Was it just a mistake on your part when you copied in the boiler plate ? > Or was the code derived (and why no attribution if it was ?) No it was not derived, and I am the original author. I think the code was copied verbatim from another file, and I know no reason that it needs to stay as V2 Only. At that time, the only people touching these files were me and Endi. The only thing that we did not originate ourselves were the unit test framework. The string 'aci' is specific to the business logic of FreeIPA and it was completely the work of Red Hat employees. > > Simo. > From simo at redhat.com Thu Dec 5 18:11:38 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Dec 2013 13:11:38 -0500 Subject: [Freeipa-devel] [PATCH] Fix python setup tools license tags In-Reply-To: <52A0B988.3030308@redhat.com> References: <1386080806.14987.87.camel@willson.li.ssimo.org> <52A07B1F.4000304@redhat.com> <52A08DAE.8050906@redhat.com> <1386254075.3255.39.camel@willson.li.ssimo.org> <52A08FCF.501@redhat.com> <1386255774.3255.43.camel@willson.li.ssimo.org> <52A09C54.9040005@redhat.com> <1386259452.3255.46.camel@willson.li.ssimo.org> <52A0B988.3030308@redhat.com> Message-ID: <1386267098.3255.70.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 12:36 -0500, Adam Young wrote: > On 12/05/2013 11:04 AM, Simo Sorce wrote: > > On Thu, 2013-12-05 at 16:31 +0100, Petr Viktorin wrote: > >> On 12/05/2013 04:02 PM, Simo Sorce wrote: > >>> On Thu, 2013-12-05 at 15:38 +0100, Petr Vobornik wrote: > >>>> On 5.12.2013 15:34, Simo Sorce wrote: > >>>>> On Thu, 2013-12-05 at 15:29 +0100, Petr Vobornik wrote: > >>>>>> On 5.12.2013 14:09, Petr Viktorin wrote: > >>>>>>> On 12/03/2013 03:26 PM, Simo Sorce wrote: > >>>>>>>> Some tags escaped the relicensing we did a long time ago. > >>>>>>>> > >>>>>>>> Simo. > >>>>>>> Looks good, ACK, pushed to: > >>>>>>> master: af26e6da4650b3a429af31bc38b546eff27e38c6 > >>>>>>> ipa-3-3: 9defb913aa65bfe9b423d510f340ae23b9e547f2 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I grepped for some other occurences of "GPLv2": > >>>>>>> > >>>>>>> contrib/RHEL4/ipa-client.spec:7:License: GPLv2 > >>>>>>> do we still want to carry the RHEL4 stuff anyway? > >>>>>>> > >>>>>>> ipa-client/ipa-client.spec.in:7:License: GPLv2 > >>>>>>> Is ipa-client.spec used for anything any more? > >>>>>>> > >>>>>>> > >>>>>>> install/ui/src/freeipa/package.json: > >>>>>>> "licenses": [{ > >>>>>>> "type": "GPLv3", > >>>>>>> "url": "http://www.gnu.org/licenses/gpl-3.0.html" > >>>>>>> },{ > >>>>>>> "type": "GPLv2", > >>>>>>> "url": "http://www.gnu.org/licenses/gpl-2.0.html" > >>>>>>> }], > >>>>>>> Is this package dual-licensed? > >>>>>>> > >>>>>> It's because of: > >>>>>> git grep "Free Software Foundation; version 2" > >>>>>> install/ui/src/freeipa/aci.js: * published by the Free Software > >>>>>> Foundation; version 2 only > >>>>>> install/ui/test/aci_tests.js: * published by the Free Software > >>>>>> Foundation; version 2 only > >>>>>> install/ui/test/widget_tests.js: * published by the Free Software > >>>>>> Foundation; version 2 only > >>>>>> > >>>>>> > >>>>>> It's most likely a mistake and should be changed. > >>>>> Is that code really v2 only ? > >>>>> > >>>>> Or are you saying the "version 2 only" strings are mistakes ? > >>>>> > >>>>> Simo. > >>>>> > >>>> It's our code. So IMO we should just change it to v3. > >>> I do not recall we ever used the v2 only variant, this is highly > >>> suspect, we should go through history and make sure it is all our code, > >>> then re-license it. > >>> If it is derived from v2 only code from an outside party though then we > >>> will need to ask for permission to change or strip the code out and > >>> rewrite it from scratch. > >>> > >>> Can someone check through git history and determine where the code comes > >>> from and how the "only" label got onto it ? > >> There were Red Hat? contributors only so far: > >> > >> $ for file in > >> install/ui/{src/freeipa/aci.js,test/aci_tests.js,test/widget_tests.js}; > >> do git log --follow --raw $file; done | grep ^Author: | sort | uniq > >> Author: Adam Young > >> Author: Endi S. Dewata > >> Author: Endi Sukma Dewata > >> Author: Martin Kosek > >> Author: Petr Vobornik > >> Author: Petr Voborn?k > >> > >> > >> The files come from these commits, with the "only" label already in them: > >> c281e786c805f400ca23d4412e29d396632d5441 widget unit tests > >> 07ace112afeaadade0ca372fe23a9432c2c9780f aci ui > >> > >> or without tracking renames: > >> b9ef6ab0c412913234f05f788b3fcd3c3277eb69 Move of core Web UI files to > >> AMD directory > >> b9ad279ad2d8d93dd501115a028783cf8fe7fcbd rename static to ui > >> c281e786c805f400ca23d4412e29d396632d5441 widget unit tests > > > > Bringing Adam in the loop as he seem to be the original author. > > > > Adam, > > can you shed some light on this license issue ? > > > > Was it just a mistake on your part when you copied in the boiler plate ? > > Or was the code derived (and why no attribution if it was ?) > > No it was not derived, and I am the original author. I think the code > was copied verbatim from another file, and I know no reason that it > needs to stay as V2 Only. At that time, the only people touching these > files were me and Endi. The only thing that we did not originate > ourselves were the unit test framework. The string 'aci' is specific to > the business logic of FreeIPA and it was completely the work of Red Hat > employees. Ok then we need to fix this, Petr can you prepare a patch ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 6 10:49:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 11:49:54 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <529C7740.7090601@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> Message-ID: <52A1ABD2.9040400@redhat.com> On 12/02/2013 01:04 PM, Martin Kosek wrote: > On 12/01/2013 11:46 PM, Petr Viktorin wrote: >> This seems to work now. Please tell me what I missed. >> >> Design: http://www.freeipa.org/page/V3/Permissions_V2 >> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >> >> >> 0322 Allow sets for initialization of frozenset-typed Param keywords >> because my OCD compels me to use sets instead of lists when the order does not >> matter. >> >> >> 0323 Allow Declarative test classes to specify the API version >> For the next patch, I want to test how the rewrite handles old clients. To make >> that easy I made the default API version a testclass attribute >> >> >> 0324 Add tests for permission plugin with older clients >> These tests will not pass yet, but comparing this file with the old >> test_permission_plugin.py will can serve as a nice summary of API changes. A >> summary of the summary: >> - Lots of new attributes will be added for output >> - The `type` and `subtree` options now interact in a different way: setting one >> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >> (Some change here was necessary for https://fedorahosted.org/freeipa/ticket/2355) >> - Validation will be stricter (and/or done in different order) >> - Some error messages will change (hopefully for the better) >> - `subtree` must now point to an existing entry >> - Permission names may now contain '.' (this is to allow names of DNS >> permissions that were previously internal) >> >> P.S. a handy command for listing the changes (once this patch is applied): >> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >> ipatests/test_xmlrpc/test_old_permission_plugin.py >> >> >> 0325 Add new permission schema >> Introducing the new OIDs >> >> >> 0326 Rewrite the Permission plugin >> See the design for what this does. >> >> The new permission plugin does not use aci plugin at all. The plan is to retire >> the aci plugin when the time comes to also refactor delegation & selfservice. >> It does use ipalib's ACI class, mainly for parsing (needed for >> upgrading/showing old ACIs). >> >> The permission-find command is a bit faster than the old one, but still >> painfully slow (5s instead of 7s on my box). The good news is that it now >> scales with the number of *old* permissions, so as you upgrade it'll get faster. >> >> Tests are updated, including privilege and DNS tests that worked with permissions. >> >> >> 0327 Verify ACIs are added correctly in tests >> Right after saying I want to get rid of it, I found a new use for the aci >> plugin: an tested code path for getting at ACIs (Declaratrive tests can only >> use the API, they don't play well with LDAP connections). >> Now we can be sure the ACIs are actually changed when we play with permissions. >> > > Great job! > > I read through the code and did few tests, this is what I've found so far: > > 1) When I tried to move ACI to non-existent DN, I got a general error + the > underlying ACI was gone: > > # ipa permission-mod "Write Group Description" --subtree=foo=bar > ipa: ERROR: no such entry > > > When I then tried to delete it, I got Internal Error: > # ipa permission-del "Write Group Description" > ipa: ERROR: an internal error has occurred > > ... > /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in pre_callback > [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] > self.obj.remove_aci(entry) > [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in > remove_aci > [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] > self._replace_aci(permission_entry) > [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in > _replace_aci > [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn > # pylint: disable=E1103 > [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' > object has no attribute 'dn' > > I think we should add a check for that + at least try to rollback if we fail to > move the ACI. Fixed. I did in in 2 additional patches for clarity: - 0331 adds rollback - 0332 adds the check (you can test the rollback without this applied) > 2) In filter check: > > + # Rough filter validation by a search > + if self.env.in_server and 'ipapermtargetfilter' in options: > + ldap = self.Backend.ldap2 > + try: > + ldap.find_entries( > + filter=options['ipapermtargetfilter'], > + base_dn=self.env.basedn, > + size_limit=0) > > This is great for starters, but I would make it less costly and only search > with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches > across whole database. Agreed, fixed. > 3) I see that I can add ALL bind type permission as a member to a privilege: > > # ipa permission-show "Write Group Description 2" > Permission name: Write Group Description 2 > Permissions: write > Attributes: description > Bind rule type: all > Subtree: cn=groups,cn=accounts,dc=example,dc=com > ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com > Type: group > > # ipa privilege-add-permission foo --permissions "Write Group Description 2" > Privilege name: foo > Description: foo > Permissions: write group description 2 > ----------------------------- > Number of permissions added 1 > ----------------------------- > > Is this a bug or do you already plan to fix it later? Yes, I plan to fix that soon (#4032). I've modified the patch to allow "permission" only. I'll re-introduce the others when I add the necessary checks. > 4) Typo in refactored permission plugin: > > + errors.NotFound('ACI of to permission %s was not found' % > + keys[0]) Fixed, thanks for the catch! -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0322.2-Allow-sets-for-initialization-of-frozenset-typed-Par.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0323.2-Allow-Declarative-test-classes-to-specify-the-API-ve.patch Type: text/x-patch Size: 1268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0324.2-Add-tests-for-permission-plugin-with-older-clients.patch Type: text/x-patch Size: 44634 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0325.2-Add-new-permission-schema.patch Type: text/x-patch Size: 4364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0326.2-Rewrite-the-Permission-plugin.patch Type: text/x-patch Size: 135946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0327.2-Verify-ACIs-are-added-correctly-in-tests.patch Type: text/x-patch Size: 20000 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0331.2-Roll-back-ACI-changes-on-failed-permission-updates.patch Type: text/x-patch Size: 10122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0332.2-permission-plugin-Ensure-ipapermlocation-subtree-alw.patch Type: text/x-patch Size: 3912 bytes Desc: not available URL: From jcholast at redhat.com Fri Dec 6 10:52:43 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Dec 2013 11:52:43 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <20131205123105.GM21264@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> Message-ID: <52A1AC7B.9030102@redhat.com> On 5.12.2013 13:31, Alexander Bokovoy wrote: > On Thu, 05 Dec 2013, Petr Viktorin wrote: >> On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Patch 207 should fix build failures some of you were having after >>> hardenening was enabled in the spec file. >> >> Thanks! >> >> In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >> would also indicate a problem, if it somehow ended up being returned. > no, write() returns -1 if an error has happened and amount of the data > written otherwise. We specifically need to check that there was an > error, not that we wrote more or less than were supposed to write. > > We are looking for EPIPE and EINTR mostly, since other errors make little > difference for our case. In case of EINTR we need to repeat or the > worker thread didn't receive our shutdown request. In case of EPIPE we > will also get SIGPIPE and in general this means the other thread died.. > > However, even if writing to the pipe failed, we still need to wait until > thread dies with pthread_join(). I think returning -1 here is premature. Fixed, updated patches attached. Also removed CFLAGS duplication, see patch 212. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-206.1-Prefer-user-CFLAGS-CPPFLAGS-over-those-provided-by-r.patch Type: text/x-patch Size: 854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-207.1-Include-LDFLAGS-provided-by-rpmbuild-in-global-LDFLA.patch Type: text/x-patch Size: 1367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-208.1-Add-stricter-default-CFLAGS-to-Makefile.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-209.1-Fix-compilation-error-in-ipa-cldap.patch Type: text/x-patch Size: 1008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-212.1-Remove-CFLAGS-duplication.patch Type: text/x-patch Size: 8924 bytes Desc: not available URL: From pviktori at redhat.com Fri Dec 6 11:39:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 12:39:29 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A1AC7B.9030102@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> Message-ID: <52A1B771.4010500@redhat.com> On 12/06/2013 11:52 AM, Jan Cholasta wrote: > On 5.12.2013 13:31, Alexander Bokovoy wrote: >> On Thu, 05 Dec 2013, Petr Viktorin wrote: >>> On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> . >>>> >>>> Patch 207 should fix build failures some of you were having after >>>> hardenening was enabled in the spec file. >>> >>> Thanks! >>> >>> In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >>> would also indicate a problem, if it somehow ended up being returned. >> no, write() returns -1 if an error has happened and amount of the data >> written otherwise. We specifically need to check that there was an >> error, not that we wrote more or less than were supposed to write. >> >> We are looking for EPIPE and EINTR mostly, since other errors make little >> difference for our case. In case of EINTR we need to repeat or the >> worker thread didn't receive our shutdown request. In case of EPIPE we >> will also get SIGPIPE and in general this means the other thread died.. >> >> However, even if writing to the pipe failed, we still need to wait until >> thread dies with pthread_join(). I think returning -1 here is premature. > > Fixed, updated patches attached. > > Also removed CFLAGS duplication, see patch 212. Thanks you! The build works fine, ACK for 206-208, 212. Alexander, is the C part OK? It seems a do-while loop would make sense here. -- Petr? From abokovoy at redhat.com Fri Dec 6 11:57:40 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Dec 2013 13:57:40 +0200 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A1B771.4010500@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> <52A1B771.4010500@redhat.com> Message-ID: <20131206115740.GA9957@redhat.com> On Fri, 06 Dec 2013, Petr Viktorin wrote: >On 12/06/2013 11:52 AM, Jan Cholasta wrote: >>On 5.12.2013 13:31, Alexander Bokovoy wrote: >>>On Thu, 05 Dec 2013, Petr Viktorin wrote: >>>>On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>>>>Hi, >>>>> >>>>>the attached patches fix >>>>>. >>>>> >>>>>Patch 207 should fix build failures some of you were having after >>>>>hardenening was enabled in the spec file. >>>> >>>>Thanks! >>>> >>>>In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >>>>would also indicate a problem, if it somehow ended up being returned. >>>no, write() returns -1 if an error has happened and amount of the data >>>written otherwise. We specifically need to check that there was an >>>error, not that we wrote more or less than were supposed to write. >>> >>>We are looking for EPIPE and EINTR mostly, since other errors make little >>>difference for our case. In case of EINTR we need to repeat or the >>>worker thread didn't receive our shutdown request. In case of EPIPE we >>>will also get SIGPIPE and in general this means the other thread died.. >>> >>>However, even if writing to the pipe failed, we still need to wait until >>>thread dies with pthread_join(). I think returning -1 here is premature. >> >>Fixed, updated patches attached. >> >>Also removed CFLAGS duplication, see patch 212. > >Thanks you! The build works fine, ACK for 206-208, 212. > >Alexander, is the C part OK? It seems a do-while loop would make sense here. I think do-while would be cleaner, purely from intent expression point of view. -- / Alexander Bokovoy From mkosek at redhat.com Fri Dec 6 12:03:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Dec 2013 13:03:17 +0100 Subject: [Freeipa-devel] [PATCHES] 0328-0329 test_integration: Support external names for hosts In-Reply-To: <529DA9F1.1050902@redhat.com> References: <529DA9F1.1050902@redhat.com> Message-ID: <52A1BD05.9010503@redhat.com> On 12/03/2013 10:52 AM, Petr Viktorin wrote: > Hello, > Patch 0328 fixes the problem that I filed [4038] for: CA-less tests fail when > run in some setups on Beaker. What the ticket says was premature diagnosis; > I'll close the ticket as invalid. > See commit message for the real problem. > > Patch 0329 adds a bit more info to logs. > > > [4038] https://fedorahosted.org/freeipa/ticket/4038 tests: Forwarder is not set > on replicas > The patches were tested by a quality engineer, the code looks ok to me, so ACK. Pushed to master, ipa-3-3. Martin From jcholast at redhat.com Fri Dec 6 12:31:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Dec 2013 13:31:13 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <20131206115740.GA9957@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> <52A1B771.4010500@redhat.com> <20131206115740.GA9957@redhat.com> Message-ID: <52A1C391.5030308@redhat.com> On 6.12.2013 12:57, Alexander Bokovoy wrote: > On Fri, 06 Dec 2013, Petr Viktorin wrote: >> On 12/06/2013 11:52 AM, Jan Cholasta wrote: >>> On 5.12.2013 13:31, Alexander Bokovoy wrote: >>>> On Thu, 05 Dec 2013, Petr Viktorin wrote: >>>>> On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix >>>>>> . >>>>>> >>>>>> Patch 207 should fix build failures some of you were having after >>>>>> hardenening was enabled in the spec file. >>>>> >>>>> Thanks! >>>>> >>>>> In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >>>>> would also indicate a problem, if it somehow ended up being returned. >>>> no, write() returns -1 if an error has happened and amount of the data >>>> written otherwise. We specifically need to check that there was an >>>> error, not that we wrote more or less than were supposed to write. >>>> >>>> We are looking for EPIPE and EINTR mostly, since other errors make >>>> little >>>> difference for our case. In case of EINTR we need to repeat or the >>>> worker thread didn't receive our shutdown request. In case of EPIPE we >>>> will also get SIGPIPE and in general this means the other thread died.. >>>> >>>> However, even if writing to the pipe failed, we still need to wait >>>> until >>>> thread dies with pthread_join(). I think returning -1 here is >>>> premature. >>> >>> Fixed, updated patches attached. >>> >>> Also removed CFLAGS duplication, see patch 212. >> >> Thanks you! The build works fine, ACK for 206-208, 212. >> >> Alexander, is the C part OK? It seems a do-while loop would make sense >> here. > I think do-while would be cleaner, purely from intent expression point > of view. > I actually like it the way it is, because it follows the ret = func() if (ret == -1) { } pattern, which is used abundantly in our code. -- Jan Cholasta From mkosek at redhat.com Fri Dec 6 12:42:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Dec 2013 13:42:05 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <20131202162044.GC21264@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> <529CA1A2.9020509@redhat.com> <529CA481.7050000@redhat.com> <20131202162044.GC21264@redhat.com> Message-ID: <52A1C61D.20808@redhat.com> On 12/02/2013 05:20 PM, Alexander Bokovoy wrote: > On Mon, 02 Dec 2013, Martin Kosek wrote: >> On 12/02/2013 04:05 PM, Petr Viktorin wrote: >>> On 12/02/2013 03:42 PM, Simo Sorce wrote: >>>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >>>>> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>>>>> supported. >>>>>>> >>>>>>>>> >>>>>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>>>>> >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been >>>>>>>>> revoked >>>>>>>> >>>>>>>> It should be enabled out of the box. But there were some initial issues >>>>>>>> with >>>>>>>> persistent keyring in the first versions of kernel with a support, >>>>>>>> hopefully >>>>>>>> this was just a fluke which disappeared. >>>>>>>> >>>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>>>>> >>>>>>>> # keyctl get_persistent @s 0 >>>>>>>> 637466038 >>>>>>> >>>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>>>>> $ keyctl get_persistent @s 0 >>>>>>> keyctl_get_persistent: Key has been revoked >>>>>> >>>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>>>>> non-root user... >>>>> >>>>> It is just a typo, but it looks like you got me on the right track. >>>>> keyctl apparently needs a real root login: >>>>> >>>>> $ sudo keyctl get_persistent @s 0 >>>>> keyctl_get_persistent: Key has been revoked >>>>> >>>>> $ sudo su >>>>> # keyctl get_persistent @s 0 >>>>> keyctl_get_persistent: Key has been revoked >>>>> # exit >>>>> >>>>> $ sudo su - >>>>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >>>>> # keyctl get_persistent @s 0 >>>>> 968622527 >>>>> # logout >>>>> >>>> >>>> Please use "sudo -i" to get an interactive 'login' shell. >>>> >>>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains >>>>> that the key is unsupported. From a root login all is OK. >>>>> >>>>> Is that expected? >>>> >>>> You should run ipa-server-install using a login shell I think. >>>> Should we open a bug to detect this and fail ? >>> >>> It's always worked with just sudo for me. So yes, if it's required I think we >>> should enforce it. >>> >> >> Simo or Alexander, is there some way to find that out in a clean way? I mean if >> we are in an interactive login shell. Ideally, please also file a bug with this >> information :) > Interactive or login? These two are different a bit. > > There is no general way because not all shells implement common approach > to detect this. For example, > echo $- | grep -q i > > would work in a Bourne-style shell for interactive shell > > shopt -q login_shell > > would give you a login shell detector in bash but > > test $options[LOGIN] = on > > would work for login shell in zsh, similarly INTERACTIVE index would > give you state of interactive shell. > > I meant login shell - so that we do not have problems with checking the get_persistent keyctl command. I still do not fully understand the keyctl behavior, it is working on my kernel-3.11.9-300.fc20.x86_64 even with plain "sudo": $ sudo keyctl get_persistent @s 0 Anyway, any opinions on this particular patch? I'd prefer to get it in soon and file enhancement ticket for the login terminal detection, if needed. Martin From jcholast at redhat.com Fri Dec 6 12:43:55 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Dec 2013 13:43:55 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A1C391.5030308@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> <52A1B771.4010500@redhat.com> <20131206115740.GA9957@redhat.com> <52A1C391.5030308@redhat.com> Message-ID: <52A1C68B.8030907@redhat.com> On 6.12.2013 13:31, Jan Cholasta wrote: > On 6.12.2013 12:57, Alexander Bokovoy wrote: >> On Fri, 06 Dec 2013, Petr Viktorin wrote: >>> On 12/06/2013 11:52 AM, Jan Cholasta wrote: >>>> On 5.12.2013 13:31, Alexander Bokovoy wrote: >>>>> On Thu, 05 Dec 2013, Petr Viktorin wrote: >>>>>> On 12/05/2013 11:15 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patches fix >>>>>>> . >>>>>>> >>>>>>> Patch 207 should fix build failures some of you were having after >>>>>>> hardenening was enabled in the spec file. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> In 209, would (ret != 1) make more sense than (ret == -1)? AFAIU zero >>>>>> would also indicate a problem, if it somehow ended up being returned. >>>>> no, write() returns -1 if an error has happened and amount of the data >>>>> written otherwise. We specifically need to check that there was an >>>>> error, not that we wrote more or less than were supposed to write. >>>>> >>>>> We are looking for EPIPE and EINTR mostly, since other errors make >>>>> little >>>>> difference for our case. In case of EINTR we need to repeat or the >>>>> worker thread didn't receive our shutdown request. In case of EPIPE we >>>>> will also get SIGPIPE and in general this means the other thread >>>>> died.. >>>>> >>>>> However, even if writing to the pipe failed, we still need to wait >>>>> until >>>>> thread dies with pthread_join(). I think returning -1 here is >>>>> premature. >>>> >>>> Fixed, updated patches attached. >>>> >>>> Also removed CFLAGS duplication, see patch 212. >>> >>> Thanks you! The build works fine, ACK for 206-208, 212. >>> >>> Alexander, is the C part OK? It seems a do-while loop would make sense >>> here. >> I think do-while would be cleaner, purely from intent expression point >> of view. >> > > I actually like it the way it is, because it follows the > > ret = func() > if (ret == -1) { > } > > pattern, which is used abundantly in our code. > ... but I don't have a strong opinion about this, so whatever floats your boat. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-206.2-Prefer-user-CFLAGS-CPPFLAGS-over-those-provided-by-r.patch Type: text/x-patch Size: 854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-207.2-Include-LDFLAGS-provided-by-rpmbuild-in-global-LDFLA.patch Type: text/x-patch Size: 1367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-208.2-Add-stricter-default-CFLAGS-to-Makefile.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-209.2-Fix-compilation-error-in-ipa-cldap.patch Type: text/x-patch Size: 960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-212.2-Remove-CFLAGS-duplication.patch Type: text/x-patch Size: 8924 bytes Desc: not available URL: From pviktori at redhat.com Fri Dec 6 13:14:52 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 14:14:52 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <529C8FB8.9020503@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> Message-ID: <52A1CDCC.5020209@redhat.com> On 12/02/2013 02:48 PM, Petr Viktorin wrote: > On 12/02/2013 02:29 PM, Simo Sorce wrote: >> On Fri, 2013-11-29 at 16:51 +0100, Petr Viktorin wrote: >> >>> I've updated the design with >>> - updated schema (this time the OIDs are even reserved properly!) >>> - longer attribute descriptions with examples >>> - updated update algorithm based on discussion with Simo >> >> Hi Petr, >> thank you for the update. >> >>> Additionally, I've updated draft designs this one references [0, 1]. The >>> CLI/API parts of those aren't finished but the LDAP should be ready for >>> criticism. >> >> It would be very nice if you can add the resulting LDAP objects in the >> example, that will allow me to reason on the correctness of the >> translation. > > OK, I'll work on that. I've added the resulting LDAP objects to the tests here: http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests >>> For examples, I felt that anything I show as an example should also go >>> in the test suite, so I added the tests. (If you're into wiki design I'd >>> appreciate ideas about how to make that section better.) >>> If you need any more examples, or see some dangerous corner cases, tell >>> me and I'll add them. >>> >>> There is still a race condition when the subtree changes, e.g. when >>> you'd move an ACI from $SUFFIX to cn=users,cn=accounts,$SUFFIX, the >>> rights are revoked between the times the ACI is removed and re-added. >>> At this point I'd rather document it and file a bug (and possibly start >>> working on it right after this) than redo the internals in yet another >>> way in the same update. >> >> I think that this will be fine, *after* we change the default mode to >> deny everything, and rely on permissions to allow. This way the lack of >> an ACI will deny (not permit!) access to arbitrary attributes. > > Permissions can only allow access. All our deny ACIs are built in, not > controlled by permissions. > > >>> [0] http://www.freeipa.org/page/V3/Anonymous_and_All_permissions >>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > -- Petr? From pvoborni at redhat.com Fri Dec 6 13:19:33 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 06 Dec 2013 14:19:33 +0100 Subject: [Freeipa-devel] [PATCH] 531 Fix license in some Web UI files Message-ID: <52A1CEE5.2020200@redhat.com> Modified web ui files had incorrect GPLv2 headers instead of GPLv3 ones. All of the affected code is of FreeIPA origin. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-Fix-license-in-Web-UI-files.patch Type: text/x-patch Size: 5559 bytes Desc: not available URL: From mkosek at redhat.com Fri Dec 6 13:21:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Dec 2013 14:21:05 +0100 Subject: [Freeipa-devel] Wiki by-component documentation In-Reply-To: <52A18D61.3010605@redhat.com> References: <52A09FF4.6090007@redhat.com> <52A18D61.3010605@redhat.com> Message-ID: <52A1CF41.1070005@redhat.com> On 12/06/2013 09:40 AM, Petr Spacek wrote: > On 5.12.2013 16:47, Martin Kosek wrote: >> Hello, >> >> Just wanted to let you know that I wrote 2 new by-component articles: >> >> http://www.freeipa.org/page/Directory_Server >> http://www.freeipa.org/page/PKI >> ... and extended >> http://www.freeipa.org/page/Kerberos and others. >> >> Now all the components in >> http://www.freeipa.org/page/Documentation#By_Component >> should have at least some meaningful information. >> >> I would like to see links to these components used in our wiki articles. For >> example, when writing about PKI, please use [[PKI]] instead of plain PKI or CA >> to advertise these pages. Then user can get basic information what the Adding freeipa-devel back to CC list. > > Could we use > http://www.mediawiki.org/wiki/Extension:LinkTitles > for this? > > Inter-wiki links are very scarce on freeipa.org and this could help, I hope. Looks like we would replace human consciousness with automatism :) I do not have much experience with this particular extension, I am bit afraid of this automatism. But if someone knows it, tests it and configures it for our wiki, I am not against it. > Another interesting extension is > http://www.mediawiki.org/wiki/Extension:Semantic_Glossary > > This could help newbies to understand our 'alphabet soup'. The idea is to > automatically augment terms like 'LDIF' with link to some external source with > explanation. > > Sure, we have to create dictionary with links at first, but then the extension > will auto-link terms from all pages to external description. > > Petr^2 Spacek > Yup, sounds interesting too. But as you said, we would need to create the content so that it makes sense. If somebody volunteers to configure it and create a reasonable glossary list, it could be useful. Martin From abokovoy at redhat.com Fri Dec 6 13:26:32 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Dec 2013 15:26:32 +0200 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A1C68B.8030907@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> <52A1B771.4010500@redhat.com> <20131206115740.GA9957@redhat.com> <52A1C391.5030308@redhat.com> <52A1C68B.8030907@redhat.com> Message-ID: <20131206132632.GA13501@redhat.com> On Fri, 06 Dec 2013, Jan Cholasta wrote: >>>>>>However, even if writing to the pipe failed, we still need to wait >>>>>>until >>>>>>thread dies with pthread_join(). I think returning -1 here is >>>>>>premature. >>>>> >>>>>Fixed, updated patches attached. >>>>> >>>>>Also removed CFLAGS duplication, see patch 212. >>>> >>>>Thanks you! The build works fine, ACK for 206-208, 212. >>>> >>>>Alexander, is the C part OK? It seems a do-while loop would make sense >>>>here. >>>I think do-while would be cleaner, purely from intent expression point >>>of view. >>> >> >>I actually like it the way it is, because it follows the >> >> ret = func() >> if (ret == -1) { >> } >> >>pattern, which is used abundantly in our code. >> > >... but I don't have a strong opinion about this, so whatever floats >your boat. Thanks. It is just that in this case - write(ctx->stopfd[1], "", 1); + do { + ret = write(ctx->stopfd[1], "", 1); + } while (ret == -1 && errno == EINTR); makes more clear that we loop here only for EINTR. ACK from my side -- / Alexander Bokovoy From pviktori at redhat.com Fri Dec 6 13:47:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 14:47:03 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <20131206132632.GA13501@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> <52A1B771.4010500@redhat.com> <20131206115740.GA9957@redhat.com> <52A1C391.5030308@redhat.com> <52A1C68B.8030907@redhat.com> <20131206132632.GA13501@redhat.com> Message-ID: <52A1D557.1070204@redhat.com> On 12/06/2013 02:26 PM, Alexander Bokovoy wrote: > On Fri, 06 Dec 2013, Jan Cholasta wrote: >>>>>>> However, even if writing to the pipe failed, we still need to wait >>>>>>> until >>>>>>> thread dies with pthread_join(). I think returning -1 here is >>>>>>> premature. >>>>>> >>>>>> Fixed, updated patches attached. >>>>>> >>>>>> Also removed CFLAGS duplication, see patch 212. >>>>> >>>>> Thanks you! The build works fine, ACK for 206-208, 212. >>>>> >>>>> Alexander, is the C part OK? It seems a do-while loop would make sense >>>>> here. >>>> I think do-while would be cleaner, purely from intent expression point >>>> of view. >>>> >>> >>> I actually like it the way it is, because it follows the >>> >>> ret = func() >>> if (ret == -1) { >>> } >>> >>> pattern, which is used abundantly in our code. >>> >> >> ... but I don't have a strong opinion about this, so whatever floats >> your boat. > Thanks. It is just that in this case - write(ctx->stopfd[1], "", 1); > + do { > + ret = write(ctx->stopfd[1], "", 1); > + } while (ret == -1 && errno == EINTR); > makes more clear that we loop here only for EINTR. > > ACK from my side > Thank you both, pushed to master: 5e2f7b68f0cb8e7fd6ea4f3236e84f1a8d075a13 -- Petr? From mbasti at redhat.com Fri Dec 6 13:48:31 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 06 Dec 2013 14:48:31 +0100 Subject: [Freeipa-devel] [PATCHES] 0022-0023 [RFE] DNS - IDN support Message-ID: <1386337711.2274.25.camel@unused-4-145.brq.redhat.com> Hello, patches here contain a *draft* of IDN support for IPA DNS. Overview: 1) IND domains stored in LDAP are punycoded(A-labels) 2) now domain can contains almost everything 3) domains have to be normalized (AD requires normalized domains too). Example: gro? => gross 4) --raw option shows domains punycoded 5) without --raw option domains are showed in Unicode(U-labels, human readable form) 6) It works only in DNS module, rest of IPA is still without IDN 7) IDN domains are not added into realmdomains TODO: 1) bug in dnspython can cause improper conversion with escaped characters: https://github.com/rthalley/dnspython/issues/46 2) discuss if validators should be more strict (only letters allowed, ...) 3) fix parts of code where domains are showed in punycode - error messages, exceptions 4) cleanup unused code TESTS: 1) 3 failures: caused by TODO 3) 2) expected value: 'value' should be in Unicode(U-labels), instead of punycode (part of TODO 3) ) -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0022-Added-support-for-IDN-domains.patch Type: text/x-patch Size: 39677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0023-IDN-domains-updated-test.patch Type: text/x-patch Size: 32249 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 6 13:49:29 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Dec 2013 14:49:29 +0100 Subject: [Freeipa-devel] [PATCHES] 206-209 Add default CFLAGS & fix hardened build In-Reply-To: <52A1AC7B.9030102@redhat.com> References: <52A05237.2030904@redhat.com> <52A06907.1030308@redhat.com> <20131205123105.GM21264@redhat.com> <52A1AC7B.9030102@redhat.com> Message-ID: <52A1D5E9.5030603@redhat.com> On 6.12.2013 11:52, Jan Cholasta wrote: > freeipa-jcholast-208.1-Add-stricter-default-CFLAGS-to-Makefile.patch > > >>From 85ad15d522274a711c87f92ed91889b781d7455e Mon Sep 17 00:00:00 2001 > From: Jan Cholasta > Date: Wed, 4 Dec 2013 18:42:36 +0100 > Subject: [PATCH 3/5] Add stricter default CFLAGS to Makefile. > > https://fedorahosted.org/freeipa/ticket/3896 > --- > Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Makefile b/Makefile > index 0664ddd..a722634 100644 > --- a/Makefile > +++ b/Makefile > @@ -52,6 +52,9 @@ endif > > PYTHON ?= $(shell rpm -E %__python || echo /usr/bin/python) > > +CFLAGS := -g -O2 -Werror -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers $(CFLAGS) > +export CFLAGS I don't like -Wno-sign-compare -Wno-missing-field-initializers parameters, both could find some nasty surprises in the code. Also, I would add those: -Wformat-nonliteral If -Wformat is specified, also warn if the format string is not a string literal and so cannot be checked, unless the format function takes its format arguments as a |va_list|. -Winit-self Warn about uninitialized variables that are initialized with themselves. -Wshadow Warn whenever a local variable or type declaration shadows another variable, parameter, type, or class member (in C++), or whenever a built-in function is shadowed. -Wpointer-arith Warn about anything that depends on the ?size of? a function type or of |void|. -Wbad-function-cast Warn whenever a function call is cast to a non-matching type. -Wjump-misses-init Warn if a |goto| statement or a |switch| statement jumps forward across the initialization of a variable, or jumps backward to a label after the variable has been initialized. This only warns about variables that are initialized when they are declared. I have seen bugs like this in bind-dyndb-ldap recently. Little bit more controversial options are: -Wswitch-enum Warn whenever a |switch| statement has an index of enumerated type and lacks a |case| for one or more of the named codes of that enumeration. |case| labels outside the enumeration range also provoke warnings when this option is used. The only difference between -Wswitch and this option is that this option gives a warning about an omitted enumeration code even if there is a |default| label. IMHO default in case should (usually) catch only 'garbage' (corrupted memory etc.) and all expected values should be specified explicitly by 'case' statements. Of course, this doesn't work in all cases ... A less invasive alternative is: -Wswitch-default Warn whenever a |switch| statement does not have a |default| case. -Wconversion Warn for implicit conversions that may alter a value. [...] This can produce a lot of warnings because of unsigned int <-> size_t conversions. Unfortunately, I didn't find a way how to disable this warning only for size_t conversions. -Wundef Warn if an undefined identifier is evaluated in an ?#if? directive. We have #ifdef for that :-) -Wcast-qual Warn whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warn if a |const char *| is cast to an ordinary |char *|. I don't insist on this. Sometimes, we are lazy and just cast the type and hope that the called function really does not modify the value ... -Wwrite-strings When compiling C, give string constants the type |const char[|length|]| so that copying the address of one into a non-|const| |char *| pointer produces a warning. This would be interesting experiment or some long-term ticket. -- Petr^2 Spacek From simo at redhat.com Fri Dec 6 14:00:06 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 09:00:06 -0500 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <52A1C61D.20808@redhat.com> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> <529CA1A2.9020509@redhat.com> <529CA481.7050000@redhat.com> <20131202162044.GC21264@redhat.com> <52A1C61D.20808@redhat.com> Message-ID: <1386338407.3255.110.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 13:42 +0100, Martin Kosek wrote: > On 12/02/2013 05:20 PM, Alexander Bokovoy wrote: > > On Mon, 02 Dec 2013, Martin Kosek wrote: > >> On 12/02/2013 04:05 PM, Petr Viktorin wrote: > >>> On 12/02/2013 03:42 PM, Simo Sorce wrote: > >>>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: > >>>>> On 12/02/2013 02:01 PM, Martin Kosek wrote: > >>>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: > >>>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: > >>>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: > >>>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: > >>>>>>>>>> Server and client installer should allow kernel keyring ccache when > >>>>>>>>>> supported. > >>>>>>> > >>>>>>>>> > >>>>>>>>> How do I enable the kernel keyring? On f20 I get this: > >>>>>>>>> > >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process > >>>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 > >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 > >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= > >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been > >>>>>>>>> revoked > >>>>>>>> > >>>>>>>> It should be enabled out of the box. But there were some initial issues > >>>>>>>> with > >>>>>>>> persistent keyring in the first versions of kernel with a support, > >>>>>>>> hopefully > >>>>>>>> this was just a fluke which disappeared. > >>>>>>>> > >>>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: > >>>>>>>> > >>>>>>>> # keyctl get_persistent @s 0 > >>>>>>>> 637466038 > >>>>>>> > >>>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: > >>>>>>> $ keyctl get_persistent @s 0 > >>>>>>> keyctl_get_persistent: Key has been revoked > >>>>>> > >>>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a > >>>>>> non-root user... > >>>>> > >>>>> It is just a typo, but it looks like you got me on the right track. > >>>>> keyctl apparently needs a real root login: > >>>>> > >>>>> $ sudo keyctl get_persistent @s 0 > >>>>> keyctl_get_persistent: Key has been revoked > >>>>> > >>>>> $ sudo su > >>>>> # keyctl get_persistent @s 0 > >>>>> keyctl_get_persistent: Key has been revoked > >>>>> # exit > >>>>> > >>>>> $ sudo su - > >>>>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 > >>>>> # keyctl get_persistent @s 0 > >>>>> 968622527 > >>>>> # logout > >>>>> > >>>> > >>>> Please use "sudo -i" to get an interactive 'login' shell. > >>>> > >>>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains > >>>>> that the key is unsupported. From a root login all is OK. > >>>>> > >>>>> Is that expected? > >>>> > >>>> You should run ipa-server-install using a login shell I think. > >>>> Should we open a bug to detect this and fail ? > >>> > >>> It's always worked with just sudo for me. So yes, if it's required I think we > >>> should enforce it. > >>> > >> > >> Simo or Alexander, is there some way to find that out in a clean way? I mean if > >> we are in an interactive login shell. Ideally, please also file a bug with this > >> information :) > > Interactive or login? These two are different a bit. > > > > There is no general way because not all shells implement common approach > > to detect this. For example, > > echo $- | grep -q i > > > > would work in a Bourne-style shell for interactive shell > > > > shopt -q login_shell > > > > would give you a login shell detector in bash but > > > > test $options[LOGIN] = on > > > > would work for login shell in zsh, similarly INTERACTIVE index would > > give you state of interactive shell. > > > > > > I meant login shell - so that we do not have problems with checking the > get_persistent keyctl command. > > I still do not fully understand the keyctl behavior, it is working on my > kernel-3.11.9-300.fc20.x86_64 even with plain "sudo": > > $ sudo keyctl get_persistent @s 0 I think the previous behavior was cause by the improper selinux handling in the kernel, and is fixed in the latest kernel. There is indeed no reason why get_persistent shouldn't work for non-login shell unless selinux policy explicitly disallows it for sudo like programs. > Anyway, any opinions on this particular patch? I'd prefer to get it in soon and > file enhancement ticket for the login terminal detection, if needed. I do not have any objections. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 6 14:28:23 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 09:28:23 -0500 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <52A1CDCC.5020209@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> Message-ID: <1386340103.3255.117.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: > On 12/02/2013 02:48 PM, Petr Viktorin wrote: > > On 12/02/2013 02:29 PM, Simo Sorce wrote: > >> It would be very nice if you can add the resulting LDAP objects in the > >> example, that will allow me to reason on the correctness of the > >> translation. > > > > OK, I'll work on that. > > I've added the resulting LDAP objects to the tests here: > http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests Thank you Petr, I was looking at them and I see we often use target=ldap:// type for selecting which objects this apply to. This was sort of necessary when the permissions were all in the base and we wanted to limit to specific entries in subtrees. However I was wondering if we shouldn't transition/allow to user targetfilter or targetattrfilter (this would be needed to have add/delete permissions). For example, instead of: (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") We could have: (targetfilter = "(objectclass=ipaUser)") It also occurs to me we could do very neat things like allowing manager access with (targetfilter = "(managedby=)"), and similar. In general using targetfilter and targetattrfilter is more flexible and allow for applying different permission depending exacly on the object type or even specific sets of objects of a common type. Something the simple target filter cannot do. What do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 6 14:36:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 15:36:54 +0100 Subject: [Freeipa-devel] FreeIPA Continuous Integration Configuration Message-ID: <52A1E106.3010005@redhat.com> Hello, As some of you are aware, I'm running a Jenkins instance for FreeIPA continuous integration in our lab here at Red Hat Brno. I'm currently porting the job definitions to jenkins-job-builder[0] for ease of management. This allowed me to strip out the private bits from the configuration, so anyone can use the config to run FreeIPA tests in their own Jenkins. In the spirit of "release early", here is the repo: https://github.com/encukou/freeipa-ci I'll update as I port more of the tests to YAML. If you want any help setting up tests for IPA, or if you have some suggestions, please get in touch! [0] https://github.com/openstack-infra/jenkins-job-builder -- Petr? From pviktori at redhat.com Fri Dec 6 14:46:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 15:46:51 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <1386340103.3255.117.camel@willson.li.ssimo.org> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> Message-ID: <52A1E35B.9060207@redhat.com> On 12/06/2013 03:28 PM, Simo Sorce wrote: > On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: >> On 12/02/2013 02:48 PM, Petr Viktorin wrote: >>> On 12/02/2013 02:29 PM, Simo Sorce wrote: > >>>> It would be very nice if you can add the resulting LDAP objects in the >>>> example, that will allow me to reason on the correctness of the >>>> translation. >>> >>> OK, I'll work on that. >> >> I've added the resulting LDAP objects to the tests here: >> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests > > Thank you Petr, > I was looking at them and I see we often use target=ldap:// type for > selecting which objects this apply to. > > This was sort of necessary when the permissions were all in the base and > we wanted to limit to specific entries in subtrees. > > However I was wondering if we shouldn't transition/allow to user > targetfilter or targetattrfilter (this would be needed to have > add/delete permissions). > > For example, instead of: > (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") > We could have: > (targetfilter = "(objectclass=ipaUser)") > > It also occurs to me we could do very neat things like allowing manager > access with (targetfilter = "(managedby=)"), and similar. > > In general using targetfilter and targetattrfilter is more flexible and > allow for applying different permission depending exacly on the object > type or even specific sets of objects of a common type. Something the > simple target filter cannot do. > > What do you think ? +1 I don't think this should block the framework patches that are on list now, though. I'll file a RFE for tuning how the default and "type" permissions look. Would that be fine? -- Petr? From simo at redhat.com Fri Dec 6 14:49:27 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 09:49:27 -0500 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <52A1E35B.9060207@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> <52A1E35B.9060207@redhat.com> Message-ID: <1386341367.3255.124.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote: > On 12/06/2013 03:28 PM, Simo Sorce wrote: > > On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: > >> On 12/02/2013 02:48 PM, Petr Viktorin wrote: > >>> On 12/02/2013 02:29 PM, Simo Sorce wrote: > > > >>>> It would be very nice if you can add the resulting LDAP objects in the > >>>> example, that will allow me to reason on the correctness of the > >>>> translation. > >>> > >>> OK, I'll work on that. > >> > >> I've added the resulting LDAP objects to the tests here: > >> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests > > > > Thank you Petr, > > I was looking at them and I see we often use target=ldap:// type for > > selecting which objects this apply to. > > > > This was sort of necessary when the permissions were all in the base and > > we wanted to limit to specific entries in subtrees. > > > > However I was wondering if we shouldn't transition/allow to user > > targetfilter or targetattrfilter (this would be needed to have > > add/delete permissions). > > > > For example, instead of: > > (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") > > We could have: > > (targetfilter = "(objectclass=ipaUser)") > > > > It also occurs to me we could do very neat things like allowing manager > > access with (targetfilter = "(managedby=)"), and similar. > > > > In general using targetfilter and targetattrfilter is more flexible and > > allow for applying different permission depending exacly on the object > > type or even specific sets of objects of a common type. Something the > > simple target filter cannot do. > > > > What do you think ? > > +1 > > I don't think this should block the framework patches that are on list > now, though. I'll file a RFE for tuning how the default and "type" > permissions look. Would that be fine? Do we need a new attribute, or do you think we can do this without changing the schema ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 6 14:54:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Dec 2013 09:54:39 -0500 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <1386341367.3255.124.camel@willson.li.ssimo.org> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> <52A1E35B.9060207@redhat.com> <1386341367.3255.124.camel@willson.li.ssimo.org> Message-ID: <52A1E52F.8040801@redhat.com> Simo Sorce wrote: > On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote: >> On 12/06/2013 03:28 PM, Simo Sorce wrote: >>> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: >>>> On 12/02/2013 02:48 PM, Petr Viktorin wrote: >>>>> On 12/02/2013 02:29 PM, Simo Sorce wrote: >>> >>>>>> It would be very nice if you can add the resulting LDAP objects in the >>>>>> example, that will allow me to reason on the correctness of the >>>>>> translation. >>>>> >>>>> OK, I'll work on that. >>>> >>>> I've added the resulting LDAP objects to the tests here: >>>> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests >>> >>> Thank you Petr, >>> I was looking at them and I see we often use target=ldap:// type for >>> selecting which objects this apply to. >>> >>> This was sort of necessary when the permissions were all in the base and >>> we wanted to limit to specific entries in subtrees. >>> >>> However I was wondering if we shouldn't transition/allow to user >>> targetfilter or targetattrfilter (this would be needed to have >>> add/delete permissions). >>> >>> For example, instead of: >>> (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") >>> We could have: >>> (targetfilter = "(objectclass=ipaUser)") >>> >>> It also occurs to me we could do very neat things like allowing manager >>> access with (targetfilter = "(managedby=)"), and similar. >>> >>> In general using targetfilter and targetattrfilter is more flexible and >>> allow for applying different permission depending exacly on the object >>> type or even specific sets of objects of a common type. Something the >>> simple target filter cannot do. >>> >>> What do you think ? >> >> +1 >> >> I don't think this should block the framework patches that are on list >> now, though. I'll file a RFE for tuning how the default and "type" >> permissions look. Would that be fine? > > Do we need a new attribute, or do you think we can do this without > changing the schema ? Right now type implies the target used. I think it would just change to be a targetfilter instead (or a piece of one anyway). What may be tricky is combining a type and a user-profiled filter, and then decomposing that, without a separate attribute. rob From pviktori at redhat.com Fri Dec 6 15:02:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 16:02:07 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <1386341367.3255.124.camel@willson.li.ssimo.org> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> <52A1E35B.9060207@redhat.com> <1386341367.3255.124.camel@willson.li.ssimo.org> Message-ID: <52A1E6EF.6010708@redhat.com> On 12/06/2013 03:49 PM, Simo Sorce wrote: > On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote: >> On 12/06/2013 03:28 PM, Simo Sorce wrote: >>> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: >>>> On 12/02/2013 02:48 PM, Petr Viktorin wrote: >>>>> On 12/02/2013 02:29 PM, Simo Sorce wrote: >>> >>>>>> It would be very nice if you can add the resulting LDAP objects in the >>>>>> example, that will allow me to reason on the correctness of the >>>>>> translation. >>>>> >>>>> OK, I'll work on that. >>>> >>>> I've added the resulting LDAP objects to the tests here: >>>> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests >>> >>> Thank you Petr, >>> I was looking at them and I see we often use target=ldap:// type for >>> selecting which objects this apply to. >>> >>> This was sort of necessary when the permissions were all in the base and >>> we wanted to limit to specific entries in subtrees. >>> >>> However I was wondering if we shouldn't transition/allow to user >>> targetfilter or targetattrfilter (this would be needed to have >>> add/delete permissions). >>> >>> For example, instead of: >>> (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") >>> We could have: >>> (targetfilter = "(objectclass=ipaUser)") >>> >>> It also occurs to me we could do very neat things like allowing manager >>> access with (targetfilter = "(managedby=)"), and similar. >>> >>> In general using targetfilter and targetattrfilter is more flexible and >>> allow for applying different permission depending exacly on the object >>> type or even specific sets of objects of a common type. Something the >>> simple target filter cannot do. >>> >>> What do you think ? >> >> +1 >> >> I don't think this should block the framework patches that are on list >> now, though. I'll file a RFE for tuning how the default and "type" >> permissions look. Would that be fine? > > Do we need a new attribute, or do you think we can do this without > changing the schema ? Ah, yes. Please reserve ipaPermTargetAttrFilter. (ipaPermTargetFilter is already reserved) -- Petr? From mkosek at redhat.com Fri Dec 6 15:07:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Dec 2013 16:07:22 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <1386340103.3255.117.camel@willson.li.ssimo.org> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> Message-ID: <52A1E82A.9030202@redhat.com> On 12/06/2013 03:28 PM, Simo Sorce wrote: > On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: >> On 12/02/2013 02:48 PM, Petr Viktorin wrote: >>> On 12/02/2013 02:29 PM, Simo Sorce wrote: > >>>> It would be very nice if you can add the resulting LDAP objects in the >>>> example, that will allow me to reason on the correctness of the >>>> translation. >>> >>> OK, I'll work on that. >> >> I've added the resulting LDAP objects to the tests here: >> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests > > Thank you Petr, > I was looking at them and I see we often use target=ldap:// type for > selecting which objects this apply to. > > This was sort of necessary when the permissions were all in the base and > we wanted to limit to specific entries in subtrees. > > However I was wondering if we shouldn't transition/allow to user > targetfilter or targetattrfilter (this would be needed to have > add/delete permissions). > > For example, instead of: > (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") > We could have: > (targetfilter = "(objectclass=ipaUser)") > > It also occurs to me we could do very neat things like allowing manager > access with (targetfilter = "(managedby=)"), and similar. > > In general using targetfilter and targetattrfilter is more flexible and > allow for applying different permission depending exacly on the object > type or even specific sets of objects of a common type. Something the > simple target filter cannot do. > > What do you think ? > > Simo. > > I am all in. I still remember what we had to do to update ACIs for SUDO commands just because the default RDN changed, e.g.: remove:aci: '(target = "ldap:///sudocmd=*,cn=sudocmds,cn=sudo,$SUFFIX")(version 3.0;acl "permission: Delete Sudo command";allow (delete) groupdn = "ldap:///cn=Delete Sudo command,cn=permissions,cn=pbac, $SUFFIX";)' add:aci: '(targetfilter = "(objectclass=ipasudocmd)")(target = "ldap:///cn=sudocmds,cn=sudo, $SUFFIX")(version 3.0;acl "permission:Delete Sudo command";allow (delete) groupdn = "ldap:///cn=Delete Sudo command,cn=permissions,cn=pbac,$SUFFIX";)' With this approach, no change would be needed at all - neat! Martin From pviktori at redhat.com Fri Dec 6 15:08:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 16:08:22 +0100 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <52A1E52F.8040801@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> <52A1E35B.9060207@redhat.com> <1386341367.3255.124.camel@willson.li.ssimo.org> <52A1E52F.8040801@redhat.com> Message-ID: <52A1E866.3050301@redhat.com> On 12/06/2013 03:54 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote: >>> On 12/06/2013 03:28 PM, Simo Sorce wrote: >>>> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: >>>>> On 12/02/2013 02:48 PM, Petr Viktorin wrote: >>>>>> On 12/02/2013 02:29 PM, Simo Sorce wrote: >>>> >>>>>>> It would be very nice if you can add the resulting LDAP objects >>>>>>> in the >>>>>>> example, that will allow me to reason on the correctness of the >>>>>>> translation. >>>>>> >>>>>> OK, I'll work on that. >>>>> >>>>> I've added the resulting LDAP objects to the tests here: >>>>> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests >>>> >>>> Thank you Petr, >>>> I was looking at them and I see we often use target=ldap:// type >>>> for >>>> selecting which objects this apply to. >>>> >>>> This was sort of necessary when the permissions were all in the base >>>> and >>>> we wanted to limit to specific entries in subtrees. >>>> >>>> However I was wondering if we shouldn't transition/allow to user >>>> targetfilter or targetattrfilter (this would be needed to have >>>> add/delete permissions). >>>> >>>> For example, instead of: >>>> (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") >>>> We could have: >>>> (targetfilter = "(objectclass=ipaUser)") >>>> >>>> It also occurs to me we could do very neat things like allowing manager >>>> access with (targetfilter = "(managedby=)"), and similar. >>>> >>>> In general using targetfilter and targetattrfilter is more flexible and >>>> allow for applying different permission depending exacly on the object >>>> type or even specific sets of objects of a common type. Something the >>>> simple target filter cannot do. >>>> >>>> What do you think ? >>> >>> +1 >>> >>> I don't think this should block the framework patches that are on list >>> now, though. I'll file a RFE for tuning how the default and "type" >>> permissions look. Would that be fine? >> >> Do we need a new attribute, or do you think we can do this without >> changing the schema ? > > Right now type implies the target used. I think it would just change to > be a targetfilter instead (or a piece of one anyway). What may be tricky > is combining a type and a user-profiled filter, and then decomposing > that, without a separate attribute. The design changes --type to be a "shortcut" for setting location and filter at the same time. Those two are what's actually stored in LDAP, and on output "type" is added if those two match a known object type. We may (in the RFE I'm about to file) want to make targetfilter & targetattrfilter multivalued, and e.g. make --type work on objectclass filters only. -- Petr? From pviktori at redhat.com Fri Dec 6 15:52:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Dec 2013 16:52:32 +0100 Subject: [Freeipa-devel] [PATCH] 0333 test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts Message-ID: <52A1F2C0.9050000@redhat.com> Hello, As I'm consolidating test job configuration, I learned that the line no_dns: False in WebUI test config has the same effect as `no_dns: True`. This is confusing, and it complicates generating the config. Patch is untested because I don't have the WebUI test environment set up locally. Petr, could you check if it works? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0333-test_webui-Allow-False-values-in-configuration-for-n.patch Type: text/x-patch Size: 1564 bytes Desc: not available URL: From simo at redhat.com Fri Dec 6 15:59:07 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 10:59:07 -0500 Subject: [Freeipa-devel] [RFE] Permissions V2 In-Reply-To: <52A1E6EF.6010708@redhat.com> References: <527B7D47.8030806@redhat.com> <5280F01F.7020907@redhat.com> <5280FC59.9050003@redhat.com> <5298B805.4080100@redhat.com> <1385990973.14987.56.camel@willson.li.ssimo.org> <529C8FB8.9020503@redhat.com> <52A1CDCC.5020209@redhat.com> <1386340103.3255.117.camel@willson.li.ssimo.org> <52A1E35B.9060207@redhat.com> <1386341367.3255.124.camel@willson.li.ssimo.org> <52A1E6EF.6010708@redhat.com> Message-ID: <1386345547.3255.130.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 16:02 +0100, Petr Viktorin wrote: > On 12/06/2013 03:49 PM, Simo Sorce wrote: > > On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote: > >> On 12/06/2013 03:28 PM, Simo Sorce wrote: > >>> On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote: > >>>> On 12/02/2013 02:48 PM, Petr Viktorin wrote: > >>>>> On 12/02/2013 02:29 PM, Simo Sorce wrote: > >>> > >>>>>> It would be very nice if you can add the resulting LDAP objects in the > >>>>>> example, that will allow me to reason on the correctness of the > >>>>>> translation. > >>>>> > >>>>> OK, I'll work on that. > >>>> > >>>> I've added the resulting LDAP objects to the tests here: > >>>> http://www.freeipa.org/index.php?title=V3/Permissions_V2/tests > >>> > >>> Thank you Petr, > >>> I was looking at them and I see we often use target=ldap:// type for > >>> selecting which objects this apply to. > >>> > >>> This was sort of necessary when the permissions were all in the base and > >>> we wanted to limit to specific entries in subtrees. > >>> > >>> However I was wondering if we shouldn't transition/allow to user > >>> targetfilter or targetattrfilter (this would be needed to have > >>> add/delete permissions). > >>> > >>> For example, instead of: > >>> (target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX") > >>> We could have: > >>> (targetfilter = "(objectclass=ipaUser)") > >>> > >>> It also occurs to me we could do very neat things like allowing manager > >>> access with (targetfilter = "(managedby=)"), and similar. > >>> > >>> In general using targetfilter and targetattrfilter is more flexible and > >>> allow for applying different permission depending exacly on the object > >>> type or even specific sets of objects of a common type. Something the > >>> simple target filter cannot do. > >>> > >>> What do you think ? > >> > >> +1 > >> > >> I don't think this should block the framework patches that are on list > >> now, though. I'll file a RFE for tuning how the default and "type" > >> permissions look. Would that be fine? > > > > Do we need a new attribute, or do you think we can do this without > > changing the schema ? > > Ah, yes. Please reserve ipaPermTargetAttrFilter. > (ipaPermTargetFilter is already reserved) Use: 2.16.840.1.113730.3.8.11.50 Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 6 16:10:20 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 11:10:20 -0500 Subject: [Freeipa-devel] [PATCH] 531 Fix license in some Web UI files In-Reply-To: <52A1CEE5.2020200@redhat.com> References: <52A1CEE5.2020200@redhat.com> Message-ID: <1386346220.3255.132.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 14:19 +0100, Petr Vobornik wrote: > Modified web ui files had incorrect GPLv2 headers instead of GPLv3 ones. > > All of the affected code is of FreeIPA origin. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 6 16:32:29 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 11:32:29 -0500 Subject: [Freeipa-devel] [PATCH][DOCS] Fix password synchronization manager explanation Message-ID: <1386347549.3255.139.camel@willson.li.ssimo.org> The current text is wrong and misleading, can we expedite trickling this change all the way down all downstream documentation ? (Ie Fedora official user guides). Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-password-sync-managers-paragraph.patch Type: text/x-patch Size: 2524 bytes Desc: not available URL: From ayoung at redhat.com Fri Dec 6 16:39:04 2013 From: ayoung at redhat.com (Adam Young) Date: Fri, 06 Dec 2013 11:39:04 -0500 Subject: [Freeipa-devel] Building FreeIPA on Debian Unstable In-Reply-To: <5280F6D4.3050106@ubuntu.com> References: <5272AD52.5030507@redhat.com> <5280F6D4.3050106@ubuntu.com> Message-ID: <52A1FDA8.5040605@redhat.com> >> And...that was pretty much as far as I got. > with the updated repo + updates from the ppa the build succeeds but > tests fail, and those are harder for me to parse. Full build log at > > http://pastebin.com/G40VMENn Your first error is: Failure: ImportError (No module named samba) ... ERROR followed by missing ipaclient and pyasn1 modules. There seem to be a slew of Kerberos errors, which indicate that the Kerberos server was not getting set up to run correctly...which may in fact be due to the Directory server not running correctly. I'd start with ensuring 389, then Kerberos, don't have any path dependnceis that are different between Debian and Fedora. The radius issue might be enough to mess up Kerberos, but I doubt it. > >> Once we get a working process we can clean up the documentation. >> >> Looks like we need 1.12 of Kerberos to get Radius support, worth pinging >> the Debian krb supporters to see if they have a package in the works. > I filed a bug about it, we'll see how it goes. Maybe 1.12 is ready soon > enough. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729291 > > > Also, since I submitted the patches for client support I did work on > them to fix the issues I found, but never sent any status update to the > previous thread. IIRC there is one issue left with how to handle > updating pam configs, or maybe just leave it up to the package to deal > instead of ipa-client-install.. (since enabling them by default on > package install isn't a huge deal) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Sat Dec 7 19:25:32 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sat, 07 Dec 2013 21:25:32 +0200 Subject: [Freeipa-devel] Building FreeIPA on Debian Unstable In-Reply-To: <52A1FDA8.5040605@redhat.com> References: <5272AD52.5030507@redhat.com> <5280F6D4.3050106@ubuntu.com> <52A1FDA8.5040605@redhat.com> Message-ID: <52A3762C.4010902@ubuntu.com> On 06.12.2013 18:39, Adam Young wrote: > >>> And...that was pretty much as far as I got. >> with the updated repo + updates from the ppa the build succeeds but >> tests fail, and those are harder for me to parse. Full build log at >> >> http://pastebin.com/G40VMENn > Your first error is: > > Failure: ImportError (No module named samba) ... ERROR > > followed by missing ipaclient and pyasn1 modules. > > There seem to be a slew of Kerberos errors, which indicate that the > Kerberos server was not getting set up to run correctly...which may in > fact be due to the Directory server not running correctly. I'd start > with ensuring 389, then Kerberos, don't have any path dependnceis that > are different between Debian and Fedora. The radius issue might be > enough to mess up Kerberos, but I doubt it. Indeed, and actually the failure in this case is running make-test at all, since it won't ever succeed during package build.. It was already disabled for client build, but now it's disabled for server too. -- t From pviktori at redhat.com Mon Dec 9 09:19:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Dec 2013 10:19:21 +0100 Subject: [Freeipa-devel] [PATCH] 531 Fix license in some Web UI files In-Reply-To: <1386346220.3255.132.camel@willson.li.ssimo.org> References: <52A1CEE5.2020200@redhat.com> <1386346220.3255.132.camel@willson.li.ssimo.org> Message-ID: <52A58B19.3040003@redhat.com> On 12/06/2013 05:10 PM, Simo Sorce wrote: > On Fri, 2013-12-06 at 14:19 +0100, Petr Vobornik wrote: >> Modified web ui files had incorrect GPLv2 headers instead of GPLv3 ones. >> >> All of the affected code is of FreeIPA origin. > > Ack. > Simo. > Pushed to master: b6540e88d88470f6566507e442f521214c5a74dc ipa-3-3: 2877f5d8a11ebdd32c2007b26facab2073cf48ad -- Petr? From tbabej at redhat.com Mon Dec 9 11:08:07 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 09 Dec 2013 12:08:07 +0100 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION In-Reply-To: <52A0738E.60302@redhat.com> References: <52A0738E.60302@redhat.com> Message-ID: <52A5A497.3070408@redhat.com> On 12/05/2013 01:37 PM, Petr Viktorin wrote: > Consider this scenario: > > - Nathaniel submits RADIUS patches that update the API version (from > 2.69 to 2.70) > - I have ACI patches that also bump the version (from 2.69 to 2.70) > - Nathaniel's patches gets accepted > - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 > change is already done, so it leaves VERSION unchanged. > > I can solve this locally by telling Git to not merge VERSION > automatically, but I think it would be helpful to add a unique comment > to each change so that everyone gets a conflict cases like this. > Do you agree? > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense to me. I'd just add a comment so that the purpose of the last change comment is also obvious for the new developer perusing the VERSION file. Maybe something along the lines of: ######################################################## IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=70 +# Update the last change entry to enforce conflict on merging two independent branches into master. +# Last change: npmccallum - RADIUS support -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Dec 9 11:24:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Dec 2013 12:24:12 +0100 Subject: [Freeipa-devel] [PATCH] 439 Allow kernel keyring CCACHE when supported In-Reply-To: <1386338407.3255.110.camel@willson.li.ssimo.org> References: <52793758.9020407@redhat.com> <528B4CEA.9020304@redhat.com> <52988D19.5040504@redhat.com> <529C83EF.9010408@redhat.com> <529C84A5.2030805@redhat.com> <529C9079.5010403@redhat.com> <1385995322.14987.70.camel@willson.li.ssimo.org> <529CA1A2.9020509@redhat.com> <529CA481.7050000@redhat.com> <20131202162044.GC21264@redhat.com> <52A1C61D.20808@redhat.com> <1386338407.3255.110.camel@willson.li.ssimo.org> Message-ID: <52A5A85C.7020609@redhat.com> On 12/06/2013 03:00 PM, Simo Sorce wrote: > On Fri, 2013-12-06 at 13:42 +0100, Martin Kosek wrote: >> On 12/02/2013 05:20 PM, Alexander Bokovoy wrote: >>> On Mon, 02 Dec 2013, Martin Kosek wrote: >>>> On 12/02/2013 04:05 PM, Petr Viktorin wrote: >>>>> On 12/02/2013 03:42 PM, Simo Sorce wrote: >>>>>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >>>>>>> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>>>>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>>>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>>>>>>> supported. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>>>>>>> >>>>>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been >>>>>>>>>>> revoked >>>>>>>>>> >>>>>>>>>> It should be enabled out of the box. But there were some initial issues >>>>>>>>>> with >>>>>>>>>> persistent keyring in the first versions of kernel with a support, >>>>>>>>>> hopefully >>>>>>>>>> this was just a fluke which disappeared. >>>>>>>>>> >>>>>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>>>>>>> >>>>>>>>>> # keyctl get_persistent @s 0 >>>>>>>>>> 637466038 >>>>>>>>> >>>>>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>>>>>>> $ keyctl get_persistent @s 0 >>>>>>>>> keyctl_get_persistent: Key has been revoked >>>>>>>> >>>>>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>>>>>>> non-root user... >>>>>>> >>>>>>> It is just a typo, but it looks like you got me on the right track. >>>>>>> keyctl apparently needs a real root login: >>>>>>> >>>>>>> $ sudo keyctl get_persistent @s 0 >>>>>>> keyctl_get_persistent: Key has been revoked >>>>>>> >>>>>>> $ sudo su >>>>>>> # keyctl get_persistent @s 0 >>>>>>> keyctl_get_persistent: Key has been revoked >>>>>>> # exit >>>>>>> >>>>>>> $ sudo su - >>>>>>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >>>>>>> # keyctl get_persistent @s 0 >>>>>>> 968622527 >>>>>>> # logout >>>>>>> >>>>>> >>>>>> Please use "sudo -i" to get an interactive 'login' shell. >>>>>> >>>>>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains >>>>>>> that the key is unsupported. From a root login all is OK. >>>>>>> >>>>>>> Is that expected? >>>>>> >>>>>> You should run ipa-server-install using a login shell I think. >>>>>> Should we open a bug to detect this and fail ? >>>>> >>>>> It's always worked with just sudo for me. So yes, if it's required I think we >>>>> should enforce it. >>>>> >>>> >>>> Simo or Alexander, is there some way to find that out in a clean way? I mean if >>>> we are in an interactive login shell. Ideally, please also file a bug with this >>>> information :) >>> Interactive or login? These two are different a bit. >>> >>> There is no general way because not all shells implement common approach >>> to detect this. For example, >>> echo $- | grep -q i >>> >>> would work in a Bourne-style shell for interactive shell >>> >>> shopt -q login_shell >>> >>> would give you a login shell detector in bash but >>> >>> test $options[LOGIN] = on >>> >>> would work for login shell in zsh, similarly INTERACTIVE index would >>> give you state of interactive shell. >>> >>> >> >> I meant login shell - so that we do not have problems with checking the >> get_persistent keyctl command. >> >> I still do not fully understand the keyctl behavior, it is working on my >> kernel-3.11.9-300.fc20.x86_64 even with plain "sudo": >> >> $ sudo keyctl get_persistent @s 0 > > I think the previous behavior was cause by the improper selinux handling > in the kernel, and is fixed in the latest kernel. There is indeed no > reason why get_persistent shouldn't work for non-login shell unless > selinux policy explicitly disallows it for sudo like programs. > >> Anyway, any opinions on this particular patch? I'd prefer to get it in soon and >> file enhancement ticket for the login terminal detection, if needed. > > I do not have any objections. > > Simo. ACK, pushed to * master: 9677308caa78ed722570aea32f21334b8c27bad3 * ipa-3-3: 5b2ce3c5a57e8193ee1c6d23c4e79c3b2b62cb05 -- Petr? From mkosek at redhat.com Mon Dec 9 11:39:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 12:39:41 +0100 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION In-Reply-To: <52A5A497.3070408@redhat.com> References: <52A0738E.60302@redhat.com> <52A5A497.3070408@redhat.com> Message-ID: <52A5ABFD.5090002@redhat.com> On 12/09/2013 12:08 PM, Tomas Babej wrote: > On 12/05/2013 01:37 PM, Petr Viktorin wrote: >> Consider this scenario: >> >> - Nathaniel submits RADIUS patches that update the API version (from 2.69 to >> 2.70) >> - I have ACI patches that also bump the version (from 2.69 to 2.70) >> - Nathaniel's patches gets accepted >> - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change >> is already done, so it leaves VERSION unchanged. >> >> I can solve this locally by telling Git to not merge VERSION automatically, >> but I think it would be helpful to add a unique comment to each change so >> that everyone gets a conflict cases like this. >> Do you agree? >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Makes sense to me. > > I'd just add a comment so that the purpose of the last change comment is also > obvious for the new developer perusing the VERSION file. > > Maybe something along the lines of: > > ######################################################## > IPA_API_VERSION_MAJOR=2 > IPA_API_VERSION_MINOR=70 > +# Update the last change entry to enforce conflict on merging two independent > branches into master. > +# Last change: npmccallum - RADIUS support I spoke with Petr offline, to me it would make bigger sense if we just forbid automatic merging of this line on the git server side (if possible) instead of adding other arbitrary work to our development process. IIRC, Petr3 said it should be possible to do. Martin From mkosek at redhat.com Mon Dec 9 11:48:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 12:48:53 +0100 Subject: [Freeipa-devel] libtool --finish warnings in build log Message-ID: <52A5AE25.6090707@redhat.com> Hello, I saw that build of FreeIPA produces several strange warnings: libtool: install: warning: remember to run `libtool --finish /usr/lib64/krb5/plugins/kdb' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/dirsrv/plugins' libtool: install: warning: remember to run `libtool --finish /usr/lib64/samba/pdb' As Lukas Slebodnik told me, this is because we install our libraries (plugins) to an uncommon directory. Can/Should we do something about it? If this is OK, can we maybe add some flag to avoid these warnings? Thanks, Martin From abokovoy at redhat.com Mon Dec 9 12:00:21 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Dec 2013 14:00:21 +0200 Subject: [Freeipa-devel] libtool --finish warnings in build log In-Reply-To: <52A5AE25.6090707@redhat.com> References: <52A5AE25.6090707@redhat.com> Message-ID: <20131209120021.GO21264@redhat.com> On Mon, 09 Dec 2013, Martin Kosek wrote: >Hello, > >I saw that build of FreeIPA produces several strange warnings: > >libtool: install: warning: remember to run `libtool --finish >/usr/lib64/krb5/plugins/kdb' >libtool: install: warning: remember to run `libtool --finish >/usr/lib64/dirsrv/plugins' >libtool: install: warning: remember to run `libtool --finish >/usr/lib64/dirsrv/plugins' >libtool: install: warning: remember to run `libtool --finish /usr/lib64/samba/pdb' > >As Lukas Slebodnik told me, this is because we install our libraries (plugins) >to an uncommon directory. Can/Should we do something about it? If this is OK, >can we maybe add some flag to avoid these warnings? We can simply ignore them since 'libtool --finish' would in addition to --installupdate .la files which will anyway be removed and never appear in the resulting RPM package. -- / Alexander Bokovoy From mkosek at redhat.com Mon Dec 9 12:35:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 13:35:37 +0100 Subject: [Freeipa-devel] [PATCH 0134] ipa-client-install: Always pass hostname to the ipa-join In-Reply-To: <5294B23C.9050109@redhat.com> References: <5294B23C.9050109@redhat.com> Message-ID: <52A5B919.1050406@redhat.com> On 11/26/2013 03:37 PM, Tomas Babej wrote: > Hi, > > The ipa-client-install script and ipa-join use different methods > of resolving the hostname, the former uses gethostbyaddr() call, > while the latter reads the "uinfo.nodename". > > This can result ipa-client-install failures in case of broken PTR > records. > > https://fedorahosted.org/freeipa/ticket/4027 This fixed the issue for me. At least ipa-client-install and ipa-join will now use the same hostname and not give strange errors. ACK. Pushed to master, ipa-3-3. Martin From simo at redhat.com Mon Dec 9 13:35:15 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Dec 2013 08:35:15 -0500 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION In-Reply-To: <52A5ABFD.5090002@redhat.com> References: <52A0738E.60302@redhat.com> <52A5A497.3070408@redhat.com> <52A5ABFD.5090002@redhat.com> Message-ID: <1386596115.3255.207.camel@willson.li.ssimo.org> On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote: > On 12/09/2013 12:08 PM, Tomas Babej wrote: > > On 12/05/2013 01:37 PM, Petr Viktorin wrote: > >> Consider this scenario: > >> > >> - Nathaniel submits RADIUS patches that update the API version (from 2.69 to > >> 2.70) > >> - I have ACI patches that also bump the version (from 2.69 to 2.70) > >> - Nathaniel's patches gets accepted > >> - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change > >> is already done, so it leaves VERSION unchanged. > >> > >> I can solve this locally by telling Git to not merge VERSION automatically, > >> but I think it would be helpful to add a unique comment to each change so > >> that everyone gets a conflict cases like this. > >> Do you agree? > >> > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Makes sense to me. > > > > I'd just add a comment so that the purpose of the last change comment is also > > obvious for the new developer perusing the VERSION file. > > > > Maybe something along the lines of: > > > > ######################################################## > > IPA_API_VERSION_MAJOR=2 > > IPA_API_VERSION_MINOR=70 > > +# Update the last change entry to enforce conflict on merging two independent > > branches into master. > > +# Last change: npmccallum - RADIUS support > > I spoke with Petr offline, to me it would make bigger sense if we just forbid > automatic merging of this line on the git server side (if possible) instead of > adding other arbitrary work to our development process. > > IIRC, Petr3 said it should be possible to do. Except it may not fix the issue, if someone does a rebase on his machine and resubmit a patch to the list w/o noticing the change was effectively dropped. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Dec 9 13:50:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 14:50:40 +0100 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION In-Reply-To: <1386596115.3255.207.camel@willson.li.ssimo.org> References: <52A0738E.60302@redhat.com> <52A5A497.3070408@redhat.com> <52A5ABFD.5090002@redhat.com> <1386596115.3255.207.camel@willson.li.ssimo.org> Message-ID: <52A5CAB0.8000802@redhat.com> On 12/09/2013 02:35 PM, Simo Sorce wrote: > On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote: >> On 12/09/2013 12:08 PM, Tomas Babej wrote: >>> On 12/05/2013 01:37 PM, Petr Viktorin wrote: >>>> Consider this scenario: >>>> >>>> - Nathaniel submits RADIUS patches that update the API version (from 2.69 to >>>> 2.70) >>>> - I have ACI patches that also bump the version (from 2.69 to 2.70) >>>> - Nathaniel's patches gets accepted >>>> - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change >>>> is already done, so it leaves VERSION unchanged. >>>> >>>> I can solve this locally by telling Git to not merge VERSION automatically, >>>> but I think it would be helpful to add a unique comment to each change so >>>> that everyone gets a conflict cases like this. >>>> Do you agree? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Makes sense to me. >>> >>> I'd just add a comment so that the purpose of the last change comment is also >>> obvious for the new developer perusing the VERSION file. >>> >>> Maybe something along the lines of: >>> >>> ######################################################## >>> IPA_API_VERSION_MAJOR=2 >>> IPA_API_VERSION_MINOR=70 >>> +# Update the last change entry to enforce conflict on merging two independent >>> branches into master. >>> +# Last change: npmccallum - RADIUS support >> >> I spoke with Petr offline, to me it would make bigger sense if we just forbid >> automatic merging of this line on the git server side (if possible) instead of >> adding other arbitrary work to our development process. >> >> IIRC, Petr3 said it should be possible to do. > > Except it may not fix the issue, if someone does a rebase on his machine > and resubmit a patch to the list w/o noticing the change was effectively > dropped. > > Simo. I thought that the point of the anti-merge protection is to prevent git merging tools to prevent automatic rebase of this particular line and force manual merging, i.e. force increasing the number. Martin From pviktori at redhat.com Mon Dec 9 13:58:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Dec 2013 14:58:44 +0100 Subject: [Freeipa-devel] [PATCH] 0330 - Add comment about last change to VERSION In-Reply-To: <52A5CAB0.8000802@redhat.com> References: <52A0738E.60302@redhat.com> <52A5A497.3070408@redhat.com> <52A5ABFD.5090002@redhat.com> <1386596115.3255.207.camel@willson.li.ssimo.org> <52A5CAB0.8000802@redhat.com> Message-ID: <52A5CC94.5010809@redhat.com> On 12/09/2013 02:50 PM, Martin Kosek wrote: > On 12/09/2013 02:35 PM, Simo Sorce wrote: >> On Mon, 2013-12-09 at 12:39 +0100, Martin Kosek wrote: >>> On 12/09/2013 12:08 PM, Tomas Babej wrote: >>>> On 12/05/2013 01:37 PM, Petr Viktorin wrote: >>>>> Consider this scenario: >>>>> >>>>> - Nathaniel submits RADIUS patches that update the API version (from 2.69 to >>>>> 2.70) >>>>> - I have ACI patches that also bump the version (from 2.69 to 2.70) >>>>> - Nathaniel's patches gets accepted >>>>> - I rebase my ACI patches onto master. Git thinks that the 2.69->2.70 change >>>>> is already done, so it leaves VERSION unchanged. >>>>> >>>>> I can solve this locally by telling Git to not merge VERSION automatically, >>>>> but I think it would be helpful to add a unique comment to each change so >>>>> that everyone gets a conflict cases like this. >>>>> Do you agree? >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> Makes sense to me. >>>> >>>> I'd just add a comment so that the purpose of the last change comment is also >>>> obvious for the new developer perusing the VERSION file. >>>> >>>> Maybe something along the lines of: >>>> >>>> ######################################################## >>>> IPA_API_VERSION_MAJOR=2 >>>> IPA_API_VERSION_MINOR=70 >>>> +# Update the last change entry to enforce conflict on merging two independent >>>> branches into master. >>>> +# Last change: npmccallum - RADIUS support I don't think this is necessary, IMO "Last change:" is enough as instructions. >>> I spoke with Petr offline, to me it would make bigger sense if we just forbid >>> automatic merging of this line on the git server side (if possible) instead of >>> adding other arbitrary work to our development process. >>> >>> IIRC, Petr3 said it should be possible to do. >> >> Except it may not fix the issue, if someone does a rebase on his machine >> and resubmit a patch to the list w/o noticing the change was effectively >> dropped. >> >> Simo. > > I thought that the point of the anti-merge protection is to prevent git merging > tools to prevent automatic rebase of this particular line and force manual > merging, i.e. force increasing the number. When the file is equal on both sides of the merge, Git just uses the common file, and doesn't consider it for merging. So unfortunately, git attributes won't work here; there needs to be another change in the file. I did say otherwise, sorry for that. -- Petr? From mkosek at redhat.com Mon Dec 9 16:43:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 17:43:22 +0100 Subject: [Freeipa-devel] [PATCH] 441 Consolidate .gitignore entries Message-ID: <52A5F32A.4000909@redhat.com> Clean up the .gitignore file: - Remove no longer used .gitignore entries, like .bzr files - Do not repeat autotools generated files over and over again - Whitelist existent Makefiles in the repository - Better separate the .gitignore entries =========== When porting Jan's patches downstream, I had hard time merging changes to /Makefile in the repository as it was stated in .gitignore which made git (and me) suffer. I fixed that by whitelisting this one. Unfortunately, when I saw other entries in .gitignore I could not resist and refactored the file to make it (hopefully) simpler and easier to maintain. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-441-consolidate-.gitignore-entries.patch Type: text/x-patch Size: 3919 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 10 09:29:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 10:29:10 +0100 Subject: [Freeipa-devel] [PATCH] 441 Consolidate .gitignore entries In-Reply-To: <52A5F32A.4000909@redhat.com> References: <52A5F32A.4000909@redhat.com> Message-ID: <52A6DEE6.5040100@redhat.com> On 12/09/2013 05:43 PM, Martin Kosek wrote: > Clean up the .gitignore file: > - Remove no longer used .gitignore entries, like .bzr files > - Do not repeat autotools generated files over and over again > - Whitelist existent Makefiles in the repository > - Better separate the .gitignore entries > > =========== > > When porting Jan's patches downstream, I had hard time merging changes to > /Makefile in the repository as it was stated in .gitignore which made git (and > me) suffer. I fixed that by whitelisting this one. > > Unfortunately, when I saw other entries in .gitignore I could not resist and > refactored the file to make it (hopefully) simpler and easier to maintain. > > Martin > Thanks! ACK, pushed to master: 1e0405880fb1855563cb9b58a39213e1d3b4a2c6 -- Petr? From pviktori at redhat.com Tue Dec 10 11:18:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 12:18:13 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command In-Reply-To: <52A08369.8020301@redhat.com> References: <52A08369.8020301@redhat.com> Message-ID: <52A6F875.1090209@redhat.com> On 12/05/2013 02:45 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Patch looks good, ACK. I've added a small regression test for this, does it look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0334-Regression-test-for-user_status-crash.patch Type: text/x-patch Size: 2402 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 10 13:00:36 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Dec 2013 14:00:36 +0100 Subject: [Freeipa-devel] [PATCH] 0333 test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts In-Reply-To: <52A1F2C0.9050000@redhat.com> References: <52A1F2C0.9050000@redhat.com> Message-ID: <52A71074.40500@redhat.com> On 6.12.2013 16:52, Petr Viktorin wrote: > Hello, > As I'm consolidating test job configuration, I learned that the line > no_dns: False > in WebUI test config has the same effect as `no_dns: True`. This is > confusing, and it complicates generating the config. > > Patch is untested because I don't have the WebUI test environment set up > locally. Petr, could you check if it works? > Tested, ACK -- Petr Vobornik From jcholast at redhat.com Tue Dec 10 13:10:20 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Dec 2013 14:10:20 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods Message-ID: <52A712BC.2090109@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-213-Rename-LDAPEntry-method-commit-to-reset_modlist.patch Type: text/x-patch Size: 1237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-214-Use-old-entry-state-in-LDAPClient.update_entry.patch Type: text/x-patch Size: 3917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-215-Move-LDAPClient-method-get_single_value-to-IPASimple.patch Type: text/x-patch Size: 3089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-216-Make-IPASimpleLDAPObject.get_single_value-result-ove.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-217-Use-LDAPClient.update_entry-for-LDAP-mods-in-ldapupd.patch Type: text/x-patch Size: 4389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-218-Reduce-amount-of-LDAPEntry.reset_modlist-calls-in-ld.patch Type: text/x-patch Size: 1976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-219-Add-LDAPEntry-method-generate_modlist.patch Type: text/x-patch Size: 5328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-220-Remove-unused-LDAPClient-methods-get_syntax-and-get_.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-221-Remove-legacy-LDAPEntry-properties-data-and-orig_dat.patch Type: text/x-patch Size: 3357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-222-Store-old-entry-state-in-dict-rather-than-LDAPEntry.patch Type: text/x-patch Size: 3656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-223-Do-not-crash-on-bad-LDAP-data-when-formatting-decode.patch Type: text/x-patch Size: 1003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-224-Use-raw-LDAP-data-in-ldapupdate.patch Type: text/x-patch Size: 2337 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 10 13:15:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Dec 2013 14:15:38 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command In-Reply-To: <52A6F875.1090209@redhat.com> References: <52A08369.8020301@redhat.com> <52A6F875.1090209@redhat.com> Message-ID: <52A713FA.3060304@redhat.com> On 10.12.2013 12:18, Petr Viktorin wrote: > On 12/05/2013 02:45 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Patch looks good, ACK. > > I've added a small regression test for this, does it look OK? Thanks, it looks OK except I don't see "dn" in result and I would rename "isodate_re" to "generalizedtime_re". -- Jan Cholasta From pviktori at redhat.com Tue Dec 10 13:38:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 14:38:13 +0100 Subject: [Freeipa-devel] [PATCH] 0335 ipa-replica-install: Move check for existing host before DNS resolution check Message-ID: <52A71945.6040503@redhat.com> See commit message & ticket for details. https://fedorahosted.org/freeipa/ticket/3889 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0335-ipa-replica-install-Move-check-for-existing-host-bef.patch Type: text/x-patch Size: 3994 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 10 14:18:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 15:18:23 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command In-Reply-To: <52A713FA.3060304@redhat.com> References: <52A08369.8020301@redhat.com> <52A6F875.1090209@redhat.com> <52A713FA.3060304@redhat.com> Message-ID: <52A722AF.5070306@redhat.com> On 12/10/2013 02:15 PM, Jan Cholasta wrote: > On 10.12.2013 12:18, Petr Viktorin wrote: >> On 12/05/2013 02:45 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Patch looks good, ACK. >> >> I've added a small regression test for this, does it look OK? > > Thanks, it looks OK except I don't see "dn" in result and I would rename > "isodate_re" to "generalizedtime_re". Your patch adds "dn". user_status without --raw will report time in ISO 8601 (%Y-%m-%dT%H:%M:%SZ). GeneralizedTime would be "%Y%m%d%H%M%SZ". -- Petr? From jcholast at redhat.com Tue Dec 10 14:23:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Dec 2013 15:23:10 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command In-Reply-To: <52A722AF.5070306@redhat.com> References: <52A08369.8020301@redhat.com> <52A6F875.1090209@redhat.com> <52A713FA.3060304@redhat.com> <52A722AF.5070306@redhat.com> Message-ID: <52A723CE.2070306@redhat.com> On 10.12.2013 15:18, Petr Viktorin wrote: > On 12/10/2013 02:15 PM, Jan Cholasta wrote: >> On 10.12.2013 12:18, Petr Viktorin wrote: >>> On 12/05/2013 02:45 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>> >>> Patch looks good, ACK. >>> >>> I've added a small regression test for this, does it look OK? >> >> Thanks, it looks OK except I don't see "dn" in result and I would rename >> "isodate_re" to "generalizedtime_re". > > Your patch adds "dn". Oh, right. > > user_status without --raw will report time in ISO 8601 > (%Y-%m-%dT%H:%M:%SZ). GeneralizedTime would be "%Y%m%d%H%M%SZ". > Also right. Sorry for the fuss then, ACK. -- Jan Cholasta From pviktori at redhat.com Tue Dec 10 14:35:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 15:35:33 +0100 Subject: [Freeipa-devel] [PATCH] 211 Fix internal error in the user-status command In-Reply-To: <52A723CE.2070306@redhat.com> References: <52A08369.8020301@redhat.com> <52A6F875.1090209@redhat.com> <52A713FA.3060304@redhat.com> <52A722AF.5070306@redhat.com> <52A723CE.2070306@redhat.com> Message-ID: <52A726B5.8090505@redhat.com> On 12/10/2013 03:23 PM, Jan Cholasta wrote: > On 10.12.2013 15:18, Petr Viktorin wrote: >> On 12/10/2013 02:15 PM, Jan Cholasta wrote: >>> On 10.12.2013 12:18, Petr Viktorin wrote: >>>> On 12/05/2013 02:45 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>> >>>> Patch looks good, ACK. >>>> >>>> I've added a small regression test for this, does it look OK? >>> >>> Thanks, it looks OK except I don't see "dn" in result and I would rename >>> "isodate_re" to "generalizedtime_re". >> >> Your patch adds "dn". > > Oh, right. > >> >> user_status without --raw will report time in ISO 8601 >> (%Y-%m-%dT%H:%M:%SZ). GeneralizedTime would be "%Y%m%d%H%M%SZ". >> > > Also right. > > Sorry for the fuss then, ACK. > Thanks, pushed both to master: b6563984154e577cdf430f8f74f15f912ac0ee12 -- Petr? From pviktori at redhat.com Tue Dec 10 14:43:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 15:43:31 +0100 Subject: [Freeipa-devel] [PATCH] 0333 test_webui: Allow False values in configuration for no_ca, no_dns, has_trusts In-Reply-To: <52A71074.40500@redhat.com> References: <52A1F2C0.9050000@redhat.com> <52A71074.40500@redhat.com> Message-ID: <52A72893.2010608@redhat.com> On 12/10/2013 02:00 PM, Petr Vobornik wrote: > On 6.12.2013 16:52, Petr Viktorin wrote: >> Hello, >> As I'm consolidating test job configuration, I learned that the line >> no_dns: False >> in WebUI test config has the same effect as `no_dns: True`. This is >> confusing, and it complicates generating the config. >> >> Patch is untested because I don't have the WebUI test environment set up >> locally. Petr, could you check if it works? >> > > Tested, ACK Thanks, pushed to master: f2ee8a74032708717f8b370de5b1acc86d4d74cc ipa-3-3: 5640049f7aa132ab73099db856b352c3413489bb -- Petr? From jcholast at redhat.com Tue Dec 10 15:05:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Dec 2013 16:05:12 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API Message-ID: <52A72DA8.4090104@redhat.com> Hi, I believe the time has come to drop support for the legacy (dn, entry_attrs) tuple API and move to the new LDAPEntry API exclusively. The attached patches convert existing code which uses the old API to the new API and remove backward compatibility code from the ipaldap module. Note that there are still some functions/methods which accept separate dn and entry_attrs arguments, they will be adapted to LDAPEntry later. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-225-Convert-remaining-backend-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 9006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-226-Convert-remaining-frontend-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 104411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-227-Convert-remaining-installer-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 14360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-228-Convert-remaining-update-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 10420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-229-Convert-remaining-test-code-to-LDAPEntry-API.patch Type: text/x-patch Size: 3334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-230-Drop-support-for-the-legacy-LDAP-API.patch Type: text/x-patch Size: 5314 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 10 19:18:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Dec 2013 20:18:45 +0100 Subject: [Freeipa-devel] [PATCH] 0336 rpcserver: Consolidate __call__ in xmlclient and jsonclient_kerb Message-ID: <52A76915.8060007@redhat.com> See commit message & ticket. https://fedorahosted.org/freeipa/ticket/4069 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0336-rpcserver-Consolidate-__call__-in-xmlclient-and-json.patch Type: text/x-patch Size: 5890 bytes Desc: not available URL: From tbabej at redhat.com Wed Dec 11 10:50:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Dec 2013 11:50:08 +0100 Subject: [Freeipa-devel] [PATCH 0133] ipa-cldap: Cut NetBIOS name after 15 characters In-Reply-To: <1385563097.22025.112.camel@willson.li.ssimo.org> References: <5294B21F.7@redhat.com> <20131126155643.GG21264@redhat.com> <52959CCF.8050108@redhat.com> <20131127072516.GJ21264@redhat.com> <5295A44F.3090704@redhat.com> <1385563097.22025.112.camel@willson.li.ssimo.org> Message-ID: <52A84360.1070404@redhat.com> On 11/27/2013 03:38 PM, Simo Sorce wrote: > On Wed, 2013-11-27 at 08:50 +0100, Tomas Babej wrote: > Sorry to nitpick but ... > >> diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> index >> 7d29fe559be55607fcb6b83fa521372e5197b848..f2e74e2c5b6e0d04dd3dc0eb15f25593aa91da8e 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >> @@ -161,9 +161,13 @@ static int ipa_cldap_encode_netlogon(char >> *fq_hostname, char *domain, >> nlr->dns_domain = domain; >> nlr->pdc_dns_name = fq_hostname; >> nlr->domain_name = name; >> - pdc_name = talloc_asprintf(nlr, "\\\\%s", fq_hostname); >> + >> + /* copy the first 15 characters of the fully qualified hostname*/ >> + pdc_name = talloc_asprintf(nlr, "\\\\%.*s", 15, fq_hostname); > Probably better to #define NETBIOS_NAME_MAX 15 somewhere above and then > use the macro here. > >> + >> for (p = pdc_name; *p; p++) { >> - if (*p == '.') { >> + /* Create the NetBIOS name from the first segment of the >> hostname */ >> + if ((*p == '.') || (*p == '\0')) { > The second check is redundant, you'll never get there, the for loop will > bail earlier. I think you only need to add the comment here and not > touch the code as the asprintf above took care of properly terminating > the name at the 15 chars mark already. > >> *p = '\0'; >> break; >> } > Simo. > Thanks for the catches. Updated patch attached. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0133-4-ipa-cldap-Cut-NetBIOS-name-after-15-characters.patch Type: text/x-patch Size: 2063 bytes Desc: not available URL: From tbabej at redhat.com Wed Dec 11 11:47:25 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Dec 2013 12:47:25 +0100 Subject: [Freeipa-devel] [PATCH] 0129 fix trust.get_dn to distinguish creating and re-adding trusts In-Reply-To: <20131205115111.GL21264@redhat.com> References: <20131205115111.GL21264@redhat.com> Message-ID: <52A850CD.2060406@redhat.com> On 12/05/2013 12:51 PM, Alexander Bokovoy wrote: > Latest support for subdomains introduced regression that masked > difference between newly added trust and re-added one. > > Additionally, in case no new subdomains were found, the code was > returning None instead of an empty list which later could confuse > trustdomain-find command. > > https://fedorahosted.org/freeipa/ticket/4067 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Dec 11 11:56:58 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Dec 2013 13:56:58 +0200 Subject: [Freeipa-devel] [PATCH 0133] ipa-cldap: Cut NetBIOS name after 15 characters In-Reply-To: <52A84360.1070404@redhat.com> References: <5294B21F.7@redhat.com> <20131126155643.GG21264@redhat.com> <52959CCF.8050108@redhat.com> <20131127072516.GJ21264@redhat.com> <5295A44F.3090704@redhat.com> <1385563097.22025.112.camel@willson.li.ssimo.org> <52A84360.1070404@redhat.com> Message-ID: <20131211115658.GW21264@redhat.com> On Wed, 11 Dec 2013, Tomas Babej wrote: > On 11/27/2013 03:38 PM, Simo Sorce wrote: >> On Wed, 2013-11-27 at 08:50 +0100, Tomas Babej wrote: >> Sorry to nitpick but ... >> >>> diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>> b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>> index >>> 7d29fe559be55607fcb6b83fa521372e5197b848..f2e74e2c5b6e0d04dd3dc0eb15f25593aa91da8e 100644 >>> --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>> +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>> @@ -161,9 +161,13 @@ static int ipa_cldap_encode_netlogon(char >>> *fq_hostname, char *domain, >>> nlr->dns_domain = domain; >>> nlr->pdc_dns_name = fq_hostname; >>> nlr->domain_name = name; >>> - pdc_name = talloc_asprintf(nlr, "\\\\%s", fq_hostname); >>> + >>> + /* copy the first 15 characters of the fully qualified hostname*/ >>> + pdc_name = talloc_asprintf(nlr, "\\\\%.*s", 15, fq_hostname); >> Probably better to #define NETBIOS_NAME_MAX 15 somewhere above and then >> use the macro here. >> >>> + >>> for (p = pdc_name; *p; p++) { >>> - if (*p == '.') { >>> + /* Create the NetBIOS name from the first segment of the >>> hostname */ >>> + if ((*p == '.') || (*p == '\0')) { >> The second check is redundant, you'll never get there, the for loop will >> bail earlier. I think you only need to add the comment here and not >> touch the code as the asprintf above took care of properly terminating >> the name at the 15 chars mark already. >> >>> *p = '\0'; >>> break; >>> } >> Simo. >> > > Thanks for the catches. > > Updated patch attached. ACK. -- / Alexander Bokovoy From mkosek at redhat.com Wed Dec 11 12:10:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Dec 2013 13:10:52 +0100 Subject: [Freeipa-devel] Troubleshooting FreeIPA In-Reply-To: <529F3CAF.9030404@redhat.com> References: <529F1BD8.3090405@redhat.com> <529F3CAF.9030404@redhat.com> Message-ID: <52A8564C.9000400@redhat.com> On 12/04/2013 03:31 PM, Dmitri Pal wrote: > On 12/04/2013 07:11 AM, Martin Kosek wrote: >> Hello all, >> >> I have started a Troubleshooting page which should help FreeIPA users >> troubleshoot and report bugs. The first attempt can be found here: >> >> http://www.freeipa.org/page/Troubleshooting >> >> This is mostly a brain dump of the most common issues I could think of. I would >> like to ask developers to help me extend it and add more information as it >> should help us a better portion of user issues before they even ask + if they >> ask, the page should help them attach the right data. >> >> Thanks in advance! >> > This is a good start. > I suggest we have a template section - a checklist that would help > people to prepare an email to the list. > Here is a proposed outline with example data: > > Distro/OS with version: Fedora 19 > Component: IPA server > Feature: Certificate management > Package version(s): ipa_..._3.0_..._.rpm > Problem description: Certificates are not renewed. > What I have tried: > Looked at X, here is output > Looked at Y, here is output > ... > Corresponding sanitized logs: > > ... > > ... > > Urgency: I found a workaround but it would be nice to get it fixed. > Recommendations: May be a message should be more clear like this "blah, > blah..." > > > Did I miss anything? Good idea, I would not enforce a strict template for issues reported in free form by mail, but we should specify all the information that we *expect* user to include. I wrote a list of required items (based on your template) which should be the core of the user's report: http://www.freeipa.org/page/Troubleshooting#Reporting_bugs Martin From jcholast at redhat.com Wed Dec 11 12:24:07 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Dec 2013 13:24:07 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1384457033.1822.51.camel@localhost.localdomain> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> Message-ID: <52A85967.1020601@redhat.com> On 14.11.2013 20:23, Nathaniel McCallum wrote: > On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote: >> On 8.10.2013 16:35, Nathaniel McCallum wrote: >>> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: >>>> >>>> +class Base32DecodeError(ExecutionError): >>>> >>>> Is this really necessary? Are we going to add DecodeError for >>>> every kind of new encoding in IPA? Can't we just have generic >>>> DecodeError? (This is not an issue in your patch per se, I'm just >>>> wondering if we can do it better in the framework.) >>> >>> I added the new error due to the existence of a Base64DecodeError. I >>> figured changing the existing error to be more generic would break api. >>> >>> Nathaniel >>> >> >> I think you can use ConversionError instead. I don't see any reason why >> base32/64 decoding errors should be special cased like this and would >> like to see Base64DecodeError gone. > > Fixed. > > Thanks. format = _("invalid '%(name)s': %(error)s") - class ValidationError(InvocationError): """ **3009** Raised when a parameter value fails a validation rule. @@ -1306,6 +1305,7 @@ class PosixGroupViolation(ExecutionError): errno = 4030 format = _('This is already a posix group and cannot be converted to external one') + class BuiltinError(ExecutionError): This white space shuffling is not necessary. +def _normalize_owner(userobj, entry_attrs): + if 'ipatokenowner' in entry_attrs: + entry_attrs['ipatokenowner'] = map(userobj.get_primary_key_from_dn, + entry_attrs['ipatokenowner']) If the --raw option is specified, ipatokenowner value should be full DN. + # Resolve the user's dn + owner = entry_attrs.get('ipatokenowner', None) + if owner is not None: + owner = self.api.Object.user.get_dn(owner) + entry_attrs['ipatokenowner'] = owner You have a _normalize_owner function, I think the code above should go into a _convert_owner function (use the function in otptoken_{mod,show,find} as well). + # Get the issuer for the URI + issuer = api.env.realm + if owner is not None: + try: + issuer = ldap.get_entry(owner, ['krbprincipalname'])['krbprincipalname'][0] + except: + pass Please use "except PublicError" here, we don't want internal errors to be ignored. + # Delete all tokens owned by this user + owner = self.api.Object.user.get_primary_key_from_dn(dn) + results = self.api.Command.otptoken_find(ipatokenowner=owner)['result'] + for token in results: + token = self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) + self.api.Command.otptoken_del(token) This should probably be handled by the referint plugin. Honza -- Jan Cholasta From mkosek at redhat.com Wed Dec 11 12:31:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Dec 2013 13:31:17 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52A85967.1020601@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> Message-ID: <52A85B15.2020906@redhat.com> On 12/11/2013 01:24 PM, Jan Cholasta wrote: > On 14.11.2013 20:23, Nathaniel McCallum wrote: >> On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote: >>> On 8.10.2013 16:35, Nathaniel McCallum wrote: >>>> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: >>>>> >>>>> +class Base32DecodeError(ExecutionError): >>>>> >>>>> Is this really necessary? Are we going to add DecodeError for >>>>> every kind of new encoding in IPA? Can't we just have generic >>>>> DecodeError? (This is not an issue in your patch per se, I'm just >>>>> wondering if we can do it better in the framework.) >>>> >>>> I added the new error due to the existence of a Base64DecodeError. I >>>> figured changing the existing error to be more generic would break api. >>>> >>>> Nathaniel >>>> >>> >>> I think you can use ConversionError instead. I don't see any reason why >>> base32/64 decoding errors should be special cased like this and would >>> like to see Base64DecodeError gone. >> >> Fixed. ... > + # Get the issuer for the URI > + issuer = api.env.realm > + if owner is not None: > + try: > + issuer = ldap.get_entry(owner, > ['krbprincipalname'])['krbprincipalname'][0] > + except: > + pass > > Please use "except PublicError" here, we don't want internal errors to be ignored. Right. I think what Nathaniel wanted to do is: except errors.NotFound: pass Bare except-pass is wrong on several levels anyway. For example it also catches syntax or interrupt exceptions. > > > + # Delete all tokens owned by this user > + owner = self.api.Object.user.get_primary_key_from_dn(dn) > + results = self.api.Command.otptoken_find(ipatokenowner=owner)['result'] > + for token in results: > + token = self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) > + self.api.Command.otptoken_del(token) > > This should probably be handled by the referint plugin. > > Honza > I think referint plugin would just remove the attribute containing DN to user, not the whole entry. I.e. I think Nathaniel need to do it this way anyway. Though I think it would be more efficient if we do just one 'otptoken_del' call with the list of tokens as primary key to it. All standard LDAPDelete based plugins can do that. You may also want to pass continue=True in the list of it's options in this case. Martin From mkosek at redhat.com Wed Dec 11 12:32:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Dec 2013 13:32:41 +0100 Subject: [Freeipa-devel] [PATCH 0133] ipa-cldap: Cut NetBIOS name after 15 characters In-Reply-To: <20131211115658.GW21264@redhat.com> References: <5294B21F.7@redhat.com> <20131126155643.GG21264@redhat.com> <52959CCF.8050108@redhat.com> <20131127072516.GJ21264@redhat.com> <5295A44F.3090704@redhat.com> <1385563097.22025.112.camel@willson.li.ssimo.org> <52A84360.1070404@redhat.com> <20131211115658.GW21264@redhat.com> Message-ID: <52A85B69.2000108@redhat.com> On 12/11/2013 12:56 PM, Alexander Bokovoy wrote: > On Wed, 11 Dec 2013, Tomas Babej wrote: >> On 11/27/2013 03:38 PM, Simo Sorce wrote: >>> On Wed, 2013-11-27 at 08:50 +0100, Tomas Babej wrote: >>> Sorry to nitpick but ... >>> >>>> diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>>> b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>>> index >>>> 7d29fe559be55607fcb6b83fa521372e5197b848..f2e74e2c5b6e0d04dd3dc0eb15f25593aa91da8e >>>> 100644 >>>> --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>>> +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c >>>> @@ -161,9 +161,13 @@ static int ipa_cldap_encode_netlogon(char >>>> *fq_hostname, char *domain, >>>> nlr->dns_domain = domain; >>>> nlr->pdc_dns_name = fq_hostname; >>>> nlr->domain_name = name; >>>> - pdc_name = talloc_asprintf(nlr, "\\\\%s", fq_hostname); >>>> + >>>> + /* copy the first 15 characters of the fully qualified hostname*/ >>>> + pdc_name = talloc_asprintf(nlr, "\\\\%.*s", 15, fq_hostname); >>> Probably better to #define NETBIOS_NAME_MAX 15 somewhere above and then >>> use the macro here. >>> >>>> + >>>> for (p = pdc_name; *p; p++) { >>>> - if (*p == '.') { >>>> + /* Create the NetBIOS name from the first segment of the >>>> hostname */ >>>> + if ((*p == '.') || (*p == '\0')) { >>> The second check is redundant, you'll never get there, the for loop will >>> bail earlier. I think you only need to add the comment here and not >>> touch the code as the asprintf above took care of properly terminating >>> the name at the 15 chars mark already. >>> >>>> *p = '\0'; >>>> break; >>>> } >>> Simo. >>> >> >> Thanks for the catches. >> >> Updated patch attached. > > ACK. > Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Wed Dec 11 12:35:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Dec 2013 13:35:03 +0100 Subject: [Freeipa-devel] [PATCH] 0129 fix trust.get_dn to distinguish creating and re-adding trusts In-Reply-To: <52A850CD.2060406@redhat.com> References: <20131205115111.GL21264@redhat.com> <52A850CD.2060406@redhat.com> Message-ID: <52A85BF7.9040106@redhat.com> On 12/11/2013 12:47 PM, Tomas Babej wrote: > On 12/05/2013 12:51 PM, Alexander Bokovoy wrote: >> Latest support for subdomains introduced regression that masked >> difference between newly added trust and re-added one. >> >> Additionally, in case no new subdomains were found, the code was >> returning None instead of an empty list which later could confuse >> trustdomain-find command. >> >> https://fedorahosted.org/freeipa/ticket/4067 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK. > Pushed to master, ipa-3-3. Martin From jcholast at redhat.com Wed Dec 11 12:51:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Dec 2013 13:51:54 +0100 Subject: [Freeipa-devel] [PATCHES] 0022-0023 [RFE] DNS - IDN support In-Reply-To: <1386337711.2274.25.camel@unused-4-145.brq.redhat.com> References: <1386337711.2274.25.camel@unused-4-145.brq.redhat.com> Message-ID: <52A85FEA.7090805@redhat.com> On 6.12.2013 14:48, Martin Basti wrote: > Hello, > > patches here contain a *draft* of IDN support for IPA DNS. > > Overview: > 1) IND domains stored in LDAP are punycoded(A-labels) > 2) now domain can contains almost everything > 3) domains have to be normalized (AD requires normalized domains too). > Example: gro? => gross > 4) --raw option shows domains punycoded > 5) without --raw option domains are showed in Unicode(U-labels, human > readable form) > 6) It works only in DNS module, rest of IPA is still without IDN > 7) IDN domains are not added into realmdomains > > TODO: > 1) bug in dnspython can cause improper conversion with escaped > characters: https://github.com/rthalley/dnspython/issues/46 > 2) discuss if validators should be more strict (only letters > allowed, ...) > 3) fix parts of code where domains are showed in punycode - error > messages, exceptions > 4) cleanup unused code > > TESTS: > 1) 3 failures: caused by TODO 3) > 2) expected value: 'value' should be in Unicode(U-labels), instead of > punycode (part of TODO 3) ) > I did a quick look at the patch and it is a little bit beefier than I would expect. Instead of doing excessive amounts of punycode encoding/decoding when a value is received from/about to be send to the client, I would instead encode right before LDAP add/mod and decode right after LDAP search. Honza -- Jan Cholasta From pviktori at redhat.com Wed Dec 11 16:05:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Dec 2013 17:05:25 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52A712BC.2090109@redhat.com> References: <52A712BC.2090109@redhat.com> Message-ID: <52A88D45.60706@redhat.com> On 12/10/2013 02:10 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza These look great, thanks! Just a couple of questions/nicpicks. 213: ACK 214: ACK 215: ACK 216: ACK 217: ACK 218: ACK 219: Does the new method guarantee 'attributetypes' are updated before 'objectclasses'? I can move the logic to schemaupdate if needed. Why is OnlyOneValueAllowed not raised any more? It should be, since the method assumes get_single_value() gives correct information. Why is MOD_REPLACE no longer used when no old values are retained? Or (MOD_DELETE, a, None) when the new set is empty? 220: ACK 221: An ancient comment in ldapupdate still has a reference to orig_data in, can you remove the comment as well? 222: ACK 223: ACK 224: ACK I noticed that IPASimpleLdapObject.convert_result's docstring is obsolete, could you update/shorten it? -- Petr? From pviktori at redhat.com Wed Dec 11 17:28:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Dec 2013 18:28:32 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52A88D45.60706@redhat.com> References: <52A712BC.2090109@redhat.com> <52A88D45.60706@redhat.com> Message-ID: <52A8A0C0.2050404@redhat.com> On 12/11/2013 05:05 PM, Petr Viktorin wrote: > On 12/10/2013 02:10 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza > > These look great, thanks! Just a couple of questions/nicpicks. > > 213: ACK > 214: ACK > 215: ACK > 216: ACK > 217: ACK > 218: ACK > > 219: > Does the new method guarantee 'attributetypes' are updated before > 'objectclasses'? > I can move the logic to schemaupdate if needed. > > Why is OnlyOneValueAllowed not raised any more? It should be, since the > method assumes get_single_value() gives correct information. > > Why is MOD_REPLACE no longer used when no old values are retained? Or > (MOD_DELETE, a, None) when the new set is empty? > > > 220: ACK > > 221: > An ancient comment in ldapupdate still has a reference to orig_data in, > can you remove the comment as well? > > 222: ACK > 223: ACK > 224: ACK I spoke too soon, NACK. This line: > -from ipaserver.plugins import ldap2 is important, please put it back. Without it api.Backend.ldap2 will not be available and upgrades will fail with AttributeError. (Yes, I know.) > I noticed that IPASimpleLdapObject.convert_result's docstring is > obsolete, could you update/shorten it? > -- Petr? From pspacek at redhat.com Thu Dec 12 09:43:22 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 Dec 2013 10:43:22 +0100 Subject: [Freeipa-devel] [PATCH 0182] Fix false error messages when nonexistent object/attribute is deleted In-Reply-To: <5252B511.9010207@redhat.com> References: <51FA674A.5020708@redhat.com> <5252B511.9010207@redhat.com> Message-ID: <52A9853A.1010506@redhat.com> On 7.10.2013 15:20, Tomas Hozza wrote: > On 08/01/2013 03:48 PM, Petr Spacek wrote: >> Hello, >> >> Fix false error messages when nonexistent object/attribute is deleted. >> >> >> This patch should go to branches v3 and master. >> > > ACK. > > Tested Patch bundle 181 - 185. Common tasks like > adding/deleting/updating records work fine. Also PTR sync, zone serial > number > incrementation is OK. No unexpected errors are printed. The described > scenario was fixed by this patch. > > > Regards, > > Tomas > I have found that this patch hides problems when deletion from LDAP failed because data in LDAP are not in 'canonical' form. See https://fedorahosted.org/bind-dyndb-ldap/ticket/12 for the details. I decided to drop this patch completely, it adds more problems than it solves. Luckily, the patch wasn't pushed so no change to Git repo is required. -- Petr^2 Spacek From pviktori at redhat.com Thu Dec 12 11:40:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Dec 2013 12:40:25 +0100 Subject: [Freeipa-devel] [PATCHES] [WIP] 0337-0343 YAML test configuration Message-ID: <52A9A0A9.9040706@redhat.com> Hello Tom??! I'm planning a little Christmas present for you. Instead of a surprise I'm Releasing early :) Apply patches or: git pull http://github.com/encukou/freeipa yaml-config These patches add YAML/JSON configuration for tests. YAML/JSON is completely optional, the existing envvar style continues to work. The ipa-test-config tool can convert between the two (which is not just for show, export will be needed for debugging and unit tests). If you choose to use YAML, you need PyYAML (python-yaml) installed. Example: $ MASTER=master.ipa.test REPLICA=repl.ipa.test TESTHOST_XYZ_env1=xyz.ipa.test BEAKERMASTER1_IP_env1=1.2.3.4 BEAKERREPLICA1_IP_env1=1.2.3.5 BEAKERXYZ1_IP_env1=1.2.3.6 ipa-test-config --global --yaml | tee /tmp/testconf.yaml ad_admin_name: Administrator ad_admin_password: Secret123 admin_name: admin admin_password: Secret123 debug: false dirman_dn: cn=Directory Manager dirman_password: Secret123 dns_forwarder: 8.8.8.8 domains: - hosts: master: external_hostname: master.ipa.test ip: 1.2.3.4 role: master repl: external_hostname: repl.ipa.test ip: 1.2.3.5 role: replica xyz: external_hostname: xyz.ipa.test ip: 1.2.3.6 role: xyz name: ipa.test type: IPA ipv6: false nis_domain: ipatest ntp_server: 2.pool.ntp.org root_password: null root_ssh_key_filename: ~/.ssh/id_rsa test_dir: /root/ipatests $ IPATEST_YAML_CONFIG=/tmp/testconf.yaml ipa-run-tests ... What's left is to update the design and write tests. I'll get to it eventually, but now I'll probably be busy for a few days. If you'd like to do them as part of review, tests could be in the format: from ipatests.test_integration import config conf = config.Config.from_env($environment) assert conf.to_dict() == {$result} conf = config.Config.from_dict($inputdict) assert conf.to_dict() == {$result} https://fedorahosted.org/freeipa/ticket/3938 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0337-test_integration.config-Fix-crash-in-to_env-when-no-.patch Type: text/x-patch Size: 2357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0338-test_integration.config-Do-not-save-the-input-enviro.patch Type: text/x-patch Size: 5025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0339-test_integration.config-Use-a-more-declarative-appro.patch Type: text/x-patch Size: 7278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0340-test_integration.config-Do-not-store-the-index-in-Do.patch Type: text/x-patch Size: 8584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0341-test_integration.config-Load-store-from-to-dicts.patch Type: text/x-patch Size: 6120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0342-test_integration.config-Add-environment-variables-fo.patch Type: text/x-patch Size: 1953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0343-ipa-test-config-Add-json-and-yaml-output-options.patch Type: text/x-patch Size: 3905 bytes Desc: not available URL: From mkosek at redhat.com Thu Dec 12 13:00:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Dec 2013 14:00:03 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <52A1ABD2.9040400@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> <52A1ABD2.9040400@redhat.com> Message-ID: <52A9B353.5010607@redhat.com> On 12/06/2013 11:49 AM, Petr Viktorin wrote: > On 12/02/2013 01:04 PM, Martin Kosek wrote: >> On 12/01/2013 11:46 PM, Petr Viktorin wrote: >>> This seems to work now. Please tell me what I missed. >>> >>> Design: http://www.freeipa.org/page/V3/Permissions_V2 >>> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >>> >>> >>> 0322 Allow sets for initialization of frozenset-typed Param keywords >>> because my OCD compels me to use sets instead of lists when the order does not >>> matter. >>> >>> >>> 0323 Allow Declarative test classes to specify the API version >>> For the next patch, I want to test how the rewrite handles old clients. To make >>> that easy I made the default API version a testclass attribute >>> >>> >>> 0324 Add tests for permission plugin with older clients >>> These tests will not pass yet, but comparing this file with the old >>> test_permission_plugin.py will can serve as a nice summary of API changes. A >>> summary of the summary: >>> - Lots of new attributes will be added for output >>> - The `type` and `subtree` options now interact in a different way: setting one >>> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >>> (Some change here was necessary for >>> https://fedorahosted.org/freeipa/ticket/2355) >>> - Validation will be stricter (and/or done in different order) >>> - Some error messages will change (hopefully for the better) >>> - `subtree` must now point to an existing entry >>> - Permission names may now contain '.' (this is to allow names of DNS >>> permissions that were previously internal) >>> >>> P.S. a handy command for listing the changes (once this patch is applied): >>> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >>> ipatests/test_xmlrpc/test_old_permission_plugin.py >>> >>> >>> 0325 Add new permission schema >>> Introducing the new OIDs >>> >>> >>> 0326 Rewrite the Permission plugin >>> See the design for what this does. >>> >>> The new permission plugin does not use aci plugin at all. The plan is to retire >>> the aci plugin when the time comes to also refactor delegation & selfservice. >>> It does use ipalib's ACI class, mainly for parsing (needed for >>> upgrading/showing old ACIs). >>> >>> The permission-find command is a bit faster than the old one, but still >>> painfully slow (5s instead of 7s on my box). The good news is that it now >>> scales with the number of *old* permissions, so as you upgrade it'll get >>> faster. >>> >>> Tests are updated, including privilege and DNS tests that worked with >>> permissions. >>> >>> >>> 0327 Verify ACIs are added correctly in tests >>> Right after saying I want to get rid of it, I found a new use for the aci >>> plugin: an tested code path for getting at ACIs (Declaratrive tests can only >>> use the API, they don't play well with LDAP connections). >>> Now we can be sure the ACIs are actually changed when we play with permissions. >>> >> >> Great job! >> >> I read through the code and did few tests, this is what I've found so far: >> >> 1) When I tried to move ACI to non-existent DN, I got a general error + the >> underlying ACI was gone: >> >> # ipa permission-mod "Write Group Description" --subtree=foo=bar >> ipa: ERROR: no such entry >> >> >> When I then tried to delete it, I got Internal Error: >> # ipa permission-del "Write Group Description" >> ipa: ERROR: an internal error has occurred >> >> ... >> /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in >> pre_callback >> [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] >> self.obj.remove_aci(entry) >> [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in >> remove_aci >> [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] >> self._replace_aci(permission_entry) >> [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in >> _replace_aci >> [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn >> # pylint: disable=E1103 >> [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' >> object has no attribute 'dn' >> >> I think we should add a check for that + at least try to rollback if we fail to >> move the ACI. > > Fixed. I did in in 2 additional patches for clarity: > - 0331 adds rollback > - 0332 adds the check (you can test the rollback without this applied) > >> 2) In filter check: >> >> + # Rough filter validation by a search >> + if self.env.in_server and 'ipapermtargetfilter' in options: >> + ldap = self.Backend.ldap2 >> + try: >> + ldap.find_entries( >> + filter=options['ipapermtargetfilter'], >> + base_dn=self.env.basedn, >> + size_limit=0) >> >> This is great for starters, but I would make it less costly and only search >> with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches >> across whole database. > > Agreed, fixed. > >> 3) I see that I can add ALL bind type permission as a member to a privilege: >> >> # ipa permission-show "Write Group Description 2" >> Permission name: Write Group Description 2 >> Permissions: write >> Attributes: description >> Bind rule type: all >> Subtree: cn=groups,cn=accounts,dc=example,dc=com >> ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com >> Type: group >> >> # ipa privilege-add-permission foo --permissions "Write Group Description 2" >> Privilege name: foo >> Description: foo >> Permissions: write group description 2 >> ----------------------------- >> Number of permissions added 1 >> ----------------------------- >> >> Is this a bug or do you already plan to fix it later? > > Yes, I plan to fix that soon (#4032). > I've modified the patch to allow "permission" only. I'll re-introduce the > others when I add the necessary checks. > >> 4) Typo in refactored permission plugin: >> >> + errors.NotFound('ACI of to permission %s was not found' % >> + keys[0]) > > Fixed, thanks for the catch! > 1) 0352.2: I think that ipaPermTargetFilter and ipaPermTarget should be SINGLE-VALUE'd as well 2) More about the schema, I think we should move the attributes that permission plugin always depends on to MUST list, I think this should affect: * ipapermright * ipapermbindruletype I was pondering about ipapermallowedattr, but ACI works without it well, it is just NOOP. Other attributes are just different combinations of targetting the entries to protect, so they may stay MAY. 3)326.2: shouldn't + StrEnum( + 'ipapermright*', + cli_name='permissions', rather read 'ipapermright+'? This is what I get if I omit the permissions: # ipa permission-add foo --attrs=description --type group ipa: ERROR: an internal error has occurred Same with update and other attributes: # ipa permission-mod foo3 --permissions '' ipa: ERROR: an internal error has occurred # ipa permission-mod foo3 --memberof='' ipa: ERROR: an internal error has occurred The later one is only reproducible if there is not memberof part set. 4) Internall error when entering blank subtree # ipa permission-add foo3 --permissions write --subtree '' ipa: ERROR: an internal error has occurred 5) Internal error when entering non-blank subtree and nothing else: # ipa permission-add foo3 --permissions write --subtree 'cn=otp,dc=example,dc=com' ipa: ERROR: an internal error has occurred [Thu Dec 12 13:18:04.635874 2013] [:error] [pid 17259] raise SyntaxError, "target must be a non-empty dictionary" It seems this case should translate into error "there should be at least one target entry specifier". 6) permission-find gives 0 results when searching in the default DN and it was not explicitly set: # ipa permission-find --subtree dc=example,dc=com --------------------- 0 permissions matched --------------------- ---------------------------- Number of entries returned 0 ---------------------------- 7) Web UI list of permissions returns weird results (just 2 of my new testing permissions). This is what it calls: [Thu Dec 12 13:41:01.473157 2013] [:error] [pid 17258] ipa: INFO: [jsonserver_session] admin at IDM.LAB.ENG.BRQ.REDHAT.COM: permission_find(u'', sizelimit=0, pkey_only=True): SUCCESS But as I see, Web UI is broken in many other aspects, so it needs to be adapted to the new output. As I do not want to stop development of the server framework part (there is a lot to do) it can be done in other patches after yours are merged, so that we have at least the server part in. We just need to fix it before 3.4 release. This is all I found in the second round of review, these are mostly corner cases, the core of the patch set seems to be nice. Martin From tbabej at redhat.com Thu Dec 12 14:02:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Dec 2013 15:02:57 +0100 Subject: [Freeipa-devel] [PATCH 0135] Fix incorrect path in error message on sysrestore failure Message-ID: <52A9C211.6090600@redhat.com> Hi, On sysrestore failure, user is prompted out to remove the sysrestore file. However, the path to the sysrestore file mentioned in the sentence is not correct. https://fedorahosted.org/freeipa/ticket/4080 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0135-Fix-incorrect-path-in-error-message-on-sysrestore-fa.patch Type: text/x-patch Size: 1642 bytes Desc: not available URL: From tbabej at redhat.com Thu Dec 12 15:55:54 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Dec 2013 16:55:54 +0100 Subject: [Freeipa-devel] [PATCH 0136] Remove enumeration index from dynamic role hosts when Message-ID: <52A9DC8A.7040903@redhat.com> Hi, When exporting test configuration, do not append indexes to dynamic role definitions as this is not expected form of input. https://fedorahosted.org/freeipa/ticket/4081 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0136-Remove-enumeration-index-from-dynamic-role-hosts-whe.patch Type: text/x-patch Size: 1287 bytes Desc: not available URL: From pviktori at redhat.com Thu Dec 12 16:17:24 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Dec 2013 17:17:24 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <52A9B353.5010607@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> <52A1ABD2.9040400@redhat.com> <52A9B353.5010607@redhat.com> Message-ID: <52A9E194.3030603@redhat.com> On 12/12/2013 02:00 PM, Martin Kosek wrote: > On 12/06/2013 11:49 AM, Petr Viktorin wrote: >> On 12/02/2013 01:04 PM, Martin Kosek wrote: >>> On 12/01/2013 11:46 PM, Petr Viktorin wrote: >>>> This seems to work now. Please tell me what I missed. >>>> >>>> Design: http://www.freeipa.org/page/V3/Permissions_V2 >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >>>> >>>> >>>> 0322 Allow sets for initialization of frozenset-typed Param keywords >>>> because my OCD compels me to use sets instead of lists when the order does not >>>> matter. >>>> >>>> >>>> 0323 Allow Declarative test classes to specify the API version >>>> For the next patch, I want to test how the rewrite handles old clients. To make >>>> that easy I made the default API version a testclass attribute >>>> >>>> >>>> 0324 Add tests for permission plugin with older clients >>>> These tests will not pass yet, but comparing this file with the old >>>> test_permission_plugin.py will can serve as a nice summary of API changes. A >>>> summary of the summary: >>>> - Lots of new attributes will be added for output >>>> - The `type` and `subtree` options now interact in a different way: setting one >>>> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >>>> (Some change here was necessary for >>>> https://fedorahosted.org/freeipa/ticket/2355) >>>> - Validation will be stricter (and/or done in different order) >>>> - Some error messages will change (hopefully for the better) >>>> - `subtree` must now point to an existing entry >>>> - Permission names may now contain '.' (this is to allow names of DNS >>>> permissions that were previously internal) >>>> >>>> P.S. a handy command for listing the changes (once this patch is applied): >>>> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >>>> ipatests/test_xmlrpc/test_old_permission_plugin.py >>>> >>>> >>>> 0325 Add new permission schema >>>> Introducing the new OIDs >>>> >>>> >>>> 0326 Rewrite the Permission plugin >>>> See the design for what this does. >>>> >>>> The new permission plugin does not use aci plugin at all. The plan is to retire >>>> the aci plugin when the time comes to also refactor delegation & selfservice. >>>> It does use ipalib's ACI class, mainly for parsing (needed for >>>> upgrading/showing old ACIs). >>>> >>>> The permission-find command is a bit faster than the old one, but still >>>> painfully slow (5s instead of 7s on my box). The good news is that it now >>>> scales with the number of *old* permissions, so as you upgrade it'll get >>>> faster. >>>> >>>> Tests are updated, including privilege and DNS tests that worked with >>>> permissions. >>>> >>>> >>>> 0327 Verify ACIs are added correctly in tests >>>> Right after saying I want to get rid of it, I found a new use for the aci >>>> plugin: an tested code path for getting at ACIs (Declaratrive tests can only >>>> use the API, they don't play well with LDAP connections). >>>> Now we can be sure the ACIs are actually changed when we play with permissions. >>>> >>> >>> Great job! >>> >>> I read through the code and did few tests, this is what I've found so far: >>> >>> 1) When I tried to move ACI to non-existent DN, I got a general error + the >>> underlying ACI was gone: >>> >>> # ipa permission-mod "Write Group Description" --subtree=foo=bar >>> ipa: ERROR: no such entry >>> >>> >>> When I then tried to delete it, I got Internal Error: >>> # ipa permission-del "Write Group Description" >>> ipa: ERROR: an internal error has occurred >>> >>> ... >>> /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in >>> pre_callback >>> [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] >>> self.obj.remove_aci(entry) >>> [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in >>> remove_aci >>> [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] >>> self._replace_aci(permission_entry) >>> [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in >>> _replace_aci >>> [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn >>> # pylint: disable=E1103 >>> [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' >>> object has no attribute 'dn' >>> >>> I think we should add a check for that + at least try to rollback if we fail to >>> move the ACI. >> >> Fixed. I did in in 2 additional patches for clarity: >> - 0331 adds rollback >> - 0332 adds the check (you can test the rollback without this applied) >> >>> 2) In filter check: >>> >>> + # Rough filter validation by a search >>> + if self.env.in_server and 'ipapermtargetfilter' in options: >>> + ldap = self.Backend.ldap2 >>> + try: >>> + ldap.find_entries( >>> + filter=options['ipapermtargetfilter'], >>> + base_dn=self.env.basedn, >>> + size_limit=0) >>> >>> This is great for starters, but I would make it less costly and only search >>> with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches >>> across whole database. >> >> Agreed, fixed. >> >>> 3) I see that I can add ALL bind type permission as a member to a privilege: >>> >>> # ipa permission-show "Write Group Description 2" >>> Permission name: Write Group Description 2 >>> Permissions: write >>> Attributes: description >>> Bind rule type: all >>> Subtree: cn=groups,cn=accounts,dc=example,dc=com >>> ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com >>> Type: group >>> >>> # ipa privilege-add-permission foo --permissions "Write Group Description 2" >>> Privilege name: foo >>> Description: foo >>> Permissions: write group description 2 >>> ----------------------------- >>> Number of permissions added 1 >>> ----------------------------- >>> >>> Is this a bug or do you already plan to fix it later? >> >> Yes, I plan to fix that soon (#4032). >> I've modified the patch to allow "permission" only. I'll re-introduce the >> others when I add the necessary checks. >> >>> 4) Typo in refactored permission plugin: >>> >>> + errors.NotFound('ACI of to permission %s was not found' % >>> + keys[0]) >> >> Fixed, thanks for the catch! >> > > > 1) 0352.2: I think that ipaPermTargetFilter and ipaPermTarget should be > SINGLE-VALUE'd as well Thanks, changed. > 2) More about the schema, I think we should move the attributes that permission > plugin always depends on to MUST list, I think this should affect: > * ipapermright > * ipapermbindruletype OK. This means that SYSTEM permissions stay without the new objectclass, which means removing most options from permission_add_noaci. > I was pondering about ipapermallowedattr, but ACI works without it well, it is > just NOOP. Other attributes are just different combinations of targetting the > entries to protect, so they may stay MAY. Optional ipapermallowedattr will be required for managed permissions. Also, add/delete permissions could be specified without an attr filter. > 3)326.2: shouldn't > > + StrEnum( > + 'ipapermright*', > + cli_name='permissions', > > rather read 'ipapermright+'? This is what I get if I omit the permissions: > > # ipa permission-add foo --attrs=description --type group > ipa: ERROR: an internal error has occurred > > Same with update and other attributes: > # ipa permission-mod foo3 --permissions '' > ipa: ERROR: an internal error has occurred > > # ipa permission-mod foo3 --memberof='' > ipa: ERROR: an internal error has occurred > > The later one is only reproducible if there is not memberof part set. Unfortunately it can't be required because it can be specified by a different name via the old API. But, it is now checked. > 4) Internall error when entering blank subtree > # ipa permission-add foo3 --permissions write --subtree '' > ipa: ERROR: an internal error has occurred > > 5) Internal error when entering non-blank subtree and nothing else: > > # ipa permission-add foo3 --permissions write --subtree 'cn=otp,dc=example,dc=com' > ipa: ERROR: an internal error has occurred > > [Thu Dec 12 13:18:04.635874 2013] [:error] [pid 17259] raise SyntaxError, > "target must be a non-empty dictionary" > > It seems this case should translate into error "there should be at least one > target entry specifier". > > 6) permission-find gives 0 results when searching in the default DN and it was > not explicitly set: > > # ipa permission-find --subtree dc=example,dc=com > --------------------- > 0 permissions matched > --------------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- 4-6: Thanks for the catches, fixed & added to tests. > 7) Web UI list of permissions returns weird results (just 2 of my new testing > permissions). This is what it calls: > > [Thu Dec 12 13:41:01.473157 2013] [:error] [pid 17258] ipa: INFO: > [jsonserver_session] admin at IDM.LAB.ENG.BRQ.REDHAT.COM: permission_find(u'', > sizelimit=0, pkey_only=True): SUCCESS > > But as I see, Web UI is broken in many other aspects, so it needs to be adapted > to the new output. As I do not want to stop development of the server framework > part (there is a lot to do) it can be done in other patches after yours are > merged, so that we have at least the server part in. We just need to fix it > before 3.4 release. Right. Here's a ticket for it: https://fedorahosted.org/freeipa/ticket/4079 > This is all I found in the second round of review, these are mostly corner > cases, the core of the patch set seems to be nice. > > Martin > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0322.3-Allow-sets-for-initialization-of-frozenset-typed-Par.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0323.3-Allow-Declarative-test-classes-to-specify-the-API-ve.patch Type: text/x-patch Size: 1268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0324.3-Add-tests-for-permission-plugin-with-older-clients.patch Type: text/x-patch Size: 44831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0325.3-Add-new-permission-schema.patch Type: text/x-patch Size: 4397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0326.3-Rewrite-the-Permission-plugin.patch Type: text/x-patch Size: 142665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0327.3-Verify-ACIs-are-added-correctly-in-tests.patch Type: text/x-patch Size: 20621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0331.3-Roll-back-ACI-changes-on-failed-permission-updates.patch Type: text/x-patch Size: 10122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0332.3-permission-plugin-Ensure-ipapermlocation-subtree-alw.patch Type: text/x-patch Size: 3013 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 07:49:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 08:49:14 +0100 Subject: [Freeipa-devel] [PATCH 0135] Fix incorrect path in error message on sysrestore failure In-Reply-To: <52A9C211.6090600@redhat.com> References: <52A9C211.6090600@redhat.com> Message-ID: <52AABBFA.7030903@redhat.com> On 12.12.2013 15:02, Tomas Babej wrote: > On sysrestore failure, user is prompted out to remove the sysrestore > file. However, the path to the sysrestore file mentioned in the > sentence is not correct. > > https://fedorahosted.org/freeipa/ticket/4080 > > -- > Tomas Babej > > > freeipa-tbabej-0135-Fix-incorrect-path-in-error-message-on-sysrestore-fa.patch > > > From eac993e153c243b6359f57a7c051d3f373a9add0 Mon Sep 17 00:00:00 2001 > From: Tomas Babej > Date: Thu, 12 Dec 2013 15:01:14 +0100 > Subject: [PATCH] Fix incorrect path in error message on sysrestore failure > > On sysrestore failure, user is prompted out to remove the sysrestore > file. However, the path to the sysrestore file mentioned in the > sentence is not correct. > > https://fedorahosted.org/freeipa/ticket/4080 > --- > install/tools/ipa-server-install | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install > index 458ebba550d0fe7675bd874e23c7d730c53297e6..718fcee45550b9f65a17ecddc599fb4489f7ab3c 100755 > --- a/install/tools/ipa-server-install > +++ b/install/tools/ipa-server-install > @@ -534,7 +534,10 @@ def uninstall(): > rv = 1 > > if has_state: > - root_logger.error('Some installation state has not been restored.\nThis may cause re-installation to fail.\nIt should be safe to remove /var/lib/ipa/sysrestore.state but it may\nmean your system hasn\'t be restored to its pre-installation state.') > + root_logger.error('Some installation state has not been restored.\n' > + 'This may cause re-installation to fail.\n' > + 'It should be safe to remove /var/lib/ipa/sysrestore/sysrestore.state but it may\n' (I know that this is bold ...) NACK. A path used in the error message should be extracted/shared with the code. It will prevent inconsistencies like this in the future. Petr^2 Spacek > + 'mean your system hasn\'t be restored to its pre-installation state.') > > # Note that this name will be wrong after the first uninstall. > dirname = dsinstance.config_dirname(dsinstance.realm_to_serverid(api.env.realm)) From pvoborni at redhat.com Fri Dec 13 08:20:56 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Dec 2013 09:20:56 +0100 Subject: [Freeipa-devel] [PATCH] 531 Increase stack size for Web UI builder Message-ID: <52AAC368.8050102@redhat.com> Web UI build fails on some architectures or configuration due to StackOverflow. This patch increases the stack size to solve it. 512k is usually enough but we encountered fail on ppc64 even with 2m, therefore the 8m. The build is single threaded so it shouldn't waste much memory. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-Increase-stack-size-for-Web-UI-builder.patch Type: text/x-patch Size: 2159 bytes Desc: not available URL: From abokovoy at redhat.com Fri Dec 13 09:28:59 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Dec 2013 11:28:59 +0200 Subject: [Freeipa-devel] [PATCH] 531 Increase stack size for Web UI builder In-Reply-To: <52AAC368.8050102@redhat.com> References: <52AAC368.8050102@redhat.com> Message-ID: <20131213092859.GA21264@redhat.com> On Fri, 13 Dec 2013, Petr Vobornik wrote: >Web UI build fails on some architectures or configuration due to >StackOverflow. This patch increases the stack size to solve it. > >512k is usually enough but we encountered fail on ppc64 even with 2m, >therefore the 8m. The build is single threaded so it shouldn't waste >much memory. >-- >Petr Vobornik >From 9eeb52abaa6a53bb3304f96dd17d0b1f74083b50 Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Wed, 31 Jul 2013 15:12:19 +0200 >Subject: [PATCH] Increase stack size for Web UI builder > >Web UI build fails on some architectures or configuration due to >StackOverflow. This patch increases the stack size to solve it. > >512k is usually enough but we encountered fail on ppc64 even with 2m, >therefore the 8m. The build is single threaded so it shouldn't waste >much memory. >--- > install/ui/util/build.sh | 5 +++-- > install/ui/util/uglifyjs/uglify | 9 +++++---- > 2 files changed, 8 insertions(+), 6 deletions(-) > >diff --git a/install/ui/util/build.sh b/install/ui/util/build.sh >index 7cd623485a8a87872e29d32f529bd77a45d59810..9495e119bac123645e41aeb2b304d7d399a3fd96 100755 >--- a/install/ui/util/build.sh >+++ b/install/ui/util/build.sh >@@ -31,5 +31,6 @@ if [[ ! $profile ]] ; then > exit 1 > fi > >-rhino $DIR/build/build.js baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js >-exit $? >\ No newline at end of file >+RHINO="java -Xss8m -classpath /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >+$RHINO $DIR/build/build.js baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js >+exit $? >diff --git a/install/ui/util/uglifyjs/uglify b/install/ui/util/uglifyjs/uglify >index 7d25b38df19e465227f29b8b70ccf7ca140f725a..fb46275b868f60f5f92175ee070d98737b5d7c89 100755 >--- a/install/ui/util/uglifyjs/uglify >+++ b/install/ui/util/uglifyjs/uglify >@@ -25,8 +25,9 @@ DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > > # rhino-1.7R4 doesn't have -main option to enable CommonJS support. It was > # replaced by -require option. >-if [ `rhino --help | grep -e -require | wc -l` -gt 0 ] ; then >- rhino -require $DIR/uglify-js.js $@ >+RHINO="java -Xss8m -classpath /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >+if [ `$RHINO --help | grep -e -require | wc -l` -gt 0 ] ; then >+ $RHINO -require $DIR/uglify-js.js $@ > else >- rhino -main $DIR/uglify-js.js $DIR/ug.js $@ >-fi >\ No newline at end of file >+ $RHINO -main $DIR/uglify-js.js $DIR/ug.js $@ >+fi I'd prefer to get the value from some environmental variable within build and uglify scripts and default to some expected value if that is missing. Then we can put default value in top Makefile and easily override it from the spec if needed. Makefile: ... JAVA_STACK_SIZE ?= 8m ... build.sh: RHINO="java -Xss${JAVA_STACK_SIZE:-512k} ..." uglify: RHINO="java -Xss${JAVA_STACK_SIZE:-512k} ..." then if some platform gets it broken, we can redefine JAVA_STACK_SIZE in the specfile to any value without touching the code. -- / Alexander Bokovoy From pviktori at redhat.com Fri Dec 13 09:45:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Dec 2013 10:45:10 +0100 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson (Was: FreeIPA 3.3."latest" failing tests: config_mod) In-Reply-To: <5284EFDF.4060702@redhat.com> References: <5284EFDF.4060702@redhat.com> Message-ID: <52AAD726.2030105@redhat.com> I finally got to investigating this failure. It seems ou, along with a bunch of other attributes, is missing from organizationalPerson in Fedora 20. I don't think it's IPA's fault, as we don't define organizationalPerson. Nathan, could it be related to the new schema parser? f19 has: objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) X-ORIGIN 'RFC 4519' ) f20 has: objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier ) X-ORIGIN 'RFC 4519' ) On 11/14/2013 04:44 PM, Petr Spacek wrote: > Hello, > > latest FreeIPA build from branch ipa-3-3 (built today on Fedora 20, > latest bits) fails following tests: > > ====================================================================== > ERROR: test_config[0]: config_mod: Try to add an unrelated objectclass > to ipauserobjectclasses > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in > > func = lambda: self.check(nice, **test) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 340, in > check_output > got = api.Command[cmd](*args, **options) > File "/tmp/git/ipalib/frontend.py", line 436, in __call__ > ret = self.run(*args, **options) > File "/tmp/git/ipalib/frontend.py", line 761, in run > return self.forward(*args, **options) > File "/tmp/git/ipalib/frontend.py", line 782, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/tmp/git/ipalib/rpc.py", line 712, in forward > raise error(message=e.faultString) > ValidationError: invalid 'ipauserobjectclasses': user default attribute > ou would not be allowed! > > ====================================================================== > ERROR: test_config[1]: config_mod: Remove the unrelated objectclass from > ipauserobjectclasses > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in > > func = lambda: self.check(nice, **test) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 340, in > check_output > got = api.Command[cmd](*args, **options) > File "/tmp/git/ipalib/frontend.py", line 436, in __call__ > ret = self.run(*args, **options) > File "/tmp/git/ipalib/frontend.py", line 761, in run > return self.forward(*args, **options) > File "/tmp/git/ipalib/frontend.py", line 782, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/tmp/git/ipalib/rpc.py", line 712, in forward > raise error(message=e.faultString) > AttrValueNotFound: ipauserobjectclasses does not contain 'ipahost' > > ---------------------------------------------------------------------- > Ran 10 tests in 1.233s > > FAILED (errors=2) > ====================================================================== > FAILED under '/usr/bin/python2.7' > > > Other tests from ipatests/test_xmlrpc/test_config_plugin.py are okay. > -- Petr? From mkosek at redhat.com Fri Dec 13 09:49:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Dec 2013 10:49:32 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <52A9E194.3030603@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> <52A1ABD2.9040400@redhat.com> <52A9B353.5010607@redhat.com> <52A9E194.3030603@redhat.com> Message-ID: <52AAD82C.2000602@redhat.com> On 12/12/2013 05:17 PM, Petr Viktorin wrote: > On 12/12/2013 02:00 PM, Martin Kosek wrote: >> On 12/06/2013 11:49 AM, Petr Viktorin wrote: >>> On 12/02/2013 01:04 PM, Martin Kosek wrote: >>>> On 12/01/2013 11:46 PM, Petr Viktorin wrote: >>>>> This seems to work now. Please tell me what I missed. >>>>> >>>>> Design: http://www.freeipa.org/page/V3/Permissions_V2 >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >>>>> >>>>> >>>>> 0322 Allow sets for initialization of frozenset-typed Param keywords >>>>> because my OCD compels me to use sets instead of lists when the order does >>>>> not >>>>> matter. >>>>> >>>>> >>>>> 0323 Allow Declarative test classes to specify the API version >>>>> For the next patch, I want to test how the rewrite handles old clients. To >>>>> make >>>>> that easy I made the default API version a testclass attribute >>>>> >>>>> >>>>> 0324 Add tests for permission plugin with older clients >>>>> These tests will not pass yet, but comparing this file with the old >>>>> test_permission_plugin.py will can serve as a nice summary of API changes. A >>>>> summary of the summary: >>>>> - Lots of new attributes will be added for output >>>>> - The `type` and `subtree` options now interact in a different way: >>>>> setting one >>>>> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >>>>> (Some change here was necessary for >>>>> https://fedorahosted.org/freeipa/ticket/2355) >>>>> - Validation will be stricter (and/or done in different order) >>>>> - Some error messages will change (hopefully for the better) >>>>> - `subtree` must now point to an existing entry >>>>> - Permission names may now contain '.' (this is to allow names of DNS >>>>> permissions that were previously internal) >>>>> >>>>> P.S. a handy command for listing the changes (once this patch is applied): >>>>> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >>>>> ipatests/test_xmlrpc/test_old_permission_plugin.py >>>>> >>>>> >>>>> 0325 Add new permission schema >>>>> Introducing the new OIDs >>>>> >>>>> >>>>> 0326 Rewrite the Permission plugin >>>>> See the design for what this does. >>>>> >>>>> The new permission plugin does not use aci plugin at all. The plan is to >>>>> retire >>>>> the aci plugin when the time comes to also refactor delegation & selfservice. >>>>> It does use ipalib's ACI class, mainly for parsing (needed for >>>>> upgrading/showing old ACIs). >>>>> >>>>> The permission-find command is a bit faster than the old one, but still >>>>> painfully slow (5s instead of 7s on my box). The good news is that it now >>>>> scales with the number of *old* permissions, so as you upgrade it'll get >>>>> faster. >>>>> >>>>> Tests are updated, including privilege and DNS tests that worked with >>>>> permissions. >>>>> >>>>> >>>>> 0327 Verify ACIs are added correctly in tests >>>>> Right after saying I want to get rid of it, I found a new use for the aci >>>>> plugin: an tested code path for getting at ACIs (Declaratrive tests can only >>>>> use the API, they don't play well with LDAP connections). >>>>> Now we can be sure the ACIs are actually changed when we play with >>>>> permissions. >>>>> >>>> >>>> Great job! >>>> >>>> I read through the code and did few tests, this is what I've found so far: >>>> >>>> 1) When I tried to move ACI to non-existent DN, I got a general error + the >>>> underlying ACI was gone: >>>> >>>> # ipa permission-mod "Write Group Description" --subtree=foo=bar >>>> ipa: ERROR: no such entry >>>> >>>> >>>> When I then tried to delete it, I got Internal Error: >>>> # ipa permission-del "Write Group Description" >>>> ipa: ERROR: an internal error has occurred >>>> >>>> ... >>>> /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in >>>> pre_callback >>>> [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] >>>> self.obj.remove_aci(entry) >>>> [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in >>>> remove_aci >>>> [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] >>>> self._replace_aci(permission_entry) >>>> [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in >>>> _replace_aci >>>> [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn >>>> # pylint: disable=E1103 >>>> [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' >>>> object has no attribute 'dn' >>>> >>>> I think we should add a check for that + at least try to rollback if we >>>> fail to >>>> move the ACI. >>> >>> Fixed. I did in in 2 additional patches for clarity: >>> - 0331 adds rollback >>> - 0332 adds the check (you can test the rollback without this applied) >>> >>>> 2) In filter check: >>>> >>>> + # Rough filter validation by a search >>>> + if self.env.in_server and 'ipapermtargetfilter' in options: >>>> + ldap = self.Backend.ldap2 >>>> + try: >>>> + ldap.find_entries( >>>> + filter=options['ipapermtargetfilter'], >>>> + base_dn=self.env.basedn, >>>> + size_limit=0) >>>> >>>> This is great for starters, but I would make it less costly and only search >>>> with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches >>>> across whole database. >>> >>> Agreed, fixed. >>> >>>> 3) I see that I can add ALL bind type permission as a member to a privilege: >>>> >>>> # ipa permission-show "Write Group Description 2" >>>> Permission name: Write Group Description 2 >>>> Permissions: write >>>> Attributes: description >>>> Bind rule type: all >>>> Subtree: cn=groups,cn=accounts,dc=example,dc=com >>>> ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com >>>> Type: group >>>> >>>> # ipa privilege-add-permission foo --permissions "Write Group Description 2" >>>> Privilege name: foo >>>> Description: foo >>>> Permissions: write group description 2 >>>> ----------------------------- >>>> Number of permissions added 1 >>>> ----------------------------- >>>> >>>> Is this a bug or do you already plan to fix it later? >>> >>> Yes, I plan to fix that soon (#4032). >>> I've modified the patch to allow "permission" only. I'll re-introduce the >>> others when I add the necessary checks. >>> >>>> 4) Typo in refactored permission plugin: >>>> >>>> + errors.NotFound('ACI of to permission %s was not found' % >>>> + keys[0]) >>> >>> Fixed, thanks for the catch! >>> >> >> >> 1) 0352.2: I think that ipaPermTargetFilter and ipaPermTarget should be >> SINGLE-VALUE'd as well > > Thanks, changed. > >> 2) More about the schema, I think we should move the attributes that permission >> plugin always depends on to MUST list, I think this should affect: >> * ipapermright >> * ipapermbindruletype > > OK. This means that SYSTEM permissions stay without the new objectclass, which > means removing most options from permission_add_noaci. > >> I was pondering about ipapermallowedattr, but ACI works without it well, it is >> just NOOP. Other attributes are just different combinations of targetting the >> entries to protect, so they may stay MAY. > > Optional ipapermallowedattr will be required for managed permissions. Also, > add/delete permissions could be specified without an attr filter. > >> 3)326.2: shouldn't >> >> + StrEnum( >> + 'ipapermright*', >> + cli_name='permissions', >> >> rather read 'ipapermright+'? This is what I get if I omit the permissions: >> >> # ipa permission-add foo --attrs=description --type group >> ipa: ERROR: an internal error has occurred >> >> Same with update and other attributes: >> # ipa permission-mod foo3 --permissions '' >> ipa: ERROR: an internal error has occurred >> >> # ipa permission-mod foo3 --memberof='' >> ipa: ERROR: an internal error has occurred >> >> The later one is only reproducible if there is not memberof part set. > > Unfortunately it can't be required because it can be specified by a different > name via the old API. But, it is now checked. > >> 4) Internall error when entering blank subtree >> # ipa permission-add foo3 --permissions write --subtree '' >> ipa: ERROR: an internal error has occurred >> >> 5) Internal error when entering non-blank subtree and nothing else: >> >> # ipa permission-add foo3 --permissions write --subtree >> 'cn=otp,dc=example,dc=com' >> ipa: ERROR: an internal error has occurred >> >> [Thu Dec 12 13:18:04.635874 2013] [:error] [pid 17259] raise SyntaxError, >> "target must be a non-empty dictionary" >> >> It seems this case should translate into error "there should be at least one >> target entry specifier". >> >> 6) permission-find gives 0 results when searching in the default DN and it was >> not explicitly set: >> >> # ipa permission-find --subtree dc=example,dc=com >> --------------------- >> 0 permissions matched >> --------------------- >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- > > 4-6: Thanks for the catches, fixed & added to tests. > >> 7) Web UI list of permissions returns weird results (just 2 of my new testing >> permissions). This is what it calls: >> >> [Thu Dec 12 13:41:01.473157 2013] [:error] [pid 17258] ipa: INFO: >> [jsonserver_session] admin at IDM.LAB.ENG.BRQ.REDHAT.COM: permission_find(u'', >> sizelimit=0, pkey_only=True): SUCCESS >> >> But as I see, Web UI is broken in many other aspects, so it needs to be adapted >> to the new output. As I do not want to stop development of the server framework >> part (there is a lot to do) it can be done in other patches after yours are >> merged, so that we have at least the server part in. We just need to fix it >> before 3.4 release. > > Right. Here's a ticket for it: https://fedorahosted.org/freeipa/ticket/4079 > >> This is all I found in the second round of review, these are mostly corner >> cases, the core of the patch set seems to be nice. >> >> Martin >> > > Looks better, this is hopefully the last issue: 1) There is some problem with DNS zone permissions: # ipa dnszone-add-permission example.com ----------------------------------------------------- Added system permission "Manage DNS zone example.com" ----------------------------------------------------- # ipa permission-show 'Manage DNS zone example.com' --all --raw ipa: ERROR: The ACI for permission Manage DNS zone example.com was not found in dc=idm,dc=example,dc=com # ipa privilege-add-permission foo --permissions foo Privilege name: foo Description: foo Failed members: permission: foo: missing attribute "ipaPermLocation" required by object class "ipaPermissionV2" ----------------------------- Number of permissions added 0 ----------------------------- Martin From pvoborni at redhat.com Fri Dec 13 12:13:17 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Dec 2013 13:13:17 +0100 Subject: [Freeipa-devel] [PATCH] 531 Increase stack size for Web UI builder In-Reply-To: <20131213092859.GA21264@redhat.com> References: <52AAC368.8050102@redhat.com> <20131213092859.GA21264@redhat.com> Message-ID: <52AAF9DD.4090507@redhat.com> On 12/13/2013 10:28 AM, Alexander Bokovoy wrote: > On Fri, 13 Dec 2013, Petr Vobornik wrote: >> Web UI build fails on some architectures or configuration due to >> StackOverflow. This patch increases the stack size to solve it. >> >> 512k is usually enough but we encountered fail on ppc64 even with 2m, >> therefore the 8m. The build is single threaded so it shouldn't waste >> much memory. >> -- >> Petr Vobornik > >> From 9eeb52abaa6a53bb3304f96dd17d0b1f74083b50 Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Wed, 31 Jul 2013 15:12:19 +0200 >> Subject: [PATCH] Increase stack size for Web UI builder >> >> Web UI build fails on some architectures or configuration due to >> StackOverflow. This patch increases the stack size to solve it. >> >> 512k is usually enough but we encountered fail on ppc64 even with 2m, >> therefore the 8m. The build is single threaded so it shouldn't waste >> much memory. >> --- >> install/ui/util/build.sh | 5 +++-- >> install/ui/util/uglifyjs/uglify | 9 +++++---- >> 2 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/install/ui/util/build.sh b/install/ui/util/build.sh >> index >> 7cd623485a8a87872e29d32f529bd77a45d59810..9495e119bac123645e41aeb2b304d7d399a3fd96 >> 100755 >> --- a/install/ui/util/build.sh >> +++ b/install/ui/util/build.sh >> @@ -31,5 +31,6 @@ if [[ ! $profile ]] ; then >> exit 1 >> fi >> >> -rhino $DIR/build/build.js baseUrl=$DIR/build load=build >> profile=$DIR/../src/$profile.profile.js >> -exit $? >> \ No newline at end of file >> +RHINO="java -Xss8m -classpath /usr/share/java/rhino.jar >> org.mozilla.javascript.tools.shell.Main" >> +$RHINO $DIR/build/build.js baseUrl=$DIR/build load=build >> profile=$DIR/../src/$profile.profile.js >> +exit $? >> diff --git a/install/ui/util/uglifyjs/uglify >> b/install/ui/util/uglifyjs/uglify >> index >> 7d25b38df19e465227f29b8b70ccf7ca140f725a..fb46275b868f60f5f92175ee070d98737b5d7c89 >> 100755 >> --- a/install/ui/util/uglifyjs/uglify >> +++ b/install/ui/util/uglifyjs/uglify >> @@ -25,8 +25,9 @@ DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" >> >> # rhino-1.7R4 doesn't have -main option to enable CommonJS support. It >> was >> # replaced by -require option. >> -if [ `rhino --help | grep -e -require | wc -l` -gt 0 ] ; then >> - rhino -require $DIR/uglify-js.js $@ >> +RHINO="java -Xss8m -classpath /usr/share/java/rhino.jar >> org.mozilla.javascript.tools.shell.Main" >> +if [ `$RHINO --help | grep -e -require | wc -l` -gt 0 ] ; then >> + $RHINO -require $DIR/uglify-js.js $@ >> else >> - rhino -main $DIR/uglify-js.js $DIR/ug.js $@ >> -fi >> \ No newline at end of file >> + $RHINO -main $DIR/uglify-js.js $DIR/ug.js $@ >> +fi > I'd prefer to get the value from some environmental variable within > build and uglify scripts and default to some expected value if that is > missing. > Then we can put default value in top Makefile and easily override it > from the spec if needed. > > Makefile: > ... > JAVA_STACK_SIZE ?= 8m > ... > > build.sh: > RHINO="java -Xss${JAVA_STACK_SIZE:-512k} ..." > > uglify: > RHINO="java -Xss${JAVA_STACK_SIZE:-512k} ..." > > > then if some platform gets it broken, we can redefine JAVA_STACK_SIZE in > the specfile to any value without touching the code. > Fixed -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-1-Increase-stack-size-for-Web-UI-builder.patch Type: text/x-patch Size: 2964 bytes Desc: not available URL: From abokovoy at redhat.com Fri Dec 13 12:18:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Dec 2013 14:18:34 +0200 Subject: [Freeipa-devel] [PATCH] 531 Increase stack size for Web UI builder In-Reply-To: <52AAF9DD.4090507@redhat.com> References: <52AAC368.8050102@redhat.com> <20131213092859.GA21264@redhat.com> <52AAF9DD.4090507@redhat.com> Message-ID: <20131213121834.GD21264@redhat.com> On Fri, 13 Dec 2013, Petr Vobornik wrote: >Web UI build fails on some architectures or configuration due to >StackOverflow. This patch increases the stack size to solve it. > >512k is usually enough but we encountered fail on ppc64 even with 2m, >therefore the 8m. The build is single threaded so it shouldn't waste >much memory. >--- > Makefile | 5 +++++ > install/ui/util/build.sh | 5 +++-- > install/ui/util/uglifyjs/uglify | 9 +++++---- > 3 files changed, 13 insertions(+), 6 deletions(-) > >diff --git a/Makefile b/Makefile >index a7226341e6bd10106309997aae558fc07239482d..e54f8f0ba6484a12343f389b3cffbc20d7420a5f 100644 >--- a/Makefile >+++ b/Makefile >@@ -55,6 +55,11 @@ PYTHON ?= $(shell rpm -E %__python || echo /usr/bin/python) > CFLAGS := -g -O2 -Werror -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers $(CFLAGS) > export CFLAGS > >+# Uncomment to increase Java stack size for Web UI build in case it fails >+# because of stack overflow exception. Default should be OK for most platforms. >+#JAVA_STACK_SIZE ?= 8m >+#export JAVA_STACK_SIZE >+ > all: bootstrap-autogen server tests > @for subdir in $(SUBDIRS); do \ > (cd $$subdir && $(MAKE) $@) || exit 1; \ >diff --git a/install/ui/util/build.sh b/install/ui/util/build.sh >index 7cd623485a8a87872e29d32f529bd77a45d59810..03776c1fe54f750cf028981bce625702af32aa1d 100755 >--- a/install/ui/util/build.sh >+++ b/install/ui/util/build.sh >@@ -31,5 +31,6 @@ if [[ ! $profile ]] ; then > exit 1 > fi > >-rhino $DIR/build/build.js baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js >-exit $? >\ No newline at end of file >+RHINO="java -Xss${JAVA_STACK_SIZE:-512k} -classpath /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >+$RHINO $DIR/build/build.js baseUrl=$DIR/build load=build profile=$DIR/../src/$profile.profile.js >+exit $? >diff --git a/install/ui/util/uglifyjs/uglify b/install/ui/util/uglifyjs/uglify >index 7d25b38df19e465227f29b8b70ccf7ca140f725a..1227f589b4c50de49c465f6c696ecdc8af5e3c91 100755 >--- a/install/ui/util/uglifyjs/uglify >+++ b/install/ui/util/uglifyjs/uglify >@@ -25,8 +25,9 @@ DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > > # rhino-1.7R4 doesn't have -main option to enable CommonJS support. It was > # replaced by -require option. >-if [ `rhino --help | grep -e -require | wc -l` -gt 0 ] ; then >- rhino -require $DIR/uglify-js.js $@ >+RHINO="java -Xss${JAVA_STACK_SIZE:-512k} -classpath /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >+if [ `$RHINO --help | grep -e -require | wc -l` -gt 0 ] ; then >+ $RHINO -require $DIR/uglify-js.js $@ > else >- rhino -main $DIR/uglify-js.js $DIR/ug.js $@ >-fi >\ No newline at end of file >+ $RHINO -main $DIR/uglify-js.js $DIR/ug.js $@ >+fi ACK. -- / Alexander Bokovoy From pviktori at redhat.com Fri Dec 13 12:35:11 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Dec 2013 13:35:11 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <52AAD82C.2000602@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> <52A1ABD2.9040400@redhat.com> <52A9B353.5010607@redhat.com> <52A9E194.3030603@redhat.com> <52AAD82C.2000602@redhat.com> Message-ID: <52AAFEFF.4090007@redhat.com> On 12/13/2013 10:49 AM, Martin Kosek wrote: > On 12/12/2013 05:17 PM, Petr Viktorin wrote: >> On 12/12/2013 02:00 PM, Martin Kosek wrote: >>> On 12/06/2013 11:49 AM, Petr Viktorin wrote: >>>> On 12/02/2013 01:04 PM, Martin Kosek wrote: >>>>> On 12/01/2013 11:46 PM, Petr Viktorin wrote: >>>>>> This seems to work now. Please tell me what I missed. >>>>>> >>>>>> Design: http://www.freeipa.org/page/V3/Permissions_V2 >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >>>>>> >>>>>> >>>>>> 0322 Allow sets for initialization of frozenset-typed Param keywords >>>>>> because my OCD compels me to use sets instead of lists when the order does >>>>>> not >>>>>> matter. >>>>>> >>>>>> >>>>>> 0323 Allow Declarative test classes to specify the API version >>>>>> For the next patch, I want to test how the rewrite handles old clients. To >>>>>> make >>>>>> that easy I made the default API version a testclass attribute >>>>>> >>>>>> >>>>>> 0324 Add tests for permission plugin with older clients >>>>>> These tests will not pass yet, but comparing this file with the old >>>>>> test_permission_plugin.py will can serve as a nice summary of API changes. A >>>>>> summary of the summary: >>>>>> - Lots of new attributes will be added for output >>>>>> - The `type` and `subtree` options now interact in a different way: >>>>>> setting one >>>>>> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >>>>>> (Some change here was necessary for >>>>>> https://fedorahosted.org/freeipa/ticket/2355) >>>>>> - Validation will be stricter (and/or done in different order) >>>>>> - Some error messages will change (hopefully for the better) >>>>>> - `subtree` must now point to an existing entry >>>>>> - Permission names may now contain '.' (this is to allow names of DNS >>>>>> permissions that were previously internal) >>>>>> >>>>>> P.S. a handy command for listing the changes (once this patch is applied): >>>>>> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >>>>>> ipatests/test_xmlrpc/test_old_permission_plugin.py >>>>>> >>>>>> >>>>>> 0325 Add new permission schema >>>>>> Introducing the new OIDs >>>>>> >>>>>> >>>>>> 0326 Rewrite the Permission plugin >>>>>> See the design for what this does. >>>>>> >>>>>> The new permission plugin does not use aci plugin at all. The plan is to >>>>>> retire >>>>>> the aci plugin when the time comes to also refactor delegation & selfservice. >>>>>> It does use ipalib's ACI class, mainly for parsing (needed for >>>>>> upgrading/showing old ACIs). >>>>>> >>>>>> The permission-find command is a bit faster than the old one, but still >>>>>> painfully slow (5s instead of 7s on my box). The good news is that it now >>>>>> scales with the number of *old* permissions, so as you upgrade it'll get >>>>>> faster. >>>>>> >>>>>> Tests are updated, including privilege and DNS tests that worked with >>>>>> permissions. >>>>>> >>>>>> >>>>>> 0327 Verify ACIs are added correctly in tests >>>>>> Right after saying I want to get rid of it, I found a new use for the aci >>>>>> plugin: an tested code path for getting at ACIs (Declaratrive tests can only >>>>>> use the API, they don't play well with LDAP connections). >>>>>> Now we can be sure the ACIs are actually changed when we play with >>>>>> permissions. >>>>>> >>>>> >>>>> Great job! >>>>> >>>>> I read through the code and did few tests, this is what I've found so far: >>>>> >>>>> 1) When I tried to move ACI to non-existent DN, I got a general error + the >>>>> underlying ACI was gone: >>>>> >>>>> # ipa permission-mod "Write Group Description" --subtree=foo=bar >>>>> ipa: ERROR: no such entry >>>>> >>>>> >>>>> When I then tried to delete it, I got Internal Error: >>>>> # ipa permission-del "Write Group Description" >>>>> ipa: ERROR: an internal error has occurred >>>>> >>>>> ... >>>>> /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in >>>>> pre_callback >>>>> [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] >>>>> self.obj.remove_aci(entry) >>>>> [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 374, in >>>>> remove_aci >>>>> [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] >>>>> self._replace_aci(permission_entry) >>>>> [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line 392, in >>>>> _replace_aci >>>>> [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = acientry.dn >>>>> # pylint: disable=E1103 >>>>> [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: 'dict' >>>>> object has no attribute 'dn' >>>>> >>>>> I think we should add a check for that + at least try to rollback if we >>>>> fail to >>>>> move the ACI. >>>> >>>> Fixed. I did in in 2 additional patches for clarity: >>>> - 0331 adds rollback >>>> - 0332 adds the check (you can test the rollback without this applied) >>>> >>>>> 2) In filter check: >>>>> >>>>> + # Rough filter validation by a search >>>>> + if self.env.in_server and 'ipapermtargetfilter' in options: >>>>> + ldap = self.Backend.ldap2 >>>>> + try: >>>>> + ldap.find_entries( >>>>> + filter=options['ipapermtargetfilter'], >>>>> + base_dn=self.env.basedn, >>>>> + size_limit=0) >>>>> >>>>> This is great for starters, but I would make it less costly and only search >>>>> with BASE scope and sizelimit==1 to avoid costly, possibly unindexed searches >>>>> across whole database. >>>> >>>> Agreed, fixed. >>>> >>>>> 3) I see that I can add ALL bind type permission as a member to a privilege: >>>>> >>>>> # ipa permission-show "Write Group Description 2" >>>>> Permission name: Write Group Description 2 >>>>> Permissions: write >>>>> Attributes: description >>>>> Bind rule type: all >>>>> Subtree: cn=groups,cn=accounts,dc=example,dc=com >>>>> ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com >>>>> Type: group >>>>> >>>>> # ipa privilege-add-permission foo --permissions "Write Group Description 2" >>>>> Privilege name: foo >>>>> Description: foo >>>>> Permissions: write group description 2 >>>>> ----------------------------- >>>>> Number of permissions added 1 >>>>> ----------------------------- >>>>> >>>>> Is this a bug or do you already plan to fix it later? >>>> >>>> Yes, I plan to fix that soon (#4032). >>>> I've modified the patch to allow "permission" only. I'll re-introduce the >>>> others when I add the necessary checks. >>>> >>>>> 4) Typo in refactored permission plugin: >>>>> >>>>> + errors.NotFound('ACI of to permission %s was not found' % >>>>> + keys[0]) >>>> >>>> Fixed, thanks for the catch! >>>> >>> >>> >>> 1) 0352.2: I think that ipaPermTargetFilter and ipaPermTarget should be >>> SINGLE-VALUE'd as well >> >> Thanks, changed. >> >>> 2) More about the schema, I think we should move the attributes that permission >>> plugin always depends on to MUST list, I think this should affect: >>> * ipapermright >>> * ipapermbindruletype >> >> OK. This means that SYSTEM permissions stay without the new objectclass, which >> means removing most options from permission_add_noaci. >> >>> I was pondering about ipapermallowedattr, but ACI works without it well, it is >>> just NOOP. Other attributes are just different combinations of targetting the >>> entries to protect, so they may stay MAY. >> >> Optional ipapermallowedattr will be required for managed permissions. Also, >> add/delete permissions could be specified without an attr filter. >> >>> 3)326.2: shouldn't >>> >>> + StrEnum( >>> + 'ipapermright*', >>> + cli_name='permissions', >>> >>> rather read 'ipapermright+'? This is what I get if I omit the permissions: >>> >>> # ipa permission-add foo --attrs=description --type group >>> ipa: ERROR: an internal error has occurred >>> >>> Same with update and other attributes: >>> # ipa permission-mod foo3 --permissions '' >>> ipa: ERROR: an internal error has occurred >>> >>> # ipa permission-mod foo3 --memberof='' >>> ipa: ERROR: an internal error has occurred >>> >>> The later one is only reproducible if there is not memberof part set. >> >> Unfortunately it can't be required because it can be specified by a different >> name via the old API. But, it is now checked. >> >>> 4) Internall error when entering blank subtree >>> # ipa permission-add foo3 --permissions write --subtree '' >>> ipa: ERROR: an internal error has occurred >>> >>> 5) Internal error when entering non-blank subtree and nothing else: >>> >>> # ipa permission-add foo3 --permissions write --subtree >>> 'cn=otp,dc=example,dc=com' >>> ipa: ERROR: an internal error has occurred >>> >>> [Thu Dec 12 13:18:04.635874 2013] [:error] [pid 17259] raise SyntaxError, >>> "target must be a non-empty dictionary" >>> >>> It seems this case should translate into error "there should be at least one >>> target entry specifier". >>> >>> 6) permission-find gives 0 results when searching in the default DN and it was >>> not explicitly set: >>> >>> # ipa permission-find --subtree dc=example,dc=com >>> --------------------- >>> 0 permissions matched >>> --------------------- >>> ---------------------------- >>> Number of entries returned 0 >>> ---------------------------- >> >> 4-6: Thanks for the catches, fixed & added to tests. >> >>> 7) Web UI list of permissions returns weird results (just 2 of my new testing >>> permissions). This is what it calls: >>> >>> [Thu Dec 12 13:41:01.473157 2013] [:error] [pid 17258] ipa: INFO: >>> [jsonserver_session] admin at IDM.LAB.ENG.BRQ.REDHAT.COM: permission_find(u'', >>> sizelimit=0, pkey_only=True): SUCCESS >>> >>> But as I see, Web UI is broken in many other aspects, so it needs to be adapted >>> to the new output. As I do not want to stop development of the server framework >>> part (there is a lot to do) it can be done in other patches after yours are >>> merged, so that we have at least the server part in. We just need to fix it >>> before 3.4 release. >> >> Right. Here's a ticket for it: https://fedorahosted.org/freeipa/ticket/4079 >> >>> This is all I found in the second round of review, these are mostly corner >>> cases, the core of the patch set seems to be nice. >>> >>> Martin >>> >> >> > > Looks better, this is hopefully the last issue: > > 1) There is some problem with DNS zone permissions: > > # ipa dnszone-add-permission example.com > ----------------------------------------------------- > Added system permission "Manage DNS zone example.com" > ----------------------------------------------------- > > # ipa permission-show 'Manage DNS zone example.com' --all --raw > ipa: ERROR: The ACI for permission Manage DNS zone example.com was not found in > dc=idm,dc=example,dc=com Thanks for the catch. Fixed in an additional patch. > # ipa privilege-add-permission foo --permissions foo > Privilege name: foo > Description: foo > Failed members: > permission: foo: missing attribute "ipaPermLocation" required by object > class "ipaPermissionV2" > ----------------------------- > Number of permissions added 0 > ----------------------------- Could not reproduce. This one used a permission created by the previous set of patches, where ipaPermLocation was not set when it was $SUFFIX. This is incompatible with the new schema. From the last update ipaPermLocation is in MUST, and is always added. I did write some additional tests before I asked Martin to explain this, so I'm also including these. Apply these on top of the patches sent earlier. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0435.3-Make-sure-SYSTEM-permissions-can-be-retreived-with-a.patch Type: text/x-patch Size: 3121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0436.3-Test-adding-noaci-system-permissions-to-privileges.patch Type: text/x-patch Size: 2774 bytes Desc: not available URL: From mkosek at redhat.com Fri Dec 13 14:13:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Dec 2013 15:13:28 +0100 Subject: [Freeipa-devel] [PATCHES] 0322-0327 New permissions system In-Reply-To: <52AAFEFF.4090007@redhat.com> References: <529BBC56.6080103@redhat.com> <529C7740.7090601@redhat.com> <52A1ABD2.9040400@redhat.com> <52A9B353.5010607@redhat.com> <52A9E194.3030603@redhat.com> <52AAD82C.2000602@redhat.com> <52AAFEFF.4090007@redhat.com> Message-ID: <52AB1608.1030107@redhat.com> On 12/13/2013 01:35 PM, Petr Viktorin wrote: > On 12/13/2013 10:49 AM, Martin Kosek wrote: >> On 12/12/2013 05:17 PM, Petr Viktorin wrote: >>> On 12/12/2013 02:00 PM, Martin Kosek wrote: >>>> On 12/06/2013 11:49 AM, Petr Viktorin wrote: >>>>> On 12/02/2013 01:04 PM, Martin Kosek wrote: >>>>>> On 12/01/2013 11:46 PM, Petr Viktorin wrote: >>>>>>> This seems to work now. Please tell me what I missed. >>>>>>> >>>>>>> Design: http://www.freeipa.org/page/V3/Permissions_V2 >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4034 >>>>>>> >>>>>>> >>>>>>> 0322 Allow sets for initialization of frozenset-typed Param keywords >>>>>>> because my OCD compels me to use sets instead of lists when the order does >>>>>>> not >>>>>>> matter. >>>>>>> >>>>>>> >>>>>>> 0323 Allow Declarative test classes to specify the API version >>>>>>> For the next patch, I want to test how the rewrite handles old clients. To >>>>>>> make >>>>>>> that easy I made the default API version a testclass attribute >>>>>>> >>>>>>> >>>>>>> 0324 Add tests for permission plugin with older clients >>>>>>> These tests will not pass yet, but comparing this file with the old >>>>>>> test_permission_plugin.py will can serve as a nice summary of API >>>>>>> changes. A >>>>>>> summary of the summary: >>>>>>> - Lots of new attributes will be added for output >>>>>>> - The `type` and `subtree` options now interact in a different way: >>>>>>> setting one >>>>>>> affects the other. Same with `type`/`filter` and `memberof`/`targetfilter`. >>>>>>> (Some change here was necessary for >>>>>>> https://fedorahosted.org/freeipa/ticket/2355) >>>>>>> - Validation will be stricter (and/or done in different order) >>>>>>> - Some error messages will change (hopefully for the better) >>>>>>> - `subtree` must now point to an existing entry >>>>>>> - Permission names may now contain '.' (this is to allow names of DNS >>>>>>> permissions that were previously internal) >>>>>>> >>>>>>> P.S. a handy command for listing the changes (once this patch is applied): >>>>>>> git diff ipa-3-3:ipatests/test_xmlrpc/test_permission_plugin.py >>>>>>> ipatests/test_xmlrpc/test_old_permission_plugin.py >>>>>>> >>>>>>> >>>>>>> 0325 Add new permission schema >>>>>>> Introducing the new OIDs >>>>>>> >>>>>>> >>>>>>> 0326 Rewrite the Permission plugin >>>>>>> See the design for what this does. >>>>>>> >>>>>>> The new permission plugin does not use aci plugin at all. The plan is to >>>>>>> retire >>>>>>> the aci plugin when the time comes to also refactor delegation & >>>>>>> selfservice. >>>>>>> It does use ipalib's ACI class, mainly for parsing (needed for >>>>>>> upgrading/showing old ACIs). >>>>>>> >>>>>>> The permission-find command is a bit faster than the old one, but still >>>>>>> painfully slow (5s instead of 7s on my box). The good news is that it now >>>>>>> scales with the number of *old* permissions, so as you upgrade it'll get >>>>>>> faster. >>>>>>> >>>>>>> Tests are updated, including privilege and DNS tests that worked with >>>>>>> permissions. >>>>>>> >>>>>>> >>>>>>> 0327 Verify ACIs are added correctly in tests >>>>>>> Right after saying I want to get rid of it, I found a new use for the aci >>>>>>> plugin: an tested code path for getting at ACIs (Declaratrive tests can >>>>>>> only >>>>>>> use the API, they don't play well with LDAP connections). >>>>>>> Now we can be sure the ACIs are actually changed when we play with >>>>>>> permissions. >>>>>>> >>>>>> >>>>>> Great job! >>>>>> >>>>>> I read through the code and did few tests, this is what I've found so far: >>>>>> >>>>>> 1) When I tried to move ACI to non-existent DN, I got a general error + the >>>>>> underlying ACI was gone: >>>>>> >>>>>> # ipa permission-mod "Write Group Description" --subtree=foo=bar >>>>>> ipa: ERROR: no such entry >>>>>> >>>>>> >>>>>> When I then tried to delete it, I got Internal Error: >>>>>> # ipa permission-del "Write Group Description" >>>>>> ipa: ERROR: an internal error has occurred >>>>>> >>>>>> ... >>>>>> /python2.7/site-packages/ipalib/plugins/permission.py", line 681, in >>>>>> pre_callback >>>>>> [Mon Dec 02 10:49:11.972422 2013] [:error] [pid 14181] >>>>>> self.obj.remove_aci(entry) >>>>>> [Mon Dec 02 10:49:11.972426 2013] [:error] [pid 14181] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line >>>>>> 374, in >>>>>> remove_aci >>>>>> [Mon Dec 02 10:49:11.972430 2013] [:error] [pid 14181] >>>>>> self._replace_aci(permission_entry) >>>>>> [Mon Dec 02 10:49:11.972434 2013] [:error] [pid 14181] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py", line >>>>>> 392, in >>>>>> _replace_aci >>>>>> [Mon Dec 02 10:49:11.972438 2013] [:error] [pid 14181] acidn = >>>>>> acientry.dn >>>>>> # pylint: disable=E1103 >>>>>> [Mon Dec 02 10:49:11.972441 2013] [:error] [pid 14181] AttributeError: >>>>>> 'dict' >>>>>> object has no attribute 'dn' >>>>>> >>>>>> I think we should add a check for that + at least try to rollback if we >>>>>> fail to >>>>>> move the ACI. >>>>> >>>>> Fixed. I did in in 2 additional patches for clarity: >>>>> - 0331 adds rollback >>>>> - 0332 adds the check (you can test the rollback without this applied) >>>>> >>>>>> 2) In filter check: >>>>>> >>>>>> + # Rough filter validation by a search >>>>>> + if self.env.in_server and 'ipapermtargetfilter' in options: >>>>>> + ldap = self.Backend.ldap2 >>>>>> + try: >>>>>> + ldap.find_entries( >>>>>> + filter=options['ipapermtargetfilter'], >>>>>> + base_dn=self.env.basedn, >>>>>> + size_limit=0) >>>>>> >>>>>> This is great for starters, but I would make it less costly and only search >>>>>> with BASE scope and sizelimit==1 to avoid costly, possibly unindexed >>>>>> searches >>>>>> across whole database. >>>>> >>>>> Agreed, fixed. >>>>> >>>>>> 3) I see that I can add ALL bind type permission as a member to a privilege: >>>>>> >>>>>> # ipa permission-show "Write Group Description 2" >>>>>> Permission name: Write Group Description 2 >>>>>> Permissions: write >>>>>> Attributes: description >>>>>> Bind rule type: all >>>>>> Subtree: cn=groups,cn=accounts,dc=example,dc=com >>>>>> ACI target DN: cn=*,cn=groups,cn=accounts,dc=example,dc=com >>>>>> Type: group >>>>>> >>>>>> # ipa privilege-add-permission foo --permissions "Write Group Description 2" >>>>>> Privilege name: foo >>>>>> Description: foo >>>>>> Permissions: write group description 2 >>>>>> ----------------------------- >>>>>> Number of permissions added 1 >>>>>> ----------------------------- >>>>>> >>>>>> Is this a bug or do you already plan to fix it later? >>>>> >>>>> Yes, I plan to fix that soon (#4032). >>>>> I've modified the patch to allow "permission" only. I'll re-introduce the >>>>> others when I add the necessary checks. >>>>> >>>>>> 4) Typo in refactored permission plugin: >>>>>> >>>>>> + errors.NotFound('ACI of to permission %s was not found' % >>>>>> + keys[0]) >>>>> >>>>> Fixed, thanks for the catch! >>>>> >>>> >>>> >>>> 1) 0352.2: I think that ipaPermTargetFilter and ipaPermTarget should be >>>> SINGLE-VALUE'd as well >>> >>> Thanks, changed. >>> >>>> 2) More about the schema, I think we should move the attributes that >>>> permission >>>> plugin always depends on to MUST list, I think this should affect: >>>> * ipapermright >>>> * ipapermbindruletype >>> >>> OK. This means that SYSTEM permissions stay without the new objectclass, which >>> means removing most options from permission_add_noaci. >>> >>>> I was pondering about ipapermallowedattr, but ACI works without it well, it is >>>> just NOOP. Other attributes are just different combinations of targetting the >>>> entries to protect, so they may stay MAY. >>> >>> Optional ipapermallowedattr will be required for managed permissions. Also, >>> add/delete permissions could be specified without an attr filter. >>> >>>> 3)326.2: shouldn't >>>> >>>> + StrEnum( >>>> + 'ipapermright*', >>>> + cli_name='permissions', >>>> >>>> rather read 'ipapermright+'? This is what I get if I omit the permissions: >>>> >>>> # ipa permission-add foo --attrs=description --type group >>>> ipa: ERROR: an internal error has occurred >>>> >>>> Same with update and other attributes: >>>> # ipa permission-mod foo3 --permissions '' >>>> ipa: ERROR: an internal error has occurred >>>> >>>> # ipa permission-mod foo3 --memberof='' >>>> ipa: ERROR: an internal error has occurred >>>> >>>> The later one is only reproducible if there is not memberof part set. >>> >>> Unfortunately it can't be required because it can be specified by a different >>> name via the old API. But, it is now checked. >>> >>>> 4) Internall error when entering blank subtree >>>> # ipa permission-add foo3 --permissions write --subtree '' >>>> ipa: ERROR: an internal error has occurred >>>> >>>> 5) Internal error when entering non-blank subtree and nothing else: >>>> >>>> # ipa permission-add foo3 --permissions write --subtree >>>> 'cn=otp,dc=example,dc=com' >>>> ipa: ERROR: an internal error has occurred >>>> >>>> [Thu Dec 12 13:18:04.635874 2013] [:error] [pid 17259] raise SyntaxError, >>>> "target must be a non-empty dictionary" >>>> >>>> It seems this case should translate into error "there should be at least one >>>> target entry specifier". >>>> >>>> 6) permission-find gives 0 results when searching in the default DN and it was >>>> not explicitly set: >>>> >>>> # ipa permission-find --subtree dc=example,dc=com >>>> --------------------- >>>> 0 permissions matched >>>> --------------------- >>>> ---------------------------- >>>> Number of entries returned 0 >>>> ---------------------------- >>> >>> 4-6: Thanks for the catches, fixed & added to tests. >>> >>>> 7) Web UI list of permissions returns weird results (just 2 of my new testing >>>> permissions). This is what it calls: >>>> >>>> [Thu Dec 12 13:41:01.473157 2013] [:error] [pid 17258] ipa: INFO: >>>> [jsonserver_session] admin at IDM.LAB.ENG.BRQ.REDHAT.COM: permission_find(u'', >>>> sizelimit=0, pkey_only=True): SUCCESS >>>> >>>> But as I see, Web UI is broken in many other aspects, so it needs to be >>>> adapted >>>> to the new output. As I do not want to stop development of the server >>>> framework >>>> part (there is a lot to do) it can be done in other patches after yours are >>>> merged, so that we have at least the server part in. We just need to fix it >>>> before 3.4 release. >>> >>> Right. Here's a ticket for it: https://fedorahosted.org/freeipa/ticket/4079 >>> >>>> This is all I found in the second round of review, these are mostly corner >>>> cases, the core of the patch set seems to be nice. >>>> >>>> Martin >>>> >>> >>> >> >> Looks better, this is hopefully the last issue: >> >> 1) There is some problem with DNS zone permissions: >> >> # ipa dnszone-add-permission example.com >> ----------------------------------------------------- >> Added system permission "Manage DNS zone example.com" >> ----------------------------------------------------- >> >> # ipa permission-show 'Manage DNS zone example.com' --all --raw >> ipa: ERROR: The ACI for permission Manage DNS zone example.com was not found in >> dc=idm,dc=example,dc=com > > Thanks for the catch. Fixed in an additional patch. > >> # ipa privilege-add-permission foo --permissions foo >> Privilege name: foo >> Description: foo >> Failed members: >> permission: foo: missing attribute "ipaPermLocation" required by object >> class "ipaPermissionV2" >> ----------------------------- >> Number of permissions added 0 >> ----------------------------- > > Could not reproduce. This one used a permission created by the previous set of > patches, where ipaPermLocation was not set when it was $SUFFIX. This is > incompatible with the new schema. From the last update ipaPermLocation is in > MUST, and is always added. > I did write some additional tests before I asked Martin to explain this, so I'm > also including these. > > Apply these on top of the patches sent earlier. > Works nice. That wraps up this part of your permission system refactoring, ACK for that! Pushed all 10 patches to master. Thanks for great work! Let's continue with next ACI adventures :) Martin From pviktori at redhat.com Fri Dec 13 14:16:24 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Dec 2013 15:16:24 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52A72DA8.4090104@redhat.com> References: <52A72DA8.4090104@redhat.com> Message-ID: <52AB16B8.6050808@redhat.com> On 12/10/2013 04:05 PM, Jan Cholasta wrote: > Hi, > > I believe the time has come to drop support for the legacy (dn, > entry_attrs) tuple API and move to the new LDAPEntry API exclusively. > The attached patches convert existing code which uses the old API to the > new API and remove backward compatibility code from the ipaldap module. > > Note that there are still some functions/methods which accept separate > dn and entry_attrs arguments, they will be adapted to LDAPEntry later. > > Honza The first N-1 patches can be tested,acked,pushed independently, right? If that's the case, ACK for 225 As for dropping the support itself, I think we should think more about backward compatibility. This will affect nearly all third-party plugins, and I'm sure there are a few. I'd recommend something like: 3.4: Warn in release notes that we'll be dropping support; log a warning when __iter__ is used 3.5: Make __iter__ raise an exception (we don't want to silently start returning different data) 3.6: Finally start acting like a dict -- Petr? From rmeggins at redhat.com Fri Dec 13 14:22:01 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Dec 2013 07:22:01 -0700 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson (Was: FreeIPA 3.3."latest" failing tests: config_mod) In-Reply-To: <52AAD726.2030105@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> Message-ID: <52AB1809.7040305@redhat.com> On 12/13/2013 02:45 AM, Petr Viktorin wrote: > I finally got to investigating this failure. > > It seems ou, along with a bunch of other attributes, is missing from > organizationalPerson in Fedora 20. I don't think it's IPA's fault, as > we don't define organizationalPerson. > Nathan, could it be related to the new schema parser? Yes, looks like it. > > f19 has: > objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person > STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ > destinationIndicator $ preferredDeliveryMethod $ telexNumber $ > teletexTerminalIdentifier $ internationalISDNNumber $ > facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ > postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) X-ORIGIN > 'RFC 4519' ) > > f20 has: > objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person > STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ > destinationIndicator $ preferredDeliveryMethod $ telexNumber $ > teletexTerminalIdentifier ) X-ORIGIN 'RFC 4519' ) > > > > > On 11/14/2013 04:44 PM, Petr Spacek wrote: >> Hello, >> >> latest FreeIPA build from branch ipa-3-3 (built today on Fedora 20, >> latest bits) fails following tests: >> >> ====================================================================== >> ERROR: test_config[0]: config_mod: Try to add an unrelated objectclass >> to ipauserobjectclasses >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in >> >> func = lambda: self.check(nice, **test) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >> check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 340, in >> check_output >> got = api.Command[cmd](*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 436, in __call__ >> ret = self.run(*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 761, in run >> return self.forward(*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 782, in forward >> return self.Backend.xmlclient.forward(self.name, *args, **kw) >> File "/tmp/git/ipalib/rpc.py", line 712, in forward >> raise error(message=e.faultString) >> ValidationError: invalid 'ipauserobjectclasses': user default attribute >> ou would not be allowed! >> >> ====================================================================== >> ERROR: test_config[1]: config_mod: Remove the unrelated objectclass from >> ipauserobjectclasses >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 283, in >> >> func = lambda: self.check(nice, **test) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >> check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> File "/tmp/git/ipatests/test_xmlrpc/xmlrpc_test.py", line 340, in >> check_output >> got = api.Command[cmd](*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 436, in __call__ >> ret = self.run(*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 761, in run >> return self.forward(*args, **options) >> File "/tmp/git/ipalib/frontend.py", line 782, in forward >> return self.Backend.xmlclient.forward(self.name, *args, **kw) >> File "/tmp/git/ipalib/rpc.py", line 712, in forward >> raise error(message=e.faultString) >> AttrValueNotFound: ipauserobjectclasses does not contain 'ipahost' >> >> ---------------------------------------------------------------------- >> Ran 10 tests in 1.233s >> >> FAILED (errors=2) >> ====================================================================== >> FAILED under '/usr/bin/python2.7' >> >> >> Other tests from ipatests/test_xmlrpc/test_config_plugin.py are okay. >> > > From mkosek at redhat.com Fri Dec 13 14:38:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Dec 2013 15:38:33 +0100 Subject: [Freeipa-devel] [PATCH] 531 Increase stack size for Web UI builder In-Reply-To: <20131213121834.GD21264@redhat.com> References: <52AAC368.8050102@redhat.com> <20131213092859.GA21264@redhat.com> <52AAF9DD.4090507@redhat.com> <20131213121834.GD21264@redhat.com> Message-ID: <52AB1BE9.3050107@redhat.com> On 12/13/2013 01:18 PM, Alexander Bokovoy wrote: > On Fri, 13 Dec 2013, Petr Vobornik wrote: >> Web UI build fails on some architectures or configuration due to >> StackOverflow. This patch increases the stack size to solve it. >> >> 512k is usually enough but we encountered fail on ppc64 even with 2m, >> therefore the 8m. The build is single threaded so it shouldn't waste >> much memory. >> --- >> Makefile | 5 +++++ >> install/ui/util/build.sh | 5 +++-- >> install/ui/util/uglifyjs/uglify | 9 +++++---- >> 3 files changed, 13 insertions(+), 6 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index >> a7226341e6bd10106309997aae558fc07239482d..e54f8f0ba6484a12343f389b3cffbc20d7420a5f >> 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -55,6 +55,11 @@ PYTHON ?= $(shell rpm -E %__python || echo /usr/bin/python) >> CFLAGS := -g -O2 -Werror -Wall -Wextra -Wformat-security >> -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers >> $(CFLAGS) >> export CFLAGS >> >> +# Uncomment to increase Java stack size for Web UI build in case it fails >> +# because of stack overflow exception. Default should be OK for most platforms. >> +#JAVA_STACK_SIZE ?= 8m >> +#export JAVA_STACK_SIZE >> + >> all: bootstrap-autogen server tests >> @for subdir in $(SUBDIRS); do \ >> (cd $$subdir && $(MAKE) $@) || exit 1; \ >> diff --git a/install/ui/util/build.sh b/install/ui/util/build.sh >> index >> 7cd623485a8a87872e29d32f529bd77a45d59810..03776c1fe54f750cf028981bce625702af32aa1d >> 100755 >> --- a/install/ui/util/build.sh >> +++ b/install/ui/util/build.sh >> @@ -31,5 +31,6 @@ if [[ ! $profile ]] ; then >> exit 1 >> fi >> >> -rhino $DIR/build/build.js baseUrl=$DIR/build load=build >> profile=$DIR/../src/$profile.profile.js >> -exit $? >> \ No newline at end of file >> +RHINO="java -Xss${JAVA_STACK_SIZE:-512k} -classpath >> /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >> +$RHINO $DIR/build/build.js baseUrl=$DIR/build load=build >> profile=$DIR/../src/$profile.profile.js >> +exit $? >> diff --git a/install/ui/util/uglifyjs/uglify b/install/ui/util/uglifyjs/uglify >> index >> 7d25b38df19e465227f29b8b70ccf7ca140f725a..1227f589b4c50de49c465f6c696ecdc8af5e3c91 >> 100755 >> --- a/install/ui/util/uglifyjs/uglify >> +++ b/install/ui/util/uglifyjs/uglify >> @@ -25,8 +25,9 @@ DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" >> >> # rhino-1.7R4 doesn't have -main option to enable CommonJS support. It was >> # replaced by -require option. >> -if [ `rhino --help | grep -e -require | wc -l` -gt 0 ] ; then >> - rhino -require $DIR/uglify-js.js $@ >> +RHINO="java -Xss${JAVA_STACK_SIZE:-512k} -classpath >> /usr/share/java/rhino.jar org.mozilla.javascript.tools.shell.Main" >> +if [ `$RHINO --help | grep -e -require | wc -l` -gt 0 ] ; then >> + $RHINO -require $DIR/uglify-js.js $@ >> else >> - rhino -main $DIR/uglify-js.js $DIR/ug.js $@ >> -fi >> \ No newline at end of file >> + $RHINO -main $DIR/uglify-js.js $DIR/ug.js $@ >> +fi > > ACK. > > Pushed to master, ipa-3-3. I also set the increased stack size for the failing platforms. Patch attached, acked by Alexander via IRC. Pushed to master and ipa-3-3 as well. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-442-increase-java-stack-size-on-ppc-platforms.patch Type: text/x-patch Size: 951 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 15:02:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 16:02:38 +0100 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <5267E30E.4010401@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> <524BFBFD.1000901@redhat.com> <5253D7A0.2020108@redhat.com> <5256DCBC.3070901@redhat.com> <5267E30E.4010401@redhat.com> Message-ID: <52AB218E.9050601@redhat.com> On 23.10.2013 16:54, Tomas Hozza wrote: > On 10/10/2013 06:58 PM, Petr Spacek wrote: >> On 8.10.2013 12:00, Tomas Hozza wrote: >>> On 10/02/2013 12:57 PM, Petr Spacek wrote: >>>> On 13.9.2013 15:31, Petr Spacek wrote: >>>>> On 14.8.2013 16:42, Petr Spacek wrote: >>>>>> On 14.8.2013 16:25, Petr Spacek wrote: >>>>>>> On 1.8.2013 15:57, Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> attached monster patches replace our internal cache/database with >>>>>>>> RBTDB >>>>>>>> implementation. See commit messages and comments inside. >>>>>>>> >>>>>>>> This patch set provides very basic functionality (including DNS >>>>>>>> support for >>>>>>>> updates). Error handling definitely needs more love, but it should >>>>>>>> be enough >>>>>>>> for rapid DNSSEC prototyping. >>>>>>> >>>>>>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>>>>>> in-memory database. Commit message was modified to mention that >>>>>>> wildcards are >>>>>>> now supported. >>>>>>> >>>>>>> Patch 187 v2: The code was re-worked and now it respects >>>>>>> serial_autoincrement >>>>>>> option. >>>>>>> >>>>>>> Patch 188 v2: Minor comment clean-up and rebase on top of patch >>>>>>> 187 v2. >>>>>>> >>>>>>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() >>>>>>> was >>>>>>> deleted. This code was meant only for testing purposes. >>>>>>> >>>>>>> These patch set is now ready for review. Please see commit messages! >>>>>>> Some >>>>>>> functionality is missing intentionally, but it will be fixed by >>>>>>> separate >>>>>>> patches. >>>>>> >>>>>> It would be too easy! >>>>>> >>>>>> Patch 186 v3: Commit message was extended with information that LDAP >>>>>> MODRDN >>>>>> operation is not supported at the moment. >>>>>> >>>>>> Patch 187 v3: Missing file ldap_driver.h was added. >>>>> >>>>> This extended patch set handles correctly object deletion from LDAP. >>>>> >>>>> Patches 186-189 contain very minor changes, only moving code from one >>>>> place to >>>>> the other. >>>>> >>>>> See commit messages for patches 190 and 191. >>>>> >>>>> This should be testable. I would recommend to test the whole patch >>>>> set at >>>>> once, most probably it doesn't make much sense to test patches >>>>> separately. >>>> >>>> bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch >>>> >>>> adds missing missing include (db.h) to zone_register.c. >>>> >>> >>> ACK. >>> >>> Patches 186-191 tested. Adding/removing/modifying records works fine. >>> Also PTR synchronization works. Zone transfer to slave and NOTIFY >>> tested when changes occurred on master. >> >> Patch 191-2 fixed problem with zone removal and race condition during >> zone load. I would recommend you to test it with other patch I plan to >> send today :-) >> > > ACK. > > Patch looks good. Changes in patch 186 v6: - README was updated - update_record() events is terminated sooner in case of BIND shutdown -- This prevents some nasty surprises during shutdown. - Crash in update_record() was fixed: E.g. imagine a zone in LDAP without A record record for name in NS record. update_record() is restarted after any modification to invalid zone. This allows us to reload previously invalid zone if e.g. the missing A record was added. Version 5 of the patch crashed in this situation. This patch should go to master branch only. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0186-6-Use-RBTDB-instead-of-internal-LDAP-cache.patch Type: text/x-patch Size: 90134 bytes Desc: not available URL: From pviktori at redhat.com Fri Dec 13 15:30:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Dec 2013 16:30:22 +0100 Subject: [Freeipa-devel] [PATCH] 0347 Remove default from the ipapermlocation option Message-ID: <52AB280E.1040007@redhat.com> Fix an oversight in the recent IPA patches that fails a build check on other machines than mine. With required=False and autofill=False, the default is not used. I re-ran the tests to be sure. I'm tempted to ignore the generated API.txt and push it as a one-liner... -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0347-Remove-default-from-the-ipapermlocation-option.patch Type: text/x-patch Size: 4835 bytes Desc: not available URL: From pviktori at redhat.com Fri Dec 13 15:34:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Dec 2013 16:34:25 +0100 Subject: [Freeipa-devel] [PATCH] 0347 Remove default from the ipapermlocation option In-Reply-To: <52AB280E.1040007@redhat.com> References: <52AB280E.1040007@redhat.com> Message-ID: <52AB2901.9090201@redhat.com> On 12/13/2013 04:30 PM, Petr Viktorin wrote: > Fix an oversight in the recent IPA patches that fails a build check on > other machines than mine. > > With required=False and autofill=False, the default is not used. I > re-ran the tests to be sure. > > I'm tempted to ignore the generated API.txt and push it as a one-liner... I got a visual ACK from Martin, just as he was leaving for the holidays. Pushed to master: acede580e1f617af3f5205a490184781dd35b481 -- Petr? From pspacek at redhat.com Fri Dec 13 16:44:22 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:22 +0100 Subject: [Freeipa-devel] [PATCH 0181] Replace LDAP persistent search with syncrepl (RFC 4533) In-Reply-To: <5252B4CC.3000407@redhat.com> References: <51ED1647.5020805@redhat.com> <51ED3091.8050003@redhat.com> <5252B4CC.3000407@redhat.com> Message-ID: <52AB3966.9050205@redhat.com> On 7.10.2013 15:19, Tomas Hozza wrote: > On 07/22/2013 03:16 PM, Petr Spacek wrote: >> On 22.7.2013 13:23, Petr Spacek wrote: >>> Hello, >>> >>> Replace LDAP persistent search with syncrepl (RFC 4533). >>> >>> All direct operations with LDAP Persistent Search control are replaced >>> by ldap_sync_* calls. >>> >>> Syncrepl code works in exactly same way as old psearch code: >>> Only the DN of the modified object is re-used from the message, >>> data from the object are fetched via separate LDAP search. >>> >>> Current code is not able to detect object renaming because we don't have >>> UUID->DN mapping yet. >>> >>> Another limitation is that current code can't detect unchanged entries, >>> so serial is incremented after each parsed LDAP object. >> >> Clang noticed potential NULL dereference in cleanup section of >> ldap_syncrepl_watcher(). Fixed patch is attached. >> > > ACK. > > Tested Patch bundle 181 - 185. Common tasks like > adding/deleting/updating records work fine. Also PTR sync, zone serial > number > incrementation is OK. I have found that patch 181-2 doesn't handle reconnection to LDAP. This new version should handle reconnections better. This patch should go to master branch only. It is known limitation that zones and records deleted when connection is down are not refreshed properly after reconnection. This will be fixed some future version. I use this command for testing: socat tcp-listen:3899,fork,reuseaddr tcp-connect:localhost:389 It is necessary to modify port in /etc/named.conf to connect via socat. Then I can kill & restart socat to simulate connection breakage. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0181-3-Replace-LDAP-persistent-search-with-syncrepl-RFC-453.patch Type: text/x-patch Size: 30047 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:44:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:32 +0100 Subject: [Freeipa-devel] [PATCH 0192-0196] Write all changes to journal In-Reply-To: <5267E94E.1050001@redhat.com> References: <5256DE40.4060000@redhat.com> <5267E748.5000800@redhat.com> <5267E94E.1050001@redhat.com> Message-ID: <52AB3970.10003@redhat.com> On 23.10.2013 17:20, Petr Spacek wrote: > On 23.10.2013 17:12, Tomas Hozza wrote: >> On 10/10/2013 07:05 PM, Petr Spacek wrote: >>> Hello, >>> >>> this patch set adds journaling to bind-dyndb-ldap. >>> >>> Journaling requires proper SOA serial maintenance, so from now >>> SOA serial auto-incrementation is mandatory. >>> >>> Journal file is deleted on each start, so IXFR is limited to time frame >>> from last BIND start. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/64 >>> >>> >>> You can use my personal branch for testing: >>> https://github.com/spacekpe/bind-dyndb-ldap/tree/rbtdb.v7 >>> >>> It contains all unpushed patches. Basically, next master should be identical >>> to this branch. >>> >>> Thank you for your time! >>> >>> -- Petr^2 Spacek >> >> ACK. >> >> IXFR works as should. Also tested that journal is cleared after BIND >> restart, so server responds with AXFR. >> >> Patches look good, I have only one small thing to patch 0193: >> >>> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >>> index >>> 0786979a1970f4b61ac5b92dd5554bf87032d1ff..89acbe610519bbe0610a07d5fa5d4ffceddc71cd >>> 100644 >>> >>> --- a/src/ldap_helper.c >>> >>> +++ b/src/ldap_helper.c >>> >>> ... >>> >>> @@ -1401,7 +1405,155 @@ >>> >>> cleanup: >>> return result; >>> } >>> +/** >>> + * Process strictly minimal diff and detect if data were changed >>> + * and return latest SOA RR. >>> + * >>> + * @pre Input diff has to be minimal, i.e. it can't contain DEL & ADD >>> operation >>> + * for the same data under the same name and TTL. >>> + * >>> + * @pre If the tuple list contains SOA RR, then exactly one SOA RR >>> deletion >>> + * has to precede exactly one SOA RR addition. >>> + * (Each SOA RR deletion has to have matching addition.) >>> + * >>> + * @param[in] diff Input diff. List of tuples can be empty. >>> + * @param[out] soa_latest Pointer to last added SOA RR from tuple list. >>> + * Result can be NULL if there is no added SOA RR >>> + * in the tuple list. >>> + * @param[out] data_changed ISC_TRUE if any data other than SOA serial >>> were >>> + * changed. ISC_FALSE if nothing (except SOA >>> + * serial) was changed. >>> + * >>> + */ >>> +static isc_result_t ATTR_NONNULLS >>> +diff_analyze_serial(dns_diff_t *diff, dns_difftuple_t **soa_latest, >>> + isc_boolean_t *data_changed) { >>> + dns_difftuple_t *t = NULL; >>> + dns_rdata_t *del_soa = NULL; /* last seen SOA with op == DEL */ >>> + dns_difftuple_t *tmp_tuple = NULL; /* tuple used for SOA comparison */ >>> + isc_result_t result = ISC_R_SUCCESS; >>> + int ret; >>> + >>> + REQUIRE(DNS_DIFF_VALID(diff)); >>> + REQUIRE(soa_latest != NULL && *soa_latest == NULL); >>> + REQUIRE(data_changed != NULL); >>> + >>> + *data_changed = ISC_FALSE; >>> + for (t = HEAD(diff->tuples); >>> + t != NULL; >>> + t = NEXT(t, link)) { >>> + INSIST(tmp_tuple == NULL); >> after this ^^^ line tmp_tuple is NULL in the current for loop cycle. >>> + if (t->rdata.type != dns_rdatatype_soa) >>> + *data_changed = ISC_TRUE; >>> + else { /* SOA is always special case */ >>> + if (t->op == DNS_DIFFOP_DEL || >>> + t->op == DNS_DIFFOP_DELRESIGN) { >>> + /* delete operation has to precede add */ >>> + INSIST(del_soa == NULL); >>> + INSIST(tmp_tuple == NULL); >> so this ^^^ check is duplicit >>> + del_soa = &t->rdata; >>> + } else if (t->op == DNS_DIFFOP_ADD || >>> + t->op == DNS_DIFFOP_ADDRESIGN) { >>> + /* add operation has to follow a delete */ >>> + INSIST(del_soa != NULL); >>> + INSIST(tmp_tuple == NULL); >> and also this ^^^ check is duplicit >>> + *soa_latest = t; >>> + >>> + /* detect if fields other than serial >>> + * were changed (compute only if necessary) */ >>> + if (*data_changed == ISC_FALSE) { >>> + CHECK(dns_difftuple_copy(t, &tmp_tuple)); >>> + dns_soa_setserial(dns_soa_getserial(del_soa), >>> + &tmp_tuple->rdata); >>> + ret = dns_rdata_compare(del_soa, >>> + &tmp_tuple->rdata); >>> + *data_changed = ISC_TF(ret != 0); >>> + } >>> + if (tmp_tuple != NULL) >>> + dns_difftuple_free(&tmp_tuple); >>> + /* re-start the SOA delete-add search cycle */ >>> + del_soa = NULL; >>> + } else { >>> + INSIST("unexpected diff: op != ADD || DEL" >>> + == NULL); >>> + } >>> + } >>> + } >>> + /* SOA deletions & additions has to create self-contained couples */ >>> + INSIST(del_soa == NULL && tmp_tuple == NULL); >>> + >>> +cleanup: >>> + if (tmp_tuple != NULL) >>> + dns_difftuple_free(&tmp_tuple); >>> + return result; >>> +} >>> + >>> ... >> >> Sorry for the formatting, obviously my email client is not perfect. >> Hope you can understand it... > > I will fix it before push. Patch 192 was unchanged. Patch 193 v2 - redundant INSIST calls were removed - patch was rebased Patch 194 v2 - copyright header was fixed Patch 196 v2 - README was updated - missing header dns/journal.h was added - fixes in error handling: journal is correctly closed as necessary - patch was rebased -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0194-2-Create-working-directory-for-each-LDAP-instance.patch Type: text/x-patch Size: 7065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0193-2-Rework-SOA-serial-auto-incrementation-and-make-it-ma.patch Type: text/x-patch Size: 20305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0196-2-Record-all-changes-in-DNS-zone-to-journal.patch Type: text/x-patch Size: 13688 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:44:36 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:36 +0100 Subject: [Freeipa-devel] [PATCH 0197-0200] Preparation for bind-dyndb-ldap release 4.0 In-Reply-To: <5267E768.1020709@redhat.com> References: <5257FEB1.6020306@redhat.com> <5267E768.1020709@redhat.com> Message-ID: <52AB3974.3030605@redhat.com> On 23.10.2013 17:12, Tomas Hozza wrote: > On 10/11/2013 03:35 PM, Petr Spacek wrote: >> Hello, >> >> update documentation and schema files for upcoming version 4.0. >> >> This fixes typo in schema file: >> https://fedorahosted.org/bind-dyndb-ldap/ticket/121 >> >> Have a nice weekend! I updated NEWS file in patch 199 v2, other files are only rebased. Patch 198 should go to v3 and master branch, other patches should go only to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0199-2-Update-NEWS-for-upcoming-4.0-release.patch Type: text/x-patch Size: 2492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0200-2-Bump-NVR-to-4.0.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0197-Remove-persistent-search-and-zone_refresh-attributes.patch Type: text/x-patch Size: 2466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0198-Fix-typo-in-LDAP-schema.patch Type: text/x-patch Size: 804 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:44:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:44 +0100 Subject: [Freeipa-devel] [PATCH 0201] Report error if RFC 4533 initialization failed In-Reply-To: <526927E7.9060404@redhat.com> References: <5267E7CF.2000202@redhat.com> <526927E7.9060404@redhat.com> Message-ID: <52AB397C.4070901@redhat.com> On 24.10.2013 16:00, Tomas Hozza wrote: > On 10/23/2013 05:14 PM, Petr Spacek wrote: >> Hello, >> >> this patch belongs to 4.0 release. It allows the user to catch some >> mis-configurations. >> >> It produces error messages like this: >> LDAP error: Critical extension is unavailable: unable to start SyncRepl >> session: is RFC 4533 supported on LDAP server? Patch 201 v2 was rebased and modified. Now the code prints an error and continues to re-try as usual instead of killing BIND. Shutdown in early stages of start-up had various strange effects including assertion failures. This patch should go only to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0201-2-Report-error-if-RFC-4533-initialization-failed.patch Type: text/x-patch Size: 1421 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:44:52 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:52 +0100 Subject: [Freeipa-devel] [PATCH 0202-0203] Improve performance of initial LDAP synchronizationDetect end of initial LDAP synchronization phase In-Reply-To: <5282458B.4000808@redhat.com> References: <5273AD7D.5020402@redhat.com> <1939839260.12480070.1383650984710.JavaMail.root@redhat.com> <5282458B.4000808@redhat.com> Message-ID: <52AB3984.8010005@redhat.com> On 12.11.2013 16:13, Petr Spacek wrote: > On 5.11.2013 12:29, Tomas Hozza wrote: >> ----- Original Message ----- >>> Hello, >>> >>> Improve performance of initial LDAP synchronization. >>> >>> Changes are not journaled and SOA serial is not incremented during initial >>> LDAP synchronization. >>> >>> This eliminates unnecessary synchronous writes to journal and also >>> unnecessary SOA serial writes to LDAP. >>> >>> See commit messages and comments in syncrepl.c for all the gory details. >> >> >> ACK. >> >> Patches look good. AXFR and IXFR works as expected. Also BIND starts up much >> faster with these patches. Good job... :) >> >> Regards, >> >> Tomas > > Hmm, further testing revealed that patch 203 changed behavior little bit: > Zones were loaded from LDAP correctly, but the SOA serial wasn't changed at > all. As a result, zone transfers return inconsistent results if the data in > LDAP are changed when BIND was not running. > > Patch 203-v2 imitates the old behavior from bind-dyndb-ldap 3.x: Zone serial > is bumped *once* for each zone, so any changed in LDAP will be transferred > correctly (with new serial). Patch 202 v2 was rebased and fixes reconnection to LDAP and solves deadlock caused by too eager locking. Patch 203 v3 was rebased and fixes reconnection to LDAP. These patches should go to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0202-2-Detect-end-of-initial-LDAP-synchronization-phase.patch Type: text/x-patch Size: 20780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0203-3-Improve-performance-of-initial-LDAP-synchronization.patch Type: text/x-patch Size: 7144 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:44:56 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:56 +0100 Subject: [Freeipa-devel] [PATCH 0204] Remove obsolete zr_get_rbt() function from zone register In-Reply-To: <5280C540.8030604@redhat.com> References: <5280C540.8030604@redhat.com> Message-ID: <52AB3988.8090801@redhat.com> On 11.11.2013 12:53, Petr Spacek wrote: > Hello, > > Remove obsolete zr_get_rbt() function from zone register. This patch stays unchanged. It should go to branches v3 and master. -- Petr^2 Spacek From pspacek at redhat.com Fri Dec 13 16:44:59 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:44:59 +0100 Subject: [Freeipa-devel] [PATCH 0205] Fix race condition during write to internal RBTDB In-Reply-To: <5280C794.3060503@redhat.com> References: <5280C794.3060503@redhat.com> Message-ID: <52AB398B.4030008@redhat.com> On 11.11.2013 13:03, Petr Spacek wrote: > Hello, > > Fix race condition during write to internal RBTDB. > > RBTDB implementation allows to open only one RBTDB instance > for writing at the same time. This patch adds mutex to > newversion() implementation in ldap_driver.c. > > See comments around ldapdb_t, newversion() and closeversion(). I'm attaching rebased patch. This patch should go to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0205-2-Fix-race-condition-during-write-to-internal-RBTDB.patch Type: text/x-patch Size: 7903 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:02 +0100 Subject: [Freeipa-devel] [PATCH 0206] Publish zones only after all LDAP events have been processed In-Reply-To: <52824464.2070503@redhat.com> References: <52824464.2070503@redhat.com> Message-ID: <52AB398E.7000806@redhat.com> On 12.11.2013 16:08, Petr Spacek wrote: > Hello, > > Publish zones only after all LDAP events have been processed. > > Zones are not exposed in _default DNS view until all events > generated before LDAP intermediate message have been processed. > > This prevents BIND from returning NXDOMAIN for some names from > a zone but NOERROR answers for other names in the same zone. > It would be pretty confusing and not easy to debug. I'm attaching rebased patch. This patch should go to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0206-2-Publish-zones-only-after-all-LDAP-events-have-been-p.patch Type: text/x-patch Size: 5614 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:06 +0100 Subject: [Freeipa-devel] [PATCH 0207] Do not load invalid zones In-Reply-To: <52961103.1020101@redhat.com> References: <52961103.1020101@redhat.com> Message-ID: <52AB3992.9050507@redhat.com> On 27.11.2013 16:34, Petr Spacek wrote: > Hello, > > Do not load invalid zones. > > Without this patch, it was possible to load an invalid zone without > proper SOA or NS records because the fake SOA and NS records allowed > checks in dns_zone_load() to pass. > > With this patch, no fake SOA or NS records are created and > dns_zone_load() is not called before end of the initial synchronization. > > See the function ldapdb_associate() in ldap_driver.c and it's comments. Patch 207 v2 fixes reconnecting to LDAP. dns_db_detachnode() call in update_record() function was moved to the cleanup section - this is workaround for ISC bug #35080. This patch should go to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0207-2-Do-not-load-invalid-zones.patch Type: text/x-patch Size: 24727 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:13 +0100 Subject: [Freeipa-devel] [PATCH 0208] Remove local variables which shadow variables from a upper level Message-ID: <52AB3999.6090502@redhat.com> Hello, Remove local variables which shadow variables from a upper level. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0208-Remove-local-variables-which-shadow-variables-from-a.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:16 +0100 Subject: [Freeipa-devel] [PATCH 0209] Silence GCC warnings produced by -Wjump-misses-init Message-ID: <52AB399C.8020204@redhat.com> Hello, Silence GCC warnings produced by -Wjump-misses-init. It seems that it is false alarm in our case. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0209-Silence-GCC-warnings-produced-by-Wjump-misses-init.patch Type: text/x-patch Size: 2196 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:19 +0100 Subject: [Freeipa-devel] [PATCH 0210] Add missing default branches to switch statemets Message-ID: <52AB399F.9020702@redhat.com> Hello, Add missing default branches to switch statemets. This should help little bit with uninitialized memory usage. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0210-Add-missing-default-branches-to-switch-statemets.patch Type: text/x-patch Size: 2473 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:21 +0100 Subject: [Freeipa-devel] [PATCH 0211] Improve error handling in code for LDAP modification Message-ID: <52AB39A1.3070905@redhat.com> Hello, Improve error handling in code for LDAP modification. Failed LDAP modification is retried once. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0211-Improve-error-handling-in-code-for-LDAP-modification.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:24 +0100 Subject: [Freeipa-devel] [PATCH 0212] Remove unused parameter attrlist from ldap_entry_nextattr() Message-ID: <52AB39A4.4050107@redhat.com> Hello, Remove unused parameter attrlist from ldap_entry_nextattr(). This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0212-Improve-error-handling-in-code-for-LDAP-modification.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:26 +0100 Subject: [Freeipa-devel] [PATCH 0213] Fix crash caused by invalid data in SOA record Message-ID: <52AB39A6.8040604@redhat.com> Hello, Fix crash caused by invalid data in SOA record. E.g. try to put '\0' to the idnsSOAmName attribute... This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0213-Fix-crash-caused-by-invalid-data-in-SOA-record.patch Type: text/x-patch Size: 936 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:29 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:29 +0100 Subject: [Freeipa-devel] [PATCH 0214] Make ldap_parse_rrentry() idempotent Message-ID: <52AB39A9.6090501@redhat.com> Hello, Make ldap_parse_rrentry() idempotent. Now, a call to ldap_parse_rrentry() resets the internal entry interators in ldap_entry_t so the results are always correct. Without this patch, a second call returned empty ldapdb_rdatalist_t because all iterators were at the end of internal lists. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0214-Make-ldap_parse_rrentry-idempotent.patch Type: text/x-patch Size: 4722 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:33 +0100 Subject: [Freeipa-devel] [PATCH 0215] Update NEWS for upcoming 3.6 release Message-ID: <52AB39AD.7010601@redhat.com> Hello, Update NEWS for upcoming 3.6 release. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0215-Update-NEWS-for-upcoming-3.6-release.patch Type: text/x-patch Size: 691 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:38 +0100 Subject: [Freeipa-devel] [PATCH 0216] Bump NVR to 3.6 Message-ID: <52AB39B2.90506@redhat.com> Hello, Bump NVR to 3.6. BIND 9.9.0 is required. Tomas, shouldn't I use Requires: bind >= 32:9.9.0-1 ? This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0216-Bump-NVR-to-3.6.patch Type: text/x-patch Size: 1845 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 16:45:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 17:45:45 +0100 Subject: [Freeipa-devel] [PATCH 0217] Cleanup zone and journal files on LDAP reconnect Message-ID: <52AB39B9.4090201@redhat.com> Hello, Cleanup zone and journal files on LDAP reconnect. This cleanup solves potential inconsistencies between order of operations in LDAP and order of operations recorded in journal. This patch should go to master branch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0217-Cleanup-zone-and-journal-files-on-LDAP-reconnect.patch Type: text/x-patch Size: 2713 bytes Desc: not available URL: From pspacek at redhat.com Fri Dec 13 17:50:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Dec 2013 18:50:47 +0100 Subject: [Freeipa-devel] Repository with bind-dyndb-ldap 3.6 and 4.0 Message-ID: <52AB48F7.8030400@redhat.com> Hello, latest patches for v3 branch are in my temporary v3.6 branch on Github: https://github.com/spacekpe/bind-dyndb-ldap/tree/v3.6 ... and latest patches for master branch are in master.rbtdb.v22 branch: https://github.com/spacekpe/bind-dyndb-ldap/tree/master.rbtdb.v22 I hope that this will save you some headaches from patch ordering. All the patches are Christmas gift for you :-) -- Petr^2 Spacek From npmccallum at redhat.com Fri Dec 13 19:46:59 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Dec 2013 14:46:59 -0500 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52A85B15.2020906@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <52A85B15.2020906@redhat.com> Message-ID: <1386964019.1948.9.camel@localhost.localdomain> On Wed, 2013-12-11 at 13:31 +0100, Martin Kosek wrote: > On 12/11/2013 01:24 PM, Jan Cholasta wrote: > > On 14.11.2013 20:23, Nathaniel McCallum wrote: > >> On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote: > >>> On 8.10.2013 16:35, Nathaniel McCallum wrote: > >>>> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: > >>>>> > >>>>> +class Base32DecodeError(ExecutionError): > >>>>> > >>>>> Is this really necessary? Are we going to add DecodeError for > >>>>> every kind of new encoding in IPA? Can't we just have generic > >>>>> DecodeError? (This is not an issue in your patch per se, I'm just > >>>>> wondering if we can do it better in the framework.) > >>>> > >>>> I added the new error due to the existence of a Base64DecodeError. I > >>>> figured changing the existing error to be more generic would break api. > >>>> > >>>> Nathaniel > >>>> > >>> > >>> I think you can use ConversionError instead. I don't see any reason why > >>> base32/64 decoding errors should be special cased like this and would > >>> like to see Base64DecodeError gone. > >> > >> Fixed. > ... > > + # Get the issuer for the URI > > + issuer = api.env.realm > > + if owner is not None: > > + try: > > + issuer = ldap.get_entry(owner, > > ['krbprincipalname'])['krbprincipalname'][0] > > + except: > > + pass > > > > Please use "except PublicError" here, we don't want internal errors to be ignored. > > Right. I think what Nathaniel wanted to do is: > > except errors.NotFound: > pass Exactly. > Bare except-pass is wrong on several levels anyway. For example it also catches > syntax or interrupt exceptions. I left this blank to figure out what the exception was and forgot about it. Thanks! :) > > + # Delete all tokens owned by this user > > + owner = self.api.Object.user.get_primary_key_from_dn(dn) > > + results = self.api.Command.otptoken_find(ipatokenowner=owner)['result'] > > + for token in results: > > + token = self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) > > + self.api.Command.otptoken_del(token) > > > > This should probably be handled by the referint plugin. > > > > Honza > > > > I think referint plugin would just remove the attribute containing DN to user, > not the whole entry. I.e. I think Nathaniel need to do it this way anyway. > > Though I think it would be more efficient if we do just one 'otptoken_del' call > with the list of tokens as primary key to it. All standard LDAPDelete based > plugins can do that. You may also want to pass continue=True in the list of > it's options in this case. This logic needs to be here and will get more complicated in the future. The big future patch I see here is distinguishing between different types of tokens. For instance, we should probably delete soft-tokens but orphan hard-tokens for reassignment. Future admins may also want this to be configurable on a per-token basis. Nathaniel From npmccallum at redhat.com Fri Dec 13 19:50:18 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Dec 2013 14:50:18 -0500 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52A85967.1020601@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> Message-ID: <1386964218.1948.12.camel@localhost.localdomain> On Wed, 2013-12-11 at 13:24 +0100, Jan Cholasta wrote: > On 14.11.2013 20:23, Nathaniel McCallum wrote: > > On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote: > >> On 8.10.2013 16:35, Nathaniel McCallum wrote: > >>> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: > >>>> > >>>> +class Base32DecodeError(ExecutionError): > >>>> > >>>> Is this really necessary? Are we going to add DecodeError for > >>>> every kind of new encoding in IPA? Can't we just have generic > >>>> DecodeError? (This is not an issue in your patch per se, I'm just > >>>> wondering if we can do it better in the framework.) > >>> > >>> I added the new error due to the existence of a Base64DecodeError. I > >>> figured changing the existing error to be more generic would break api. > >>> > >>> Nathaniel > >>> > >> > >> I think you can use ConversionError instead. I don't see any reason why > >> base32/64 decoding errors should be special cased like this and would > >> like to see Base64DecodeError gone. > > > > Fixed. > > > > > > Thanks. > > format = _("invalid '%(name)s': %(error)s") > > - > class ValidationError(InvocationError): > """ > **3009** Raised when a parameter value fails a validation rule. > @@ -1306,6 +1305,7 @@ class PosixGroupViolation(ExecutionError): > errno = 4030 > format = _('This is already a posix group and cannot be converted > to external one') > > + > class BuiltinError(ExecutionError): > > This white space shuffling is not necessary. Fixed. I missed this, thanks! > +def _normalize_owner(userobj, entry_attrs): > + if 'ipatokenowner' in entry_attrs: > + entry_attrs['ipatokenowner'] = map(userobj.get_primary_key_from_dn, > + entry_attrs['ipatokenowner']) > > If the --raw option is specified, ipatokenowner value should be full DN. Fixed. > + # Resolve the user's dn > + owner = entry_attrs.get('ipatokenowner', None) > + if owner is not None: > + owner = self.api.Object.user.get_dn(owner) > + entry_attrs['ipatokenowner'] = owner > > You have a _normalize_owner function, I think the code above should go > into a _convert_owner function (use the function in > otptoken_{mod,show,find} as well). Fixed for mod and find. Show doesn't make sense. > + # Get the issuer for the URI > + issuer = api.env.realm > + if owner is not None: > + try: > + issuer = ldap.get_entry(owner, > ['krbprincipalname'])['krbprincipalname'][0] > + except: > + pass > > Please use "except PublicError" here, we don't want internal errors to > be ignored. Fixed: (NotFound, IndexError) > + # Delete all tokens owned by this user > + owner = self.api.Object.user.get_primary_key_from_dn(dn) > + results = > self.api.Command.otptoken_find(ipatokenowner=owner)['result'] > + for token in results: > + token = > self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) > + self.api.Command.otptoken_del(token) > > This should probably be handled by the referint plugin. See my reply to Martin. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-4-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 32623 bytes Desc: not available URL: From npmccallum at redhat.com Fri Dec 13 20:15:29 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Dec 2013 15:15:29 -0500 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1386964218.1948.12.camel@localhost.localdomain> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> Message-ID: <1386965729.1948.13.camel@localhost.localdomain> On Fri, 2013-12-13 at 14:50 -0500, Nathaniel McCallum wrote: > On Wed, 2013-12-11 at 13:24 +0100, Jan Cholasta wrote: > > On 14.11.2013 20:23, Nathaniel McCallum wrote: > > > On Wed, 2013-10-30 at 08:57 +0100, Jan Cholasta wrote: > > >> On 8.10.2013 16:35, Nathaniel McCallum wrote: > > >>> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: > > >>>> > > >>>> +class Base32DecodeError(ExecutionError): > > >>>> > > >>>> Is this really necessary? Are we going to add DecodeError for > > >>>> every kind of new encoding in IPA? Can't we just have generic > > >>>> DecodeError? (This is not an issue in your patch per se, I'm just > > >>>> wondering if we can do it better in the framework.) > > >>> > > >>> I added the new error due to the existence of a Base64DecodeError. I > > >>> figured changing the existing error to be more generic would break api. > > >>> > > >>> Nathaniel > > >>> > > >> > > >> I think you can use ConversionError instead. I don't see any reason why > > >> base32/64 decoding errors should be special cased like this and would > > >> like to see Base64DecodeError gone. > > > > > > Fixed. > > > > > > > > > > Thanks. > > > > format = _("invalid '%(name)s': %(error)s") > > > > - > > class ValidationError(InvocationError): > > """ > > **3009** Raised when a parameter value fails a validation rule. > > @@ -1306,6 +1305,7 @@ class PosixGroupViolation(ExecutionError): > > errno = 4030 > > format = _('This is already a posix group and cannot be converted > > to external one') > > > > + > > class BuiltinError(ExecutionError): > > > > This white space shuffling is not necessary. > > Fixed. I missed this, thanks! > > > +def _normalize_owner(userobj, entry_attrs): > > + if 'ipatokenowner' in entry_attrs: > > + entry_attrs['ipatokenowner'] = map(userobj.get_primary_key_from_dn, > > + entry_attrs['ipatokenowner']) > > > > If the --raw option is specified, ipatokenowner value should be full DN. > > Fixed. > > > + # Resolve the user's dn > > + owner = entry_attrs.get('ipatokenowner', None) > > + if owner is not None: > > + owner = self.api.Object.user.get_dn(owner) > > + entry_attrs['ipatokenowner'] = owner > > > > You have a _normalize_owner function, I think the code above should go > > into a _convert_owner function (use the function in > > otptoken_{mod,show,find} as well). > > Fixed for mod and find. Show doesn't make sense. > > > + # Get the issuer for the URI > > + issuer = api.env.realm > > + if owner is not None: > > + try: > > + issuer = ldap.get_entry(owner, > > ['krbprincipalname'])['krbprincipalname'][0] > > + except: > > + pass > > > > Please use "except PublicError" here, we don't want internal errors to > > be ignored. > > Fixed: (NotFound, IndexError) > > > + # Delete all tokens owned by this user > > + owner = self.api.Object.user.get_primary_key_from_dn(dn) > > + results = > > self.api.Command.otptoken_find(ipatokenowner=owner)['result'] > > + for token in results: > > + token = > > self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) > > + self.api.Command.otptoken_del(token) > > > > This should probably be handled by the referint plugin. > > See my reply to Martin. ARGH! I should try not to break stuff. New patch attached... -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-5-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 32654 bytes Desc: not available URL: From npmccallum at redhat.com Fri Dec 13 20:57:31 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Dec 2013 15:57:31 -0500 Subject: [Freeipa-devel] FreeIPA OTP End-to-End Message-ID: <1386968251.1948.25.camel@localhost.localdomain> This is an email to track the status of the OTP project as we push toward completion. I'm also attempting to get all the pieces in play so that they are testable. RPMs Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ These currently contain the CLI and UI patches, but exclude the DS plugin patch. I will merge this last patch in when submitted to the list. OTP CLI All of the patches are merged except npmccallum-0024, which is undergoing active review. https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html OTP UI Thanks to Petr Vobornik for his set of patches implementing the UI. They can be found rebased on top of my otp changes here: https://github.com/npmccallum/freeipa/commits/otpui Authentication methods and RADIUS proxy support seems to be fully functional and I have not encountered any bugs. I'm not currently able to get the OTP UI to show up at all (I may well be doing something wrong). I believe Petr plans to clean these up and resubmit them to the list. One additional patch will be required for the token sync extop. DS PLUGIN I am nearing completion on the DS plugin providing support for deletion protection and the token sync extop. This should hit the list next week. OTHER Am I missing anything? Nathaniel From dpal at redhat.com Fri Dec 13 22:45:28 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Dec 2013 17:45:28 -0500 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <1386968251.1948.25.camel@localhost.localdomain> References: <1386968251.1948.25.camel@localhost.localdomain> Message-ID: <52AB8E08.5000102@redhat.com> On 12/13/2013 03:57 PM, Nathaniel McCallum wrote: > This is an email to track the status of the OTP project as we push > toward completion. I'm also attempting to get all the pieces in play so > that they are testable. > > RPMs > Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > These currently contain the CLI and UI patches, but exclude the DS > plugin patch. I will merge this last patch in when submitted to the > list. > > OTP CLI > All of the patches are merged except npmccallum-0024, which is > undergoing active review. > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html > > OTP UI > Thanks to Petr Vobornik for his set of patches implementing the UI. They > can be found rebased on top of my otp changes here: > https://github.com/npmccallum/freeipa/commits/otpui > > Authentication methods and RADIUS proxy support seems to be fully > functional and I have not encountered any bugs. I'm not currently able > to get the OTP UI to show up at all (I may well be doing something > wrong). > > I believe Petr plans to clean these up and resubmit them to the list. > > One additional patch will be required for the token sync extop. > > DS PLUGIN > I am nearing completion on the DS plugin providing support for deletion > protection and the token sync extop. This should hit the list next week. > > OTHER > Am I missing anything? Did you update the wiki page? I think it was one of the outstanding items. Any unit tests? Any way to include some testes for Continues Integration? Anything SELinux related? Default configuration of locations and names of sockets and files? Things like that. A recorded demo also would be nice when all things put together. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Mon Dec 16 09:22:28 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Dec 2013 10:22:28 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52AB16B8.6050808@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> Message-ID: <52AEC654.5040602@redhat.com> On 13.12.2013 15:16, Petr Viktorin wrote: > On 12/10/2013 04:05 PM, Jan Cholasta wrote: >> Hi, >> >> I believe the time has come to drop support for the legacy (dn, >> entry_attrs) tuple API and move to the new LDAPEntry API exclusively. >> The attached patches convert existing code which uses the old API to the >> new API and remove backward compatibility code from the ipaldap module. >> >> Note that there are still some functions/methods which accept separate >> dn and entry_attrs arguments, they will be adapted to LDAPEntry later. >> >> Honza > > The first N-1 patches can be tested,acked,pushed independently, right? Yes. > If that's the case, ACK for 225 > > > As for dropping the support itself, I think we should think more about > backward compatibility. This will affect nearly all third-party plugins, > and I'm sure there are a few. Are there? > > I'd recommend something like: > 3.4: Warn in release notes that we'll be dropping support; log a warning > when __iter__ is used > 3.5: Make __iter__ raise an exception (we don't want to silently start > returning different data) > 3.6: Finally start acting like a dict Could we raise an exception now instead of waiting for 3.5? Fixing the plugins is nothing hard, you know... -- Jan Cholasta From pviktori at redhat.com Mon Dec 16 09:29:50 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Dec 2013 10:29:50 +0100 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <52AB1809.7040305@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> Message-ID: <52AEC80E.1000003@redhat.com> On 12/13/2013 03:22 PM, Rich Megginson wrote: > On 12/13/2013 02:45 AM, Petr Viktorin wrote: >> I finally got to investigating this failure. >> >> It seems ou, along with a bunch of other attributes, is missing from >> organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >> we don't define organizationalPerson. >> Nathan, could it be related to the new schema parser? > > Yes, looks like it. Thanks for filing the bug, sorry I didn't get to it on Friday. URL for the record: https://fedorahosted.org/389/ticket/47631 >> f19 has: >> objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person >> STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ >> destinationIndicator $ preferredDeliveryMethod $ telexNumber $ >> teletexTerminalIdentifier $ internationalISDNNumber $ >> facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ >> postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) X-ORIGIN >> 'RFC 4519' ) >> >> f20 has: >> objectclasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person >> STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ >> destinationIndicator $ preferredDeliveryMethod $ telexNumber $ >> teletexTerminalIdentifier ) X-ORIGIN 'RFC 4519' ) -- Petr? From abokovoy at redhat.com Mon Dec 16 09:52:58 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 11:52:58 +0200 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <52AEC80E.1000003@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> Message-ID: <20131216095258.GK21264@redhat.com> On Mon, 16 Dec 2013, Petr Viktorin wrote: >On 12/13/2013 03:22 PM, Rich Megginson wrote: >>On 12/13/2013 02:45 AM, Petr Viktorin wrote: >>>I finally got to investigating this failure. >>> >>>It seems ou, along with a bunch of other attributes, is missing from >>>organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >>>we don't define organizationalPerson. >>>Nathan, could it be related to the new schema parser? >> >>Yes, looks like it. > >Thanks for filing the bug, sorry I didn't get to it on Friday. > >URL for the record: https://fedorahosted.org/389/ticket/47631 Should we consider this a release blocker for tomorrow's Fedora 20 release? At the very least this bug has to be fixed and the fix pushed to F20 as soon as possible. -- / Alexander Bokovoy From pviktori at redhat.com Mon Dec 16 11:11:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Dec 2013 12:11:02 +0100 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <20131216095258.GK21264@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> <20131216095258.GK21264@redhat.com> Message-ID: <52AEDFC6.30207@redhat.com> On 12/16/2013 10:52 AM, Alexander Bokovoy wrote: > On Mon, 16 Dec 2013, Petr Viktorin wrote: >> On 12/13/2013 03:22 PM, Rich Megginson wrote: >>> On 12/13/2013 02:45 AM, Petr Viktorin wrote: >>>> I finally got to investigating this failure. >>>> >>>> It seems ou, along with a bunch of other attributes, is missing from >>>> organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >>>> we don't define organizationalPerson. >>>> Nathan, could it be related to the new schema parser? >>> >>> Yes, looks like it. >> >> Thanks for filing the bug, sorry I didn't get to it on Friday. >> >> URL for the record: https://fedorahosted.org/389/ticket/47631 > Should we consider this a release blocker for tomorrow's Fedora 20 > release? > > At the very least this bug has to be fixed and the fix pushed to F20 > as soon as possible. AFAIU 389-ds will get a downgrade for f20, complete with an epoch bump. -- Petr? From pviktori at redhat.com Mon Dec 16 11:46:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Dec 2013 12:46:48 +0100 Subject: [Freeipa-devel] [PATCH] 0344-0345 Allow anonymous and all permissions Message-ID: <52AEE828.6010102@redhat.com> Hello, The next step in permission effort is small since the groundwork is already done. This adds API/CLI for anonymous&all permissions, and disables adding these to privileges. Ticket: https://fedorahosted.org/freeipa/ticket/4032 Design: http://www.freeipa.org/page/V3/Anonymous_and_All_permissions -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0344-Use-new-registration-API-in-the-privilege-plugin.patch Type: text/x-patch Size: 2919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0345-Allow-anonymous-and-all-permissions.patch Type: text/x-patch Size: 18324 bytes Desc: not available URL: From jcholast at redhat.com Mon Dec 16 12:47:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Dec 2013 13:47:21 +0100 Subject: [Freeipa-devel] [PATCH] 231 Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent Message-ID: <52AEF659.8040502@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-231-Prevent-garbage-from-readline-on-standard-output-of-.patch Type: text/x-patch Size: 955 bytes Desc: not available URL: From pviktori at redhat.com Mon Dec 16 13:45:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Dec 2013 14:45:22 +0100 Subject: [Freeipa-devel] [PATCHES] 225-230 Drop support for the legacy LDAP API In-Reply-To: <52AEC654.5040602@redhat.com> References: <52A72DA8.4090104@redhat.com> <52AB16B8.6050808@redhat.com> <52AEC654.5040602@redhat.com> Message-ID: <52AF03F2.2090904@redhat.com> On 12/16/2013 10:22 AM, Jan Cholasta wrote: > On 13.12.2013 15:16, Petr Viktorin wrote: >> On 12/10/2013 04:05 PM, Jan Cholasta wrote: >>> Hi, >>> >>> I believe the time has come to drop support for the legacy (dn, >>> entry_attrs) tuple API and move to the new LDAPEntry API exclusively. >>> The attached patches convert existing code which uses the old API to the >>> new API and remove backward compatibility code from the ipaldap module. >>> >>> Note that there are still some functions/methods which accept separate >>> dn and entry_attrs arguments, they will be adapted to LDAPEntry later. >>> >>> Honza >> >> The first N-1 patches can be tested,acked,pushed independently, right? > > Yes. > >> If that's the case, ACK for 225 Pushed that one to master, 5 more to go. bc3f3381c6bf0b4941889b775025a60f56318551 >> As for dropping the support itself, I think we should think more about >> backward compatibility. This will affect nearly all third-party plugins, >> and I'm sure there are a few. > > Are there? Yes, there are some private plugins in the wild. >> I'd recommend something like: >> 3.4: Warn in release notes that we'll be dropping support; log a warning >> when __iter__ is used >> 3.5: Make __iter__ raise an exception (we don't want to silently start >> returning different data) >> 3.6: Finally start acting like a dict > > Could we raise an exception now instead of waiting for 3.5? Fixing the > plugins is nothing hard, you know... We should discuss this next year, when people come back from holidays. -- Petr? From rmeggins at redhat.com Mon Dec 16 14:50:28 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 07:50:28 -0700 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <52AEDFC6.30207@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> <20131216095258.GK21264@redhat.com> <52AEDFC6.30207@redhat.com> Message-ID: <52AF1334.7060205@redhat.com> On 12/16/2013 04:11 AM, Petr Viktorin wrote: > On 12/16/2013 10:52 AM, Alexander Bokovoy wrote: >> On Mon, 16 Dec 2013, Petr Viktorin wrote: >>> On 12/13/2013 03:22 PM, Rich Megginson wrote: >>>> On 12/13/2013 02:45 AM, Petr Viktorin wrote: >>>>> I finally got to investigating this failure. >>>>> >>>>> It seems ou, along with a bunch of other attributes, is missing from >>>>> organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >>>>> we don't define organizationalPerson. >>>>> Nathan, could it be related to the new schema parser? >>>> >>>> Yes, looks like it. >>> >>> Thanks for filing the bug, sorry I didn't get to it on Friday. >>> >>> URL for the record: https://fedorahosted.org/389/ticket/47631 >> Should we consider this a release blocker for tomorrow's Fedora 20 >> release? Yes. >> >> At the very least this bug has to be fixed and the fix pushed to F20 >> as soon as possible. Yes. > > AFAIU 389-ds will get a downgrade for f20, complete with an epoch bump. > We are having a meeting today to decide this issue. From pspacek at redhat.com Mon Dec 16 15:07:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Dec 2013 16:07:54 +0100 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF0236.3030907@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> Message-ID: <52AF174A.4060104@redhat.com> Hello list, we have to decide what we will do with 389-ds-base package in Fedora 20. Currently, we know about following problems: Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Replication: https://fedorahosted.org/389/ticket/47632 (?) Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) One option is to fix 1.3.2.x as quickly as possible. Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as quickly as possible. The problem with downgrade to 1.3.1.x is that it requires manual change in dse.ldif file. You have to disable 'content synchronization' (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but were added and enabled by 1.3.2.x packages. In our tests, the downgraded DS server starts and works after manual dse.ldif correction (but be careful - we didn't test replication). Here is the main problem: 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way how to replace it there. It means that somebody can do F19->F20 upgrade from ISO and *then* upgrade from repos will break his DS configuration (because of new plugins...). Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x inevitably needs automated script which will purge two missing plugins from dse.ldif. Nathan, is it manageable before Christmas? One or either way? Is you think that the downgrade is safe from data format perspective? (I mean DB format upgrades etc.?) -- Petr^2 Spacek From pviktori at redhat.com Mon Dec 16 15:46:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Dec 2013 16:46:58 +0100 Subject: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1 Message-ID: <52AF2072.9030905@redhat.com> Hello, Honza found a failure in the new permission plugin when ipasearchrecordslimit is set to -1. Here is a fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0346-permission_find-Do-not-fail-for-ipasearchrecordslimi.patch Type: text/x-patch Size: 1252 bytes Desc: not available URL: From jcholast at redhat.com Mon Dec 16 15:55:35 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Dec 2013 16:55:35 +0100 Subject: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1 In-Reply-To: <52AF2072.9030905@redhat.com> References: <52AF2072.9030905@redhat.com> Message-ID: <52AF2277.7090204@redhat.com> Hi, On 16.12.2013 16:46, Petr Viktorin wrote: > Hello, > Honza found a failure in the new permission plugin when > ipasearchrecordslimit is set to -1. Here is a fix. > Judging from LDAPSearch.find_entries, it seems that 0 also means unlimited, so I think "if len(entries) > max_entries > 0" might be safer here. Honza -- Jan Cholasta From rmeggins at redhat.com Mon Dec 16 16:05:32 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 09:05:32 -0700 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <1387209607.2611.100.camel@adam.happyassassin.net> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> <20131216095258.GK21264@redhat.com> <1387209607.2611.100.camel@adam.happyassassin.net> Message-ID: <52AF24CC.7080001@redhat.com> On 12/16/2013 09:00 AM, Adam Williamson wrote: > On Mon, 2013-12-16 at 11:52 +0200, Alexander Bokovoy wrote: >> On Mon, 16 Dec 2013, Petr Viktorin wrote: >>> On 12/13/2013 03:22 PM, Rich Megginson wrote: >>>> On 12/13/2013 02:45 AM, Petr Viktorin wrote: >>>>> I finally got to investigating this failure. >>>>> >>>>> It seems ou, along with a bunch of other attributes, is missing from >>>>> organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >>>>> we don't define organizationalPerson. >>>>> Nathan, could it be related to the new schema parser? >>>> Yes, looks like it. >>> Thanks for filing the bug, sorry I didn't get to it on Friday. >>> >>> URL for the record: https://fedorahosted.org/389/ticket/47631 >> Should we consider this a release blocker for tomorrow's Fedora 20 >> release? > You'll need a TARDIS; we signed off on it on Thursday, and nothing stops > the Fedora release train (at least, nothing short of epic data loss, > this seems well short). The schema problem could have serious repercussions. So what are our options for getting a stable 389-ds-base into F20? > >> At the very least this bug has to be fixed and the fix pushed to F20 >> as soon as possible. > Indeed, is there an RHBZ for me to link a commonbugs note to? From rmeggins at redhat.com Mon Dec 16 16:09:23 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 09:09:23 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF174A.4060104@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> Message-ID: <52AF25B3.9040708@redhat.com> On 12/16/2013 08:07 AM, Petr Spacek wrote: > Hello list, > > we have to decide what we will do with 389-ds-base package in Fedora 20. > > Currently, we know about following problems: > > Schema problems: > https://fedorahosted.org/389/ticket/47631 (regression) > > Referential Integrity: > https://fedorahosted.org/389/ticket/47621 (new functionality) > https://fedorahosted.org/389/ticket/47624 (regression) > > Replication: > https://fedorahosted.org/389/ticket/47632 (?) > > Stability: > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 > https://fedorahosted.org/389/ticket/47629 (we are not sure if the > syncrepl really plays some role or not) > > One option is to fix 1.3.2.x as quickly as possible. > > Another option is to build 1.3.1.x for F20 with Epoch == 1 and release > it as quickly as possible. > > The problem with downgrade to 1.3.1.x is that it requires manual > change in dse.ldif file. You have to disable 'content synchronization' > (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but > were added and enabled by 1.3.2.x packages. > > In our tests, the downgraded DS server starts and works after manual > dse.ldif correction (but be careful - we didn't test replication). > > Here is the main problem: > 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not > way how to replace it there. It means that somebody can do F19->F20 > upgrade from ISO and *then* upgrade from repos will break his DS > configuration (because of new plugins...). > > Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x > inevitably needs automated script which will purge two missing plugins > from dse.ldif. > > Nathan, is it manageable before Christmas? One or either way? Is you > think that the downgrade is safe from data format perspective? (I mean > DB format upgrades etc.?) > We will have a meeting at 11:30 AM US EST to discuss The number is the usual bridge (US Toll Free 18004518679 - 3150468279#) From abokovoy at redhat.com Mon Dec 16 16:10:06 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 18:10:06 +0200 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <1387209607.2611.100.camel@adam.happyassassin.net> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> <20131216095258.GK21264@redhat.com> <1387209607.2611.100.camel@adam.happyassassin.net> Message-ID: <20131216161006.GN21264@redhat.com> On Mon, 16 Dec 2013, Adam Williamson wrote: >On Mon, 2013-12-16 at 11:52 +0200, Alexander Bokovoy wrote: >> On Mon, 16 Dec 2013, Petr Viktorin wrote: >> >On 12/13/2013 03:22 PM, Rich Megginson wrote: >> >>On 12/13/2013 02:45 AM, Petr Viktorin wrote: >> >>>I finally got to investigating this failure. >> >>> >> >>>It seems ou, along with a bunch of other attributes, is missing from >> >>>organizationalPerson in Fedora 20. I don't think it's IPA's fault, as >> >>>we don't define organizationalPerson. >> >>>Nathan, could it be related to the new schema parser? >> >> >> >>Yes, looks like it. >> > >> >Thanks for filing the bug, sorry I didn't get to it on Friday. >> > >> >URL for the record: https://fedorahosted.org/389/ticket/47631 >> Should we consider this a release blocker for tomorrow's Fedora 20 >> release? > >You'll need a TARDIS; we signed off on it on Thursday, and nothing stops >the Fedora release train (at least, nothing short of epic data loss, >this seems well short). There is data loss, though not epic. One of bugs for 389-ds 1.3.2.x covers crashes during replication and ticket 47631 above covers schema corruption. >> At the very least this bug has to be fixed and the fix pushed to F20 >> as soon as possible. > >Indeed, is there an RHBZ for me to link a commonbugs note to? Schema problems: https://fedorahosted.org/389/ticket/47631 (regression) Referential Integrity: https://fedorahosted.org/389/ticket/47621 (new functionality) https://fedorahosted.org/389/ticket/47624 (regression) Replication: https://fedorahosted.org/389/ticket/47632 (?) Stability: https://bugzilla.redhat.com/show_bug.cgi?id=1041732 https://bugzilla.redhat.com/show_bug.cgi?id=1043546 https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl really plays some role or not) Not all of these have corresponding bugzilla entries yet but at least #1041732 and #1043546 should be linked. DS team will have meeting today to decide on proper strategy to fix -- either by downgrading to 1.3.1.x (unwelcome, needs configuration downgrade and we are not yet sure everything works afterwards) or fixing these bugs in 1.3.2.x branch. -- / Alexander Bokovoy From rmeggins at redhat.com Mon Dec 16 16:15:34 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 09:15:34 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF174A.4060104@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> Message-ID: <52AF2726.5030401@redhat.com> On 12/16/2013 08:07 AM, Petr Spacek wrote: > Hello list, > > we have to decide what we will do with 389-ds-base package in Fedora 20. > > Currently, we know about following problems: > > Schema problems: > https://fedorahosted.org/389/ticket/47631 (regression) Fixed. > > Referential Integrity: > https://fedorahosted.org/389/ticket/47621 (new functionality) Does it matter if new functionality is a problem? > https://fedorahosted.org/389/ticket/47624 (regression) > > Replication: > https://fedorahosted.org/389/ticket/47632 (?) > > Stability: > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. However, there is a problem with slapi-nis: https://bugzilla.redhat.com/show_bug.cgi?id=1043546 > https://fedorahosted.org/389/ticket/47629 (we are not sure if the > syncrepl really plays some role or not) How can we find out? > > One option is to fix 1.3.2.x as quickly as possible. > > Another option is to build 1.3.1.x for F20 with Epoch == 1 and release > it as quickly as possible. > > The problem with downgrade to 1.3.1.x is that it requires manual > change in dse.ldif file. You have to disable 'content synchronization' > (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but > were added and enabled by 1.3.2.x packages. > > In our tests, the downgraded DS server starts and works after manual > dse.ldif correction (but be careful - we didn't test replication). > > Here is the main problem: > 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not > way how to replace it there. It means that somebody can do F19->F20 > upgrade from ISO and *then* upgrade from repos will break his DS > configuration (because of new plugins...). > > Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x > inevitably needs automated script which will purge two missing plugins > from dse.ldif. We have an upgrade/downgrade framework, it should be easy to disable/remove these plugins. Is that it? Are there any other problems found attempting to downgrade 1.3.2 to 1.3.1 in F20? > > Nathan, is it manageable before Christmas? One or either way? Is you > think that the downgrade is safe from data format perspective? (I mean > DB format upgrades etc.?) The db format in 1.3.1 and 1.3.2 is the same, so there should be no problems there. From abokovoy at redhat.com Mon Dec 16 16:21:05 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 18:21:05 +0200 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF2726.5030401@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> Message-ID: <20131216162105.GO21264@redhat.com> On Mon, 16 Dec 2013, Rich Megginson wrote: >On 12/16/2013 08:07 AM, Petr Spacek wrote: >>Hello list, >> >>we have to decide what we will do with 389-ds-base package in Fedora 20. >> >>Currently, we know about following problems: >> >>Schema problems: >> https://fedorahosted.org/389/ticket/47631 (regression) > >Fixed. > >> >>Referential Integrity: >> https://fedorahosted.org/389/ticket/47621 (new functionality) > >Does it matter if new functionality is a problem? Only if there is a crash. > >>https://fedorahosted.org/389/ticket/47624 (regression) >> >>Replication: >> https://fedorahosted.org/389/ticket/47632 (?) >> >>Stability: >> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 > >Fixed. However, there is a problem with slapi-nis: >https://bugzilla.redhat.com/show_bug.cgi?id=1043546 slapi-nis part seems to be a double-free on plugin shutdown. I'll look into it tomorrow morning if Nalin will not find it earlier. >>https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>syncrepl really plays some role or not) > >How can we find out? > >> >>One option is to fix 1.3.2.x as quickly as possible. >> >>Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>release it as quickly as possible. >> >>The problem with downgrade to 1.3.1.x is that it requires manual >>change in dse.ldif file. You have to disable 'content >>synchronization' (syncrepl) and 'whoami' plugins which are not in >>1.3.1.x packages but were added and enabled by 1.3.2.x packages. >> >>In our tests, the downgraded DS server starts and works after >>manual dse.ldif correction (but be careful - we didn't test >>replication). >> >>Here is the main problem: >>389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is >>not way how to replace it there. It means that somebody can do >>F19->F20 upgrade from ISO and *then* upgrade from repos will break >>his DS configuration (because of new plugins...). >> >>Simo thinks that this is a reason why 'downgrade package' with >>1.3.1.x inevitably needs automated script which will purge two >>missing plugins from dse.ldif. > >We have an upgrade/downgrade framework, it should be easy to >disable/remove these plugins. > >Is that it? Are there any other problems found attempting to >downgrade 1.3.2 to 1.3.1 in F20? Packaging issue -- epoch will have to be increased and maintained forever. It is weird but that's what it is. And then making sure disabling the plugins will happen only on downgrade, this is actually an RPM trigger which is something people easily get wrong. >>Nathan, is it manageable before Christmas? One or either way? Is >>you think that the downgrade is safe from data format perspective? >>(I mean DB format upgrades etc.?) > >The db format in 1.3.1 and 1.3.2 is the same, so there should be no >problems there. > -- / Alexander Bokovoy From pspacek at redhat.com Mon Dec 16 16:26:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Dec 2013 17:26:39 +0100 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF2726.5030401@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> Message-ID: <52AF29BF.6050903@redhat.com> On 16.12.2013 17:15, Rich Megginson wrote: > On 12/16/2013 08:07 AM, Petr Spacek wrote: >> Hello list, >> >> we have to decide what we will do with 389-ds-base package in Fedora 20. >> >> Currently, we know about following problems: >> >> Schema problems: >> https://fedorahosted.org/389/ticket/47631 (regression) > > Fixed. > >> >> Referential Integrity: >> https://fedorahosted.org/389/ticket/47621 (new functionality) > > Does it matter if new functionality is a problem? I think that this is not a problem for now. I just copied it from Nathan's mail, I'm sorry for the noise! >> https://fedorahosted.org/389/ticket/47624 (regression) >> >> Replication: >> https://fedorahosted.org/389/ticket/47632 (?) >> >> Stability: >> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 > > Fixed. However, there is a problem with slapi-nis: > https://bugzilla.redhat.com/show_bug.cgi?id=1043546 Alexander is looking into it. >> https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl >> really plays some role or not) > > How can we find out? I can't find a way how to reproduce it. I have seen 3 crashes in one hour and then nothing for a day ... >> One option is to fix 1.3.2.x as quickly as possible. >> >> Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as >> quickly as possible. >> >> The problem with downgrade to 1.3.1.x is that it requires manual change in >> dse.ldif file. You have to disable 'content synchronization' (syncrepl) and >> 'whoami' plugins which are not in 1.3.1.x packages but were added and >> enabled by 1.3.2.x packages. >> >> In our tests, the downgraded DS server starts and works after manual >> dse.ldif correction (but be careful - we didn't test replication). >> >> Here is the main problem: >> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way >> how to replace it there. It means that somebody can do F19->F20 upgrade from >> ISO and *then* upgrade from repos will break his DS configuration (because >> of new plugins...). >> >> Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x >> inevitably needs automated script which will purge two missing plugins from >> dse.ldif. > > We have an upgrade/downgrade framework, it should be easy to disable/remove > these plugins. > > Is that it? Are there any other problems found attempting to downgrade 1.3.2 > to 1.3.1 in F20? Disabling plugins should be enough, we didn't find any other problem. >> Nathan, is it manageable before Christmas? One or either way? Is you think >> that the downgrade is safe from data format perspective? (I mean DB format >> upgrades etc.?) > > The db format in 1.3.1 and 1.3.2 is the same, so there should be no problems > there. Great. -- Petr^2 Spacek From rmeggins at redhat.com Mon Dec 16 16:28:49 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 09:28:49 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <20131216162105.GO21264@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> Message-ID: <52AF2A41.4010509@redhat.com> On 12/16/2013 09:21 AM, Alexander Bokovoy wrote: > On Mon, 16 Dec 2013, Rich Megginson wrote: >> On 12/16/2013 08:07 AM, Petr Spacek wrote: >>> Hello list, >>> >>> we have to decide what we will do with 389-ds-base package in Fedora >>> 20. >>> >>> Currently, we know about following problems: >>> >>> Schema problems: >>> https://fedorahosted.org/389/ticket/47631 (regression) >> >> Fixed. >> >>> >>> Referential Integrity: >>> https://fedorahosted.org/389/ticket/47621 (new functionality) >> >> Does it matter if new functionality is a problem? > Only if there is a crash. I don't think there is a crash here. > >> >>> https://fedorahosted.org/389/ticket/47624 (regression) >>> >>> Replication: >>> https://fedorahosted.org/389/ticket/47632 (?) >>> >>> Stability: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >> >> Fixed. However, there is a problem with slapi-nis: >> https://bugzilla.redhat.com/show_bug.cgi?id=1043546 > slapi-nis part seems to be a double-free on plugin shutdown. > I'll look into it tomorrow morning if Nalin will not find it earlier. > > >>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>> syncrepl really plays some role or not) >> >> How can we find out? >> >>> >>> One option is to fix 1.3.2.x as quickly as possible. >>> >>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>> release it as quickly as possible. >>> >>> The problem with downgrade to 1.3.1.x is that it requires manual >>> change in dse.ldif file. You have to disable 'content >>> synchronization' (syncrepl) and 'whoami' plugins which are not in >>> 1.3.1.x packages but were added and enabled by 1.3.2.x packages. >>> >>> In our tests, the downgraded DS server starts and works after manual >>> dse.ldif correction (but be careful - we didn't test replication). >>> >>> Here is the main problem: >>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is >>> not way how to replace it there. It means that somebody can do >>> F19->F20 upgrade from ISO and *then* upgrade from repos will break >>> his DS configuration (because of new plugins...). >>> >>> Simo thinks that this is a reason why 'downgrade package' with >>> 1.3.1.x inevitably needs automated script which will purge two >>> missing plugins from dse.ldif. >> >> We have an upgrade/downgrade framework, it should be easy to >> disable/remove these plugins. >> >> Is that it? Are there any other problems found attempting to >> downgrade 1.3.2 to 1.3.1 in F20? > Packaging issue -- epoch will have to be increased and maintained > forever. It is weird but that's what it is. Sure. But that's a one time thing. And, it's only for F20 - once we go to F21, we can remove the epoch. > And then making sure > disabling the plugins will happen only on downgrade, this is actually an > RPM trigger which is something people easily get wrong. I think it's simpler than that - if the version is 1.3.1, disable/remove the plugins. If the version is 1.3.2, add/enable the plugins. I don't think this will be a big deal. > > >>> Nathan, is it manageable before Christmas? One or either way? Is you >>> think that the downgrade is safe from data format perspective? (I >>> mean DB format upgrades etc.?) >> >> The db format in 1.3.1 and 1.3.2 is the same, so there should be no >> problems there. >> > From jcholast at redhat.com Mon Dec 16 16:31:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Dec 2013 17:31:21 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1386965729.1948.13.camel@localhost.localdomain> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> Message-ID: <52AF2AD9.2080500@redhat.com> On 13.12.2013 21:15, Nathaniel McCallum wrote: > On Fri, 2013-12-13 at 14:50 -0500, Nathaniel McCallum wrote: >> On Wed, 2013-12-11 at 13:24 +0100, Jan Cholasta wrote: >>> + # Resolve the user's dn >>> + owner = entry_attrs.get('ipatokenowner', None) >>> + if owner is not None: >>> + owner = self.api.Object.user.get_dn(owner) >>> + entry_attrs['ipatokenowner'] = owner >>> >>> You have a _normalize_owner function, I think the code above should go >>> into a _convert_owner function (use the function in >>> otptoken_{mod,show,find} as well). >> >> Fixed for mod and find. Show doesn't make sense. Please rename _normalize_owner to _convert_owner and vice versa, to match the convention used in other plugins (sorry for noticing this earlier). This bit in otptoken_add should be replaced by a call to _normalize_owner (after the rename): + # Resolve the user's dn + owner = entry_attrs.get('ipatokenowner', None) + if owner is not None: + owner = self.api.Object.user.get_dn(owner) + entry_attrs['ipatokenowner'] = owner You do the conversion from uid to DN in otptoken_find twice: + _convert_owner(self.api.Object.user, kwargs) + return super(otptoken_find, self).pre_callback(ldap, filters, *args, **kwargs) + + def args_options_2_entry(self, *args, **options): + o = 'ipatokenowner' + if o in options: + options[o] = self.api.Object.user.get_dn(options[o]) I would suggest to do it only in args_options_2_entry like this (again, after the rename): def args_options_2_entry(self, *args, **options): entry = super(otptoken_find, self).args_options_2_entry(*args, **options) _convert_owner(self.api.Object.user, entry) return entry >>> + # Delete all tokens owned by this user >>> + owner = self.api.Object.user.get_primary_key_from_dn(dn) >>> + results = >>> self.api.Command.otptoken_find(ipatokenowner=owner)['result'] >>> + for token in results: >>> + token = >>> self.api.Object.otptoken.get_primary_key_from_dn(token['dn']) >>> + self.api.Command.otptoken_del(token) >>> >>> This should probably be handled by the referint plugin. >> >> See my reply to Martin. I see, my mistake. > > ARGH! I should try not to break stuff. New patch attached... > The patch needs a rebase (for the sake of ipapermlocation default value). -- Jan Cholasta From abokovoy at redhat.com Mon Dec 16 16:33:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 18:33:52 +0200 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF2A41.4010509@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> Message-ID: <20131216163352.GP21264@redhat.com> On Mon, 16 Dec 2013, Rich Megginson wrote: >On 12/16/2013 09:21 AM, Alexander Bokovoy wrote: >>On Mon, 16 Dec 2013, Rich Megginson wrote: >>>On 12/16/2013 08:07 AM, Petr Spacek wrote: >>>>Hello list, >>>> >>>>we have to decide what we will do with 389-ds-base package in >>>>Fedora 20. >>>> >>>>Currently, we know about following problems: >>>> >>>>Schema problems: >>>> https://fedorahosted.org/389/ticket/47631 (regression) >>> >>>Fixed. >>> >>>> >>>>Referential Integrity: >>>> https://fedorahosted.org/389/ticket/47621 (new functionality) >>> >>>Does it matter if new functionality is a problem? >>Only if there is a crash. > >I don't think there is a crash here. > >> >>> >>>>https://fedorahosted.org/389/ticket/47624 (regression) >>>> >>>>Replication: >>>> https://fedorahosted.org/389/ticket/47632 (?) >>>> >>>>Stability: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >>> >>>Fixed. However, there is a problem with slapi-nis: >>>https://bugzilla.redhat.com/show_bug.cgi?id=1043546 >>slapi-nis part seems to be a double-free on plugin shutdown. >>I'll look into it tomorrow morning if Nalin will not find it earlier. >> >> >>>>https://fedorahosted.org/389/ticket/47629 (we are not sure if >>>>the syncrepl really plays some role or not) >>> >>>How can we find out? >>> >>>> >>>>One option is to fix 1.3.2.x as quickly as possible. >>>> >>>>Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>>>release it as quickly as possible. >>>> >>>>The problem with downgrade to 1.3.1.x is that it requires >>>>manual change in dse.ldif file. You have to disable 'content >>>>synchronization' (syncrepl) and 'whoami' plugins which are not >>>>in 1.3.1.x packages but were added and enabled by 1.3.2.x >>>>packages. >>>> >>>>In our tests, the downgraded DS server starts and works after >>>>manual dse.ldif correction (but be careful - we didn't test >>>>replication). >>>> >>>>Here is the main problem: >>>>389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there >>>>is not way how to replace it there. It means that somebody can >>>>do F19->F20 upgrade from ISO and *then* upgrade from repos will >>>>break his DS configuration (because of new plugins...). >>>> >>>>Simo thinks that this is a reason why 'downgrade package' with >>>>1.3.1.x inevitably needs automated script which will purge two >>>>missing plugins from dse.ldif. >>> >>>We have an upgrade/downgrade framework, it should be easy to >>>disable/remove these plugins. >>> >>>Is that it? Are there any other problems found attempting to >>>downgrade 1.3.2 to 1.3.1 in F20? >>Packaging issue -- epoch will have to be increased and maintained >>forever. It is weird but that's what it is. > >Sure. But that's a one time thing. And, it's only for F20 - once we >go to F21, we can remove the epoch. No, and that's key here. Once Epoch is in place, it is forever. >>And then making sure >>disabling the plugins will happen only on downgrade, this is actually an >>RPM trigger which is something people easily get wrong. > >I think it's simpler than that - if the version is 1.3.1, >disable/remove the plugins. If the version is 1.3.2, add/enable the >plugins. I don't think this will be a big deal. Ok, fine. -- / Alexander Bokovoy From rmeggins at redhat.com Mon Dec 16 16:42:57 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 09:42:57 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <20131216163352.GP21264@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> Message-ID: <52AF2D91.90404@redhat.com> On 12/16/2013 09:33 AM, Alexander Bokovoy wrote: > On Mon, 16 Dec 2013, Rich Megginson wrote: >> On 12/16/2013 09:21 AM, Alexander Bokovoy wrote: >>> On Mon, 16 Dec 2013, Rich Megginson wrote: >>>> On 12/16/2013 08:07 AM, Petr Spacek wrote: >>>>> Hello list, >>>>> >>>>> we have to decide what we will do with 389-ds-base package in >>>>> Fedora 20. >>>>> >>>>> Currently, we know about following problems: >>>>> >>>>> Schema problems: >>>>> https://fedorahosted.org/389/ticket/47631 (regression) >>>> >>>> Fixed. >>>> >>>>> >>>>> Referential Integrity: >>>>> https://fedorahosted.org/389/ticket/47621 (new functionality) >>>> >>>> Does it matter if new functionality is a problem? >>> Only if there is a crash. >> >> I don't think there is a crash here. >> >>> >>>> >>>>> https://fedorahosted.org/389/ticket/47624 (regression) >>>>> >>>>> Replication: >>>>> https://fedorahosted.org/389/ticket/47632 (?) >>>>> >>>>> Stability: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >>>> >>>> Fixed. However, there is a problem with slapi-nis: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1043546 >>> slapi-nis part seems to be a double-free on plugin shutdown. >>> I'll look into it tomorrow morning if Nalin will not find it earlier. >>> >>> >>>>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>>>> syncrepl really plays some role or not) >>>> >>>> How can we find out? >>>> >>>>> >>>>> One option is to fix 1.3.2.x as quickly as possible. >>>>> >>>>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>>>> release it as quickly as possible. >>>>> >>>>> The problem with downgrade to 1.3.1.x is that it requires manual >>>>> change in dse.ldif file. You have to disable 'content >>>>> synchronization' (syncrepl) and 'whoami' plugins which are not in >>>>> 1.3.1.x packages but were added and enabled by 1.3.2.x packages. >>>>> >>>>> In our tests, the downgraded DS server starts and works after >>>>> manual dse.ldif correction (but be careful - we didn't test >>>>> replication). >>>>> >>>>> Here is the main problem: >>>>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is >>>>> not way how to replace it there. It means that somebody can do >>>>> F19->F20 upgrade from ISO and *then* upgrade from repos will break >>>>> his DS configuration (because of new plugins...). >>>>> >>>>> Simo thinks that this is a reason why 'downgrade package' with >>>>> 1.3.1.x inevitably needs automated script which will purge two >>>>> missing plugins from dse.ldif. >>>> >>>> We have an upgrade/downgrade framework, it should be easy to >>>> disable/remove these plugins. >>>> >>>> Is that it? Are there any other problems found attempting to >>>> downgrade 1.3.2 to 1.3.1 in F20? >>> Packaging issue -- epoch will have to be increased and maintained >>> forever. It is weird but that's what it is. >> >> Sure. But that's a one time thing. And, it's only for F20 - once we >> go to F21, we can remove the epoch. > No, and that's key here. Once Epoch is in place, it is forever. Why? > > >>> And then making sure >>> disabling the plugins will happen only on downgrade, this is >>> actually an >>> RPM trigger which is something people easily get wrong. >> >> I think it's simpler than that - if the version is 1.3.1, >> disable/remove the plugins. If the version is 1.3.2, add/enable the >> plugins. I don't think this will be a big deal. > Ok, fine. > From abokovoy at redhat.com Mon Dec 16 16:55:28 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 18:55:28 +0200 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF2D91.90404@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> Message-ID: <20131216165528.GR21264@redhat.com> On Mon, 16 Dec 2013, Rich Megginson wrote: >>>>>>Simo thinks that this is a reason why 'downgrade package' >>>>>>with 1.3.1.x inevitably needs automated script which will >>>>>>purge two missing plugins from dse.ldif. >>>>> >>>>>We have an upgrade/downgrade framework, it should be easy to >>>>>disable/remove these plugins. >>>>> >>>>>Is that it? Are there any other problems found attempting to >>>>>downgrade 1.3.2 to 1.3.1 in F20? >>>>Packaging issue -- epoch will have to be increased and maintained >>>>forever. It is weird but that's what it is. >>> >>>Sure. But that's a one time thing. And, it's only for F20 - >>>once we go to F21, we can remove the epoch. >>No, and that's key here. Once Epoch is in place, it is forever. > >Why? Because that's how RPM is built. When Epoch value is absent it is assumed to be equal to 0. 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1, however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter is equal to 0:1.3.2.8-1. Once epoch is there, it is to stay. -- / Alexander Bokovoy From npmccallum at redhat.com Mon Dec 16 17:01:36 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 16 Dec 2013 12:01:36 -0500 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52AF2AD9.2080500@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> <52AF2AD9.2080500@redhat.com> Message-ID: <1387213296.1948.76.camel@localhost.localdomain> On Mon, 2013-12-16 at 17:31 +0100, Jan Cholasta wrote: > On 13.12.2013 21:15, Nathaniel McCallum wrote: > > On Fri, 2013-12-13 at 14:50 -0500, Nathaniel McCallum wrote: > >> On Wed, 2013-12-11 at 13:24 +0100, Jan Cholasta wrote: > >>> + # Resolve the user's dn > >>> + owner = entry_attrs.get('ipatokenowner', None) > >>> + if owner is not None: > >>> + owner = self.api.Object.user.get_dn(owner) > >>> + entry_attrs['ipatokenowner'] = owner > >>> > >>> You have a _normalize_owner function, I think the code above should go > >>> into a _convert_owner function (use the function in > >>> otptoken_{mod,show,find} as well). > >> > >> Fixed for mod and find. Show doesn't make sense. > > Please rename _normalize_owner to _convert_owner and vice versa, to > match the convention used in other plugins (sorry for noticing this > earlier). Fixed. > This bit in otptoken_add should be replaced by a call to > _normalize_owner (after the rename): > > + # Resolve the user's dn > + owner = entry_attrs.get('ipatokenowner', None) > + if owner is not None: > + owner = self.api.Object.user.get_dn(owner) > + entry_attrs['ipatokenowner'] = owner Fixed. > You do the conversion from uid to DN in otptoken_find twice: > > + _convert_owner(self.api.Object.user, kwargs) > + return super(otptoken_find, self).pre_callback(ldap, filters, > *args, **kwargs) > + > + def args_options_2_entry(self, *args, **options): > + o = 'ipatokenowner' > + if o in options: > + options[o] = self.api.Object.user.get_dn(options[o]) > > I would suggest to do it only in args_options_2_entry like this (again, > after the rename): > > def args_options_2_entry(self, *args, **options): > entry = super(otptoken_find, self).args_options_2_entry(*args, > **options) > _convert_owner(self.api.Object.user, entry) > return entry Fixed. > The patch needs a rebase (for the sake of ipapermlocation default value). Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-6-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 28442 bytes Desc: not available URL: From pspacek at redhat.com Mon Dec 16 17:12:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Dec 2013 18:12:13 +0100 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <20131216165528.GR21264@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> Message-ID: <52AF346D.4070905@redhat.com> On 16.12.2013 17:55, Alexander Bokovoy wrote: > On Mon, 16 Dec 2013, Rich Megginson wrote: >>>>>>> Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x >>>>>>> inevitably needs automated script which will purge two missing plugins >>>>>>> from dse.ldif. >>>>>> >>>>>> We have an upgrade/downgrade framework, it should be easy to >>>>>> disable/remove these plugins. >>>>>> >>>>>> Is that it? Are there any other problems found attempting to downgrade >>>>>> 1.3.2 to 1.3.1 in F20? >>>>> Packaging issue -- epoch will have to be increased and maintained >>>>> forever. It is weird but that's what it is. >>>> >>>> Sure. But that's a one time thing. And, it's only for F20 - once we go >>>> to F21, we can remove the epoch. >>> No, and that's key here. Once Epoch is in place, it is forever. >> >> Why? > Because that's how RPM is built. When Epoch value is absent it is > assumed to be equal to 0. > 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1, > however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter > is equal to 0:1.3.2.8-1. > > Once epoch is there, it is to stay. Anyway, is it a real problem? Personally, I consider it like yet-another-version-number. On my Fedora 19: $ repoquery -qa | wc -l 46645 (packages in total) $ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l 6581 (packages with non-zero epoch) -- Petr^2 Spacek From rmeggins at redhat.com Mon Dec 16 17:16:11 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 10:16:11 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF346D.4070905@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> <52AF346D.4070905@redhat.com> Message-ID: <52AF355B.8070903@redhat.com> On 12/16/2013 10:12 AM, Petr Spacek wrote: > On 16.12.2013 17:55, Alexander Bokovoy wrote: >> On Mon, 16 Dec 2013, Rich Megginson wrote: >>>>>>>> Simo thinks that this is a reason why 'downgrade package' with >>>>>>>> 1.3.1.x >>>>>>>> inevitably needs automated script which will purge two missing >>>>>>>> plugins >>>>>>>> from dse.ldif. >>>>>>> >>>>>>> We have an upgrade/downgrade framework, it should be easy to >>>>>>> disable/remove these plugins. >>>>>>> >>>>>>> Is that it? Are there any other problems found attempting to >>>>>>> downgrade >>>>>>> 1.3.2 to 1.3.1 in F20? >>>>>> Packaging issue -- epoch will have to be increased and maintained >>>>>> forever. It is weird but that's what it is. >>>>> >>>>> Sure. But that's a one time thing. And, it's only for F20 - once >>>>> we go >>>>> to F21, we can remove the epoch. >>>> No, and that's key here. Once Epoch is in place, it is forever. >>> >>> Why? >> Because that's how RPM is built. When Epoch value is absent it is >> assumed to be equal to 0. >> 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1, >> however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter >> is equal to 0:1.3.2.8-1. >> >> Once epoch is there, it is to stay. > > Anyway, is it a real problem? Personally, I consider it like > yet-another-version-number. > > On my Fedora 19: > $ repoquery -qa | wc -l > 46645 > (packages in total) > > $ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l > 6581 > (packages with non-zero epoch) > No, not a real problem, but just one more hassle I'd rather not have to deal with. From awilliam at redhat.com Mon Dec 16 16:00:07 2013 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 16 Dec 2013 08:00:07 -0800 Subject: [Freeipa-devel] ou, st, l missing from organizationalPerson In-Reply-To: <20131216095258.GK21264@redhat.com> References: <5284EFDF.4060702@redhat.com> <52AAD726.2030105@redhat.com> <52AB1809.7040305@redhat.com> <52AEC80E.1000003@redhat.com> <20131216095258.GK21264@redhat.com> Message-ID: <1387209607.2611.100.camel@adam.happyassassin.net> On Mon, 2013-12-16 at 11:52 +0200, Alexander Bokovoy wrote: > On Mon, 16 Dec 2013, Petr Viktorin wrote: > >On 12/13/2013 03:22 PM, Rich Megginson wrote: > >>On 12/13/2013 02:45 AM, Petr Viktorin wrote: > >>>I finally got to investigating this failure. > >>> > >>>It seems ou, along with a bunch of other attributes, is missing from > >>>organizationalPerson in Fedora 20. I don't think it's IPA's fault, as > >>>we don't define organizationalPerson. > >>>Nathan, could it be related to the new schema parser? > >> > >>Yes, looks like it. > > > >Thanks for filing the bug, sorry I didn't get to it on Friday. > > > >URL for the record: https://fedorahosted.org/389/ticket/47631 > Should we consider this a release blocker for tomorrow's Fedora 20 > release? You'll need a TARDIS; we signed off on it on Thursday, and nothing stops the Fedora release train (at least, nothing short of epic data loss, this seems well short). > At the very least this bug has to be fixed and the fix pushed to F20 > as soon as possible. Indeed, is there an RHBZ for me to link a commonbugs note to? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net From simo at redhat.com Mon Dec 16 20:14:06 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Dec 2013 15:14:06 -0500 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF355B.8070903@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> <52AF346D.4070905@redhat.com> <52AF355B.8070903@redhat.com> Message-ID: <1387224846.19564.248.camel@willson.li.ssimo.org> On Mon, 2013-12-16 at 10:16 -0700, Rich Megginson wrote: > On 12/16/2013 10:12 AM, Petr Spacek wrote: > > On 16.12.2013 17:55, Alexander Bokovoy wrote: > >> On Mon, 16 Dec 2013, Rich Megginson wrote: > >>>>>>>> Simo thinks that this is a reason why 'downgrade package' with > >>>>>>>> 1.3.1.x > >>>>>>>> inevitably needs automated script which will purge two missing > >>>>>>>> plugins > >>>>>>>> from dse.ldif. > >>>>>>> > >>>>>>> We have an upgrade/downgrade framework, it should be easy to > >>>>>>> disable/remove these plugins. > >>>>>>> > >>>>>>> Is that it? Are there any other problems found attempting to > >>>>>>> downgrade > >>>>>>> 1.3.2 to 1.3.1 in F20? > >>>>>> Packaging issue -- epoch will have to be increased and maintained > >>>>>> forever. It is weird but that's what it is. > >>>>> > >>>>> Sure. But that's a one time thing. And, it's only for F20 - once > >>>>> we go > >>>>> to F21, we can remove the epoch. > >>>> No, and that's key here. Once Epoch is in place, it is forever. > >>> > >>> Why? > >> Because that's how RPM is built. When Epoch value is absent it is > >> assumed to be equal to 0. > >> 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1, > >> however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter > >> is equal to 0:1.3.2.8-1. > >> > >> Once epoch is there, it is to stay. > > > > Anyway, is it a real problem? Personally, I consider it like > > yet-another-version-number. > > > > On my Fedora 19: > > $ repoquery -qa | wc -l > > 46645 > > (packages in total) > > > > $ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l > > 6581 > > (packages with non-zero epoch) > > > No, not a real problem, but just one more hassle I'd rather not have to > deal with. Yes it is a real problem, it is extremely confusing to people, because it is not in the rpm file name. It should be avoided if at all possible, and it is an unremovable tattoo once you have it on. So a decision to add an epoch number should never be taken lightly. If you do not understand why, you should probably not set epochs. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Dec 16 20:48:26 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Dec 2013 13:48:26 -0700 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <1387224846.19564.248.camel@willson.li.ssimo.org> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> <52AF346D.4070905@redhat.com> <52AF355B.8070903@redhat.com> <1387224846.19564.248.camel@willson.li.ssimo.org> Message-ID: <52AF671A.4010904@redhat.com> On 12/16/2013 01:14 PM, Simo Sorce wrote: > On Mon, 2013-12-16 at 10:16 -0700, Rich Megginson wrote: >> On 12/16/2013 10:12 AM, Petr Spacek wrote: >>> On 16.12.2013 17:55, Alexander Bokovoy wrote: >>>> On Mon, 16 Dec 2013, Rich Megginson wrote: >>>>>>>>>> Simo thinks that this is a reason why 'downgrade package' with >>>>>>>>>> 1.3.1.x >>>>>>>>>> inevitably needs automated script which will purge two missing >>>>>>>>>> plugins >>>>>>>>>> from dse.ldif. >>>>>>>>> We have an upgrade/downgrade framework, it should be easy to >>>>>>>>> disable/remove these plugins. >>>>>>>>> >>>>>>>>> Is that it? Are there any other problems found attempting to >>>>>>>>> downgrade >>>>>>>>> 1.3.2 to 1.3.1 in F20? >>>>>>>> Packaging issue -- epoch will have to be increased and maintained >>>>>>>> forever. It is weird but that's what it is. >>>>>>> Sure. But that's a one time thing. And, it's only for F20 - once >>>>>>> we go >>>>>>> to F21, we can remove the epoch. >>>>>> No, and that's key here. Once Epoch is in place, it is forever. >>>>> Why? >>>> Because that's how RPM is built. When Epoch value is absent it is >>>> assumed to be equal to 0. >>>> 1.3.1.18-1 will be equal to 0:1.3.1.18-1 and less than 1.3.2.8-1, >>>> however, 1:1.3.1.18-1 will be greater than 1.3.2.8-1 because the latter >>>> is equal to 0:1.3.2.8-1. >>>> >>>> Once epoch is there, it is to stay. >>> Anyway, is it a real problem? Personally, I consider it like >>> yet-another-version-number. >>> >>> On my Fedora 19: >>> $ repoquery -qa | wc -l >>> 46645 >>> (packages in total) >>> >>> $ repoquery -qa | grep -- '-[1-9][0-9]*:' | wc -l >>> 6581 >>> (packages with non-zero epoch) >>> >> No, not a real problem, but just one more hassle I'd rather not have to >> deal with. > Yes it is a real problem, it is extremely confusing to people, because > it is not in the rpm file name. > > It should be avoided if at all possible, and it is an unremovable tattoo > once you have it on. > > So a decision to add an epoch number should never be taken lightly. > > If you do not understand why, you should probably not set epochs. Ok. We're going to try to fix the bugs in 1.3.2 ASAP, and do some testing in F20. I have some 1.3.2.9 packages for F20 here: http://rmeggins.fedorapeople.org/rpms/ 1.3.2.9 fixes the following issues: - Ticket #47631 objectclass may, must lists skip rest of objectclass once first is found in sup -- NOTE: this is the schema issue - Ticket 47627 - Fix replication logging - Ticket #47313 - Indexed search with filter containing '&' and "!" with attribute subtypes gives wrong result -- NOTE: this is one of the crashing issues (not the crash that appears to be syncrepl related) - Ticket 47613 - Issues setting allowed mechanisms - Ticket 47617 - allow configuring changelog trim interval - Ticket 47601 - Plugin library path validation prevents intentional loading of out-of-tree modules - Ticket 47627 - changelog iteration should ignore cleaned rids when getting the minCSN - Ticket #47623 fix memleak caused by 47347 - Ticket 47622 - Automember betxnpreoperation - transaction not aborted when group entry does not exist - Ticket 47620 - 389-ds rejects nsds5ReplicaProtocolTimeout attribute I'm trying to use copr to set up a repo: http://copr.fedoraproject.org/coprs/rmeggins/389-ds-base-testing/repo/fedora-20-x86_64/ but copr seems to be having some issues. I also have a patch for 1:389-ds-base-1.3.1.16 for F20 ready to go - I tested upgrade from 1.3.2.7 on F20, works fine, disables whoami and syncrepl. > > Simo. > > From npmccallum at redhat.com Mon Dec 16 21:12:29 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 16 Dec 2013 16:12:29 -0500 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode Message-ID: <1387228349.1948.83.camel@localhost.localdomain> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0026-Enable-building-in-C99-mode.patch Type: text/x-patch Size: 703 bytes Desc: not available URL: From tbabej at redhat.com Mon Dec 16 23:42:42 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Dec 2013 00:42:42 +0100 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF671A.4010904@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> <52AF346D.4070905@redhat.com> <52AF355B.8070903@redhat.com> <1387224846.19564.248.camel@willson.li.ssimo.org> <52AF671A.4010904@redhat.com> Message-ID: <52AF8FF2.9030505@redhat.com> Good news! With slapi-nis-0.52-1 and 389-ds-base-1.3.2.9-1 I can no longer reproduce neither of https://bugzilla.redhat.com/show_bug.cgi?id=1043546 or https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Thanks Rich, Nalin (or anyone else involved)! I will move to some more heavyweight testing in F20 first thing tomorrow morning, as it is already past midnight here. But at least we got rid of immediate post-install crashes. Tomas > Ok. We're going to try to fix the bugs in 1.3.2 ASAP, and do some > testing in F20. > > I have some 1.3.2.9 packages for F20 here: > http://rmeggins.fedorapeople.org/rpms/ > > 1.3.2.9 fixes the following issues: > - Ticket #47631 objectclass may, must lists skip rest of objectclass > once first is found in sup > -- NOTE: this is the schema issue > - Ticket 47627 - Fix replication logging > - Ticket #47313 - Indexed search with filter containing '&' and "!" > with attribute subtypes gives wrong result > -- NOTE: this is one of the crashing issues (not the crash that > appears to be syncrepl related) > - Ticket 47613 - Issues setting allowed mechanisms > - Ticket 47617 - allow configuring changelog trim interval > - Ticket 47601 - Plugin library path validation prevents intentional > loading of out-of-tree modules > - Ticket 47627 - changelog iteration should ignore cleaned rids when > getting the minCSN > - Ticket #47623 fix memleak caused by 47347 > - Ticket 47622 - Automember betxnpreoperation - transaction not > aborted when group entry does not exist > - Ticket 47620 - 389-ds rejects nsds5ReplicaProtocolTimeout attribute > > > I'm trying to use copr to set up a repo: > http://copr.fedoraproject.org/coprs/rmeggins/389-ds-base-testing/repo/fedora-20-x86_64/ > but copr seems to be having some issues. > > I also have a patch for 1:389-ds-base-1.3.1.16 for F20 ready to go - I > tested upgrade from 1.3.2.7 on F20, works fine, disables whoami and > syncrepl. > >> >> Simo. >> >> > From nkinder at redhat.com Tue Dec 17 00:06:32 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 16 Dec 2013 16:06:32 -0800 Subject: [Freeipa-devel] Fedora 20 Release In-Reply-To: <52AF8FF2.9030505@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52AF2726.5030401@redhat.com> <20131216162105.GO21264@redhat.com> <52AF2A41.4010509@redhat.com> <20131216163352.GP21264@redhat.com> <52AF2D91.90404@redhat.com> <20131216165528.GR21264@redhat.com> <52AF346D.4070905@redhat.com> <52AF355B.8070903@redhat.com> <1387224846.19564.248.camel@willson.li.ssimo.org> <52AF671A.4010904@redhat.com> <52AF8FF2.9030505@redhat.com> Message-ID: <52AF9588.9020509@redhat.com> On 12/16/2013 03:42 PM, Tomas Babej wrote: > Good news! > > With slapi-nis-0.52-1 and 389-ds-base-1.3.2.9-1 I can no longer > reproduce neither of > > https://bugzilla.redhat.com/show_bug.cgi?id=1043546 > > or > > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 > > Thanks Rich, Nalin (or anyone else involved)! > > I will move to some more heavyweight testing in F20 first thing tomorrow > morning, as it is already past midnight here. But at least we got rid of > immediate post-install crashes. Great! Thanks for confirming these fixes. That leaves the syncrepl related(?) crash that Petr encountered, and the GSSAPI replication issues that Honza encountered: https://fedorahosted.org/389/ticket/47629 (syncrepl crash) https://fedorahosted.org/389/ticket/47632 (GSSAPI replication) Is it possible to simply disable syncrepl to avoid the crash until we can pin down the cause/fix? It seems like this should be a viable approach since we were discussing using 389-ds-base-1.3.1, which doesn't even have syncrepl support. Has it been confirmed that the crash does not occur if syncrepl is not used? Rich has been unable to reproduce the GSSAPI replication issues. It would be great if we can get access to an environment where the problem occurs. Thanks, -NGK > > Tomas > >> Ok. We're going to try to fix the bugs in 1.3.2 ASAP, and do some >> testing in F20. >> >> I have some 1.3.2.9 packages for F20 here: >> http://rmeggins.fedorapeople.org/rpms/ >> >> 1.3.2.9 fixes the following issues: >> - Ticket #47631 objectclass may, must lists skip rest of objectclass >> once first is found in sup >> -- NOTE: this is the schema issue >> - Ticket 47627 - Fix replication logging >> - Ticket #47313 - Indexed search with filter containing '&' and "!" >> with attribute subtypes gives wrong result >> -- NOTE: this is one of the crashing issues (not the crash that >> appears to be syncrepl related) >> - Ticket 47613 - Issues setting allowed mechanisms >> - Ticket 47617 - allow configuring changelog trim interval >> - Ticket 47601 - Plugin library path validation prevents intentional >> loading of out-of-tree modules >> - Ticket 47627 - changelog iteration should ignore cleaned rids when >> getting the minCSN >> - Ticket #47623 fix memleak caused by 47347 >> - Ticket 47622 - Automember betxnpreoperation - transaction not >> aborted when group entry does not exist >> - Ticket 47620 - 389-ds rejects nsds5ReplicaProtocolTimeout attribute >> >> >> I'm trying to use copr to set up a repo: >> http://copr.fedoraproject.org/coprs/rmeggins/389-ds-base-testing/repo/fedora-20-x86_64/ >> but copr seems to be having some issues. >> >> I also have a patch for 1:389-ds-base-1.3.1.16 for F20 ready to go - I >> tested upgrade from 1.3.2.7 on F20, works fine, disables whoami and >> syncrepl. >> >>> >>> Simo. >>> >>> >> > From jcholast at redhat.com Tue Dec 17 07:19:09 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Dec 2013 08:19:09 +0100 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <1387228349.1948.83.camel@localhost.localdomain> References: <1387228349.1948.83.camel@localhost.localdomain> Message-ID: <52AFFAED.50105@redhat.com> Hi, On 16.12.2013 22:12, Nathaniel McCallum wrote: > Patch attached. Care to elaborate? There's no ticket or explanation why this is beneficial or necessary. Honza -- Jan Cholasta From jcholast at redhat.com Tue Dec 17 08:36:31 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Dec 2013 09:36:31 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1387213296.1948.76.camel@localhost.localdomain> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> <52AF2AD9.2080500@redhat.com> <1387213296.1948.76.camel@localhost.localdomain> Message-ID: <52B00D0F.5010505@redhat.com> On 16.12.2013 18:01, Nathaniel McCallum wrote: > On Mon, 2013-12-16 at 17:31 +0100, Jan Cholasta wrote: >> Please rename _normalize_owner to _convert_owner and vice versa, to >> match the convention used in other plugins (sorry for noticing this >> earlier). > > Fixed. > >> This bit in otptoken_add should be replaced by a call to >> _normalize_owner (after the rename): >> >> + # Resolve the user's dn >> + owner = entry_attrs.get('ipatokenowner', None) >> + if owner is not None: >> + owner = self.api.Object.user.get_dn(owner) >> + entry_attrs['ipatokenowner'] = owner > > Fixed. ipalib/plugins/otptoken.py:230: [E0602(undefined-variable), otptoken_add.pre_callback] Undefined variable 'owner') ipalib/plugins/otptoken.py:232: [E0602(undefined-variable), otptoken_add.pre_callback] Undefined variable 'owner') (just put a "owner = entry_attrs.get('ipatokenowner')" line somewhere in there) > >> You do the conversion from uid to DN in otptoken_find twice: >> >> + _convert_owner(self.api.Object.user, kwargs) >> + return super(otptoken_find, self).pre_callback(ldap, filters, >> *args, **kwargs) >> + >> + def args_options_2_entry(self, *args, **options): >> + o = 'ipatokenowner' >> + if o in options: >> + options[o] = self.api.Object.user.get_dn(options[o]) >> >> I would suggest to do it only in args_options_2_entry like this (again, >> after the rename): >> >> def args_options_2_entry(self, *args, **options): >> entry = super(otptoken_find, self).args_options_2_entry(*args, >> **options) >> _convert_owner(self.api.Object.user, entry) >> return entry > > Fixed. Thanks. Also sorry for misleading you to use _convert_owner here, I see you did the right thing and used _normalize_owner. > >> The patch needs a rebase (for the sake of ipapermlocation default value). > > Fixed. > > Nathaniel > -- Jan Cholasta From jhrozek at redhat.com Tue Dec 17 09:12:20 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Dec 2013 10:12:20 +0100 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <52AFFAED.50105@redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> Message-ID: <20131217091220.GD4707@hendrix.brq.redhat.com> On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: > Hi, > > On 16.12.2013 22:12, Nathaniel McCallum wrote: > >Patch attached. > > Care to elaborate? There's no ticket or explanation why this is > beneficial or necessary. We had a short chat with Nathaniel yesterday on IRC about which C standards we, as a project, allow. I think this patch is a result of that discussion. SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. I think we can safely support C99 and its features now, it's almost 2014 and all major compilers support the features we care about. But I think this change should go hand-in-hand with amending http://www.freeipa.org/page/Coding_Style For instance, would variable-length arrays considered OK? (I would vote yes), would intermingled code and declarations be considered OK (I personally dislike these), etc? From pspacek at redhat.com Tue Dec 17 09:29:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Dec 2013 10:29:03 +0100 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <20131217091220.GD4707@hendrix.brq.redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <20131217091220.GD4707@hendrix.brq.redhat.com> Message-ID: <52B0195F.9010101@redhat.com> On 17.12.2013 10:12, Jakub Hrozek wrote: > On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: >> Hi, >> >> On 16.12.2013 22:12, Nathaniel McCallum wrote: >>> Patch attached. >> >> Care to elaborate? There's no ticket or explanation why this is >> beneficial or necessary. > > We had a short chat with Nathaniel yesterday on IRC about which C standards > we, as a project, allow. I think this patch is a result of that discussion. > > SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. > > I think we can safely support C99 and its features now, it's almost 2014 > and all major compilers support the features we care about. But I think > this change should go hand-in-hand with amending > http://www.freeipa.org/page/Coding_Style > > For instance, would variable-length arrays considered OK? (I would vote > yes), Please no. You can't catch the error if the memory allocation fails for whatever reason and the process will killed by OS. (There is a question if you want to handle memory allocation failures at all, of course.) > would intermingled code and declarations be considered OK (I > personally dislike these), etc? Neither do I :-) -- Petr^2 Spacek From pviktori at redhat.com Tue Dec 17 09:54:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 17 Dec 2013 10:54:59 +0100 Subject: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1 In-Reply-To: <52AF2277.7090204@redhat.com> References: <52AF2072.9030905@redhat.com> <52AF2277.7090204@redhat.com> Message-ID: <52B01F73.8020700@redhat.com> On 12/16/2013 04:55 PM, Jan Cholasta wrote: > Hi, > > On 16.12.2013 16:46, Petr Viktorin wrote: >> Hello, >> Honza found a failure in the new permission plugin when >> ipasearchrecordslimit is set to -1. Here is a fix. >> > > Judging from LDAPSearch.find_entries, it seems that 0 also means > unlimited, so I think "if len(entries) > max_entries > 0" might be safer > here. Fixed. I think it's clearer to spell this out since it's not really comparing the same quantity. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0346.2-permission_find-Do-not-fail-for-ipasearchrecordslimi.patch Type: text/x-patch Size: 1467 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 17 10:08:20 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Dec 2013 11:08:20 +0100 Subject: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1 In-Reply-To: <52B01F73.8020700@redhat.com> References: <52AF2072.9030905@redhat.com> <52AF2277.7090204@redhat.com> <52B01F73.8020700@redhat.com> Message-ID: <52B02294.5030104@redhat.com> On 17.12.2013 10:54, Petr Viktorin wrote: > On 12/16/2013 04:55 PM, Jan Cholasta wrote: >> Hi, >> >> On 16.12.2013 16:46, Petr Viktorin wrote: >>> Hello, >>> Honza found a failure in the new permission plugin when >>> ipasearchrecordslimit is set to -1. Here is a fix. >>> >> >> Judging from LDAPSearch.find_entries, it seems that 0 also means >> unlimited, so I think "if len(entries) > max_entries > 0" might be safer >> here. > > Fixed. > I think it's clearer to spell this out since it's not really comparing > the same quantity. > ACK. -- Jan Cholasta From jhrozek at redhat.com Tue Dec 17 10:06:48 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Dec 2013 11:06:48 +0100 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <52B0195F.9010101@redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <20131217091220.GD4707@hendrix.brq.redhat.com> <52B0195F.9010101@redhat.com> Message-ID: <20131217100648.GG4707@hendrix.brq.redhat.com> On Tue, Dec 17, 2013 at 10:29:03AM +0100, Petr Spacek wrote: > On 17.12.2013 10:12, Jakub Hrozek wrote: > >On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: > >>Hi, > >> > >>On 16.12.2013 22:12, Nathaniel McCallum wrote: > >>>Patch attached. > >> > >>Care to elaborate? There's no ticket or explanation why this is > >>beneficial or necessary. > > > >We had a short chat with Nathaniel yesterday on IRC about which C standards > >we, as a project, allow. I think this patch is a result of that discussion. > > > >SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. > > > >I think we can safely support C99 and its features now, it's almost 2014 > >and all major compilers support the features we care about. But I think > >this change should go hand-in-hand with amending > >http://www.freeipa.org/page/Coding_Style > > > >For instance, would variable-length arrays considered OK? (I would vote > >yes), > > Please no. You can't catch the error if the memory allocation fails > for whatever reason and the process will killed by OS. > > (There is a question if you want to handle memory allocation > failures at all, of course.) I thought that variable length arrays were allocated on the stack? So yes, you need to be careful and only allow use VLAs when you absolutely know that the value is small and you don't run past the stack size. But that's not really what I wanted to discuss now, I mostly wanted to bring up that if we allow some extra language features, we should agree on whether it's OK to use all of them. From pviktori at redhat.com Tue Dec 17 11:30:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 17 Dec 2013 12:30:34 +0100 Subject: [Freeipa-devel] [PATCH] 0346 permission_find: Do not fail for ipasearchrecordslimit=-1 In-Reply-To: <52B02294.5030104@redhat.com> References: <52AF2072.9030905@redhat.com> <52AF2277.7090204@redhat.com> <52B01F73.8020700@redhat.com> <52B02294.5030104@redhat.com> Message-ID: <52B035DA.2020409@redhat.com> On 12/17/2013 11:08 AM, Jan Cholasta wrote: > On 17.12.2013 10:54, Petr Viktorin wrote: >> On 12/16/2013 04:55 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 16.12.2013 16:46, Petr Viktorin wrote: >>>> Hello, >>>> Honza found a failure in the new permission plugin when >>>> ipasearchrecordslimit is set to -1. Here is a fix. >>>> >>> >>> Judging from LDAPSearch.find_entries, it seems that 0 also means >>> unlimited, so I think "if len(entries) > max_entries > 0" might be safer >>> here. >> >> Fixed. >> I think it's clearer to spell this out since it's not really comparing >> the same quantity. >> > > ACK. Thanks! Pushed to master: 1a9beac1bebc7d9b0207053a7eb6d775cae590d1 -- Petr? From npmccallum at redhat.com Tue Dec 17 13:38:07 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 17 Dec 2013 08:38:07 -0500 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <52AFFAED.50105@redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> Message-ID: <1387287487.1948.86.camel@localhost.localdomain> On Tue, 2013-12-17 at 08:19 +0100, Jan Cholasta wrote: > Hi, > > On 16.12.2013 22:12, Nathaniel McCallum wrote: > > Patch attached. > > Care to elaborate? There's no ticket or explanation why this is > beneficial or necessary. It enables compiling with C99 features, which I personally find very beneficial. I am using these features (incomplete initializers and for-loop declarations) in my DS plugin code. It is 2014 after all, and most recent compilers support C11 at this point (certainly all the ones we care to support)... Nathaniel From npmccallum at redhat.com Tue Dec 17 13:47:21 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 17 Dec 2013 08:47:21 -0500 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <52B0195F.9010101@redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <20131217091220.GD4707@hendrix.brq.redhat.com> <52B0195F.9010101@redhat.com> Message-ID: <1387288041.1948.93.camel@localhost.localdomain> On Tue, 2013-12-17 at 10:29 +0100, Petr Spacek wrote: > On 17.12.2013 10:12, Jakub Hrozek wrote: > > On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: > >> Hi, > >> > >> On 16.12.2013 22:12, Nathaniel McCallum wrote: > >>> Patch attached. > >> > >> Care to elaborate? There's no ticket or explanation why this is > >> beneficial or necessary. > > > > We had a short chat with Nathaniel yesterday on IRC about which C standards > > we, as a project, allow. I think this patch is a result of that discussion. > > > > SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. > > > > I think we can safely support C99 and its features now, it's almost 2014 > > and all major compilers support the features we care about. But I think > > this change should go hand-in-hand with amending > > http://www.freeipa.org/page/Coding_Style > > > > For instance, would variable-length arrays considered OK? (I would vote > > yes), > > Please no. You can't catch the error if the memory allocation fails for > whatever reason and the process will killed by OS. > > (There is a question if you want to handle memory allocation failures at all, > of course.) I think this can be reasonably be used with appropriately documented caution. > > would intermingled code and declarations be considered OK (I > > personally dislike these), etc? > > Neither do I :-) +1, with the exception of declarations at the beginning of the block, which I find useful (I know this isn't C99). Features that I don't want to live without: 1. Standard struct initializers 2. Compound literals 3. For-loop declarations 4. Standard bool type Nathaniel From npmccallum at redhat.com Tue Dec 17 13:54:13 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 17 Dec 2013 08:54:13 -0500 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52B00D0F.5010505@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> <52AF2AD9.2080500@redhat.com> <1387213296.1948.76.camel@localhost.localdomain> <52B00D0F.5010505@redhat.com> Message-ID: <1387288453.1948.95.camel@localhost.localdomain> On Tue, 2013-12-17 at 09:36 +0100, Jan Cholasta wrote: > On 16.12.2013 18:01, Nathaniel McCallum wrote: > > On Mon, 2013-12-16 at 17:31 +0100, Jan Cholasta wrote: > >> Please rename _normalize_owner to _convert_owner and vice versa, to > >> match the convention used in other plugins (sorry for noticing this > >> earlier). > > > > Fixed. > > > >> This bit in otptoken_add should be replaced by a call to > >> _normalize_owner (after the rename): > >> > >> + # Resolve the user's dn > >> + owner = entry_attrs.get('ipatokenowner', None) > >> + if owner is not None: > >> + owner = self.api.Object.user.get_dn(owner) > >> + entry_attrs['ipatokenowner'] = owner > > > > Fixed. > > ipalib/plugins/otptoken.py:230: [E0602(undefined-variable), > otptoken_add.pre_callback] Undefined variable 'owner') > ipalib/plugins/otptoken.py:232: [E0602(undefined-variable), > otptoken_add.pre_callback] Undefined variable 'owner') > > (just put a "owner = entry_attrs.get('ipatokenowner')" line somewhere in > there) Fixed, with: owner = entry_attrs.get('ipatokenowner', None) Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-7-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 28498 bytes Desc: not available URL: From simo at redhat.com Tue Dec 17 13:58:26 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Dec 2013 08:58:26 -0500 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <1387288041.1948.93.camel@localhost.localdomain> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <20131217091220.GD4707@hendrix.brq.redhat.com> <52B0195F.9010101@redhat.com> <1387288041.1948.93.camel@localhost.localdomain> Message-ID: <1387288706.19564.292.camel@willson.li.ssimo.org> On Tue, 2013-12-17 at 08:47 -0500, Nathaniel McCallum wrote: > On Tue, 2013-12-17 at 10:29 +0100, Petr Spacek wrote: > > On 17.12.2013 10:12, Jakub Hrozek wrote: > > > On Tue, Dec 17, 2013 at 08:19:09AM +0100, Jan Cholasta wrote: > > >> Hi, > > >> > > >> On 16.12.2013 22:12, Nathaniel McCallum wrote: > > >>> Patch attached. > > >> > > >> Care to elaborate? There's no ticket or explanation why this is > > >> beneficial or necessary. > > > > > > We had a short chat with Nathaniel yesterday on IRC about which C standards > > > we, as a project, allow. I think this patch is a result of that discussion. > > > > > > SSSD has had -std=gnu99 in the default CFLAGS for more than a year now. > > > > > > I think we can safely support C99 and its features now, it's almost 2014 > > > and all major compilers support the features we care about. But I think > > > this change should go hand-in-hand with amending > > > http://www.freeipa.org/page/Coding_Style > > > > > > For instance, would variable-length arrays considered OK? (I would vote > > > yes), > > > > Please no. You can't catch the error if the memory allocation fails for > > whatever reason and the process will killed by OS. > > > > (There is a question if you want to handle memory allocation failures at all, > > of course.) > > I think this can be reasonably be used with appropriately documented > caution. +1 > > > would intermingled code and declarations be considered OK (I > > > personally dislike these), etc? > > > > Neither do I :-) > > +1, with the exception of declarations at the beginning of the block, > which I find useful (I know this isn't C99). +1, although in general declarations in blocks should really be sparse and only for very local very temporary variables, and generally *not* for pointers that hold the only reference to allocated memory (as then a goto error statement will not be possible as the variable is out of context and can't be freed in the exception handling part of the code after the label). > Features that I don't want to live without: > 1. Standard struct initializers > 2. Compound literals > 3. For-loop declarations > 4. Standard bool type I am pretty much +1 on C99 as the minimum common denominator for our code. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Dec 17 14:03:55 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Dec 2013 15:03:55 +0100 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <1387287487.1948.86.camel@localhost.localdomain> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <1387287487.1948.86.camel@localhost.localdomain> Message-ID: <52B059CB.5080108@redhat.com> On 17.12.2013 14:38, Nathaniel McCallum wrote: > On Tue, 2013-12-17 at 08:19 +0100, Jan Cholasta wrote: >> Hi, >> >> On 16.12.2013 22:12, Nathaniel McCallum wrote: >>> Patch attached. >> >> Care to elaborate? There's no ticket or explanation why this is >> beneficial or necessary. > > It enables compiling with C99 features, which I personally find very > beneficial. I am using these features (incomplete initializers and > for-loop declarations) in my DS plugin code. It is 2014 after all, and > most recent compilers support C11 at this point (certainly all the ones > we care to support)... > > Nathaniel > Can you put something like this explanation in the commit message please? -- Jan Cholasta From rmeggins at redhat.com Tue Dec 17 16:35:50 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Dec 2013 09:35:50 -0700 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <52AF174A.4060104@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> Message-ID: <52B07D66.7050105@redhat.com> On 12/16/2013 08:07 AM, Petr Spacek wrote: > Hello list, > > we have to decide what we will do with 389-ds-base package in Fedora 20. > > Currently, we know about following problems: > > Schema problems: > https://fedorahosted.org/389/ticket/47631 (regression) Fixed. > > Referential Integrity: > https://fedorahosted.org/389/ticket/47621 (new functionality) > https://fedorahosted.org/389/ticket/47624 (regression) Fixed. > > Replication: > https://fedorahosted.org/389/ticket/47632 (?) Cannot reproduce. Closed as WORKSFORME. > > Stability: > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 Fixed. > https://fedorahosted.org/389/ticket/47629 (we are not sure if the > syncrepl really plays some role or not) We are still trying to determine the cause, and if this is related to the use of syncrepl. If it turns out to be related to syncrepl, I would like to release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. Is everyone ok with this? > > One option is to fix 1.3.2.x as quickly as possible. > > Another option is to build 1.3.1.x for F20 with Epoch == 1 and release > it as quickly as possible. > > The problem with downgrade to 1.3.1.x is that it requires manual > change in dse.ldif file. You have to disable 'content synchronization' > (syncrepl) and 'whoami' plugins which are not in 1.3.1.x packages but > were added and enabled by 1.3.2.x packages. > > In our tests, the downgraded DS server starts and works after manual > dse.ldif correction (but be careful - we didn't test replication). > > Here is the main problem: > 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not > way how to replace it there. It means that somebody can do F19->F20 > upgrade from ISO and *then* upgrade from repos will break his DS > configuration (because of new plugins...). > > Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x > inevitably needs automated script which will purge two missing plugins > from dse.ldif. > > Nathan, is it manageable before Christmas? One or either way? Is you > think that the downgrade is safe from data format perspective? (I mean > DB format upgrades etc.?) > From abokovoy at redhat.com Tue Dec 17 16:40:57 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Dec 2013 18:40:57 +0200 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <52B07D66.7050105@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52B07D66.7050105@redhat.com> Message-ID: <20131217164057.GF21264@redhat.com> On Tue, 17 Dec 2013, Rich Megginson wrote: >On 12/16/2013 08:07 AM, Petr Spacek wrote: >>Hello list, >> >>we have to decide what we will do with 389-ds-base package in Fedora 20. >> >>Currently, we know about following problems: >> >>Schema problems: >> https://fedorahosted.org/389/ticket/47631 (regression) > >Fixed. > >> >>Referential Integrity: >> https://fedorahosted.org/389/ticket/47621 (new functionality) >> https://fedorahosted.org/389/ticket/47624 (regression) >Fixed. >> >>Replication: >> https://fedorahosted.org/389/ticket/47632 (?) > >Cannot reproduce. Closed as WORKSFORME. > >> >>Stability: >> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >Fixed. >>https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>syncrepl really plays some role or not) > >We are still trying to determine the cause, and if this is related to >the use of syncrepl. If it turns out to be related to syncrepl, I >would like to release 1.3.2.9 in F20, and just disable the use of >syncrepl in 389 clients. > >Is everyone ok with this? Fine for me. Once you get update out, we can issue FreeIPA update that requires new 389-ds-base and slapi-nis (slapi-nis was already released so we cannot combine all three packages in the same update). -- / Alexander Bokovoy From pspacek at redhat.com Tue Dec 17 16:58:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Dec 2013 17:58:54 +0100 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <20131217164057.GF21264@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52B07D66.7050105@redhat.com> <20131217164057.GF21264@redhat.com> Message-ID: <52B082CE.80703@redhat.com> On 17.12.2013 17:40, Alexander Bokovoy wrote: > On Tue, 17 Dec 2013, Rich Megginson wrote: >> On 12/16/2013 08:07 AM, Petr Spacek wrote: >>> Hello list, >>> >>> we have to decide what we will do with 389-ds-base package in Fedora 20. >>> >>> Currently, we know about following problems: >>> >>> Schema problems: >>> https://fedorahosted.org/389/ticket/47631 (regression) >> >> Fixed. >> >>> >>> Referential Integrity: >>> https://fedorahosted.org/389/ticket/47621 (new functionality) >>> https://fedorahosted.org/389/ticket/47624 (regression) >> Fixed. >>> >>> Replication: >>> https://fedorahosted.org/389/ticket/47632 (?) >> >> Cannot reproduce. Closed as WORKSFORME. >> >>> >>> Stability: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >> Fixed. >>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl >>> really plays some role or not) >> >> We are still trying to determine the cause, and if this is related to the >> use of syncrepl. If it turns out to be related to syncrepl, I would like to >> release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients. >> >> Is everyone ok with this? It works for me. > Fine for me. Once you get update out, we can issue FreeIPA update that > requires new 389-ds-base and slapi-nis (slapi-nis was already released > so we cannot combine all three packages in the same update). I'm not sure that we need/want to release a freeipa package with new requires. Users just need to upgrade all packages as usual. (Note that users will not get the new freeipa package with new "requires" until they run yum upgrade anyway, so I don't see a big value in new release.) -- Petr^2 Spacek From mareynol at redhat.com Tue Dec 17 18:19:02 2013 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 17 Dec 2013 13:19:02 -0500 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <52B07D66.7050105@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52B07D66.7050105@redhat.com> Message-ID: <52B09596.9090901@redhat.com> On 12/17/2013 11:35 AM, Rich Megginson wrote: > On 12/16/2013 08:07 AM, Petr Spacek wrote: >> Hello list, >> >> we have to decide what we will do with 389-ds-base package in Fedora 20. >> >> Currently, we know about following problems: >> >> Schema problems: >> https://fedorahosted.org/389/ticket/47631 (regression) > > Fixed. > >> >> Referential Integrity: >> https://fedorahosted.org/389/ticket/47621 (new functionality) >> https://fedorahosted.org/389/ticket/47624 (regression) > Fixed. >> >> Replication: >> https://fedorahosted.org/389/ticket/47632 (?) > > Cannot reproduce. Closed as WORKSFORME. > >> >> Stability: >> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 > Fixed. >> https://fedorahosted.org/389/ticket/47629 (we are not sure if the >> syncrepl really plays some role or not) > > We are still trying to determine the cause, and if this is related to > the use of syncrepl. If it turns out to be related to syncrepl, I > would like to release 1.3.2.9 in F20, and just disable the use of > syncrepl in 389 clients. > > Is everyone ok with this? > Rich I found a crash in 1.3.2 and 1.3.1. This should go into 1.3.2.9(or a 1.3.2.10). >> >> One option is to fix 1.3.2.x as quickly as possible. >> >> Another option is to build 1.3.1.x for F20 with Epoch == 1 and >> release it as quickly as possible. >> >> The problem with downgrade to 1.3.1.x is that it requires manual >> change in dse.ldif file. You have to disable 'content >> synchronization' (syncrepl) and 'whoami' plugins which are not in >> 1.3.1.x packages but were added and enabled by 1.3.2.x packages. >> >> In our tests, the downgraded DS server starts and works after manual >> dse.ldif correction (but be careful - we didn't test replication). >> >> Here is the main problem: >> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not >> way how to replace it there. It means that somebody can do F19->F20 >> upgrade from ISO and *then* upgrade from repos will break his DS >> configuration (because of new plugins...). >> >> Simo thinks that this is a reason why 'downgrade package' with >> 1.3.1.x inevitably needs automated script which will purge two >> missing plugins from dse.ldif. >> >> Nathan, is it manageable before Christmas? One or either way? Is you >> think that the downgrade is safe from data format perspective? (I >> mean DB format upgrades etc.?) >> > -- Mark Reynolds 389 Development Team Red Hat, Inc mreynolds at redhat.com From rmeggins at redhat.com Tue Dec 17 18:23:45 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Dec 2013 11:23:45 -0700 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <52B09596.9090901@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52B07D66.7050105@redhat.com> <52B09596.9090901@redhat.com> Message-ID: <52B096B1.40606@redhat.com> On 12/17/2013 11:19 AM, Mark Reynolds wrote: > > On 12/17/2013 11:35 AM, Rich Megginson wrote: >> On 12/16/2013 08:07 AM, Petr Spacek wrote: >>> Hello list, >>> >>> we have to decide what we will do with 389-ds-base package in Fedora >>> 20. >>> >>> Currently, we know about following problems: >>> >>> Schema problems: >>> https://fedorahosted.org/389/ticket/47631 (regression) >> >> Fixed. >> >>> >>> Referential Integrity: >>> https://fedorahosted.org/389/ticket/47621 (new functionality) >>> https://fedorahosted.org/389/ticket/47624 (regression) >> Fixed. >>> >>> Replication: >>> https://fedorahosted.org/389/ticket/47632 (?) >> >> Cannot reproduce. Closed as WORKSFORME. >> >>> >>> Stability: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >> Fixed. >>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>> syncrepl really plays some role or not) >> >> We are still trying to determine the cause, and if this is related to >> the use of syncrepl. If it turns out to be related to syncrepl, I >> would like to release 1.3.2.9 in F20, and just disable the use of >> syncrepl in 389 clients. >> >> Is everyone ok with this? >> > Rich I found a crash in 1.3.2 and 1.3.1. This should go into > 1.3.2.9(or a 1.3.2.10). Ok. >>> >>> One option is to fix 1.3.2.x as quickly as possible. >>> >>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>> release it as quickly as possible. >>> >>> The problem with downgrade to 1.3.1.x is that it requires manual >>> change in dse.ldif file. You have to disable 'content >>> synchronization' (syncrepl) and 'whoami' plugins which are not in >>> 1.3.1.x packages but were added and enabled by 1.3.2.x packages. >>> >>> In our tests, the downgraded DS server starts and works after manual >>> dse.ldif correction (but be careful - we didn't test replication). >>> >>> Here is the main problem: >>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is >>> not way how to replace it there. It means that somebody can do >>> F19->F20 upgrade from ISO and *then* upgrade from repos will break >>> his DS configuration (because of new plugins...). >>> >>> Simo thinks that this is a reason why 'downgrade package' with >>> 1.3.1.x inevitably needs automated script which will purge two >>> missing plugins from dse.ldif. >>> >>> Nathan, is it manageable before Christmas? One or either way? Is you >>> think that the downgrade is safe from data format perspective? (I >>> mean DB format upgrades etc.?) >>> >> > From rmeggins at redhat.com Tue Dec 17 23:47:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Dec 2013 16:47:03 -0700 Subject: [Freeipa-devel] Update: Re: Fedora 20 Release In-Reply-To: <52B096B1.40606@redhat.com> References: <52AE015D.9070306@redhat.com> <52AE5C88.5020506@redhat.com> <52AEEA9B.8000608@redhat.com> <52AF0236.3030907@redhat.com> <52AF174A.4060104@redhat.com> <52B07D66.7050105@redhat.com> <52B09596.9090901@redhat.com> <52B096B1.40606@redhat.com> Message-ID: <52B0E277.8020701@redhat.com> On 12/17/2013 11:23 AM, Rich Megginson wrote: > On 12/17/2013 11:19 AM, Mark Reynolds wrote: >> >> On 12/17/2013 11:35 AM, Rich Megginson wrote: >>> On 12/16/2013 08:07 AM, Petr Spacek wrote: >>>> Hello list, >>>> >>>> we have to decide what we will do with 389-ds-base package in >>>> Fedora 20. >>>> >>>> Currently, we know about following problems: >>>> >>>> Schema problems: >>>> https://fedorahosted.org/389/ticket/47631 (regression) >>> >>> Fixed. >>> >>>> >>>> Referential Integrity: >>>> https://fedorahosted.org/389/ticket/47621 (new functionality) >>>> https://fedorahosted.org/389/ticket/47624 (regression) >>> Fixed. >>>> >>>> Replication: >>>> https://fedorahosted.org/389/ticket/47632 (?) >>> >>> Cannot reproduce. Closed as WORKSFORME. >>> >>>> >>>> Stability: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1041732 >>> Fixed. >>>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the >>>> syncrepl really plays some role or not) >>> >>> We are still trying to determine the cause, and if this is related >>> to the use of syncrepl. If it turns out to be related to syncrepl, >>> I would like to release 1.3.2.9 in F20, and just disable the use of >>> syncrepl in 389 clients. >>> >>> Is everyone ok with this? >>> >> Rich I found a crash in 1.3.2 and 1.3.1. This should go into >> 1.3.2.9(or a 1.3.2.10). > > Ok. 389-ds-base-1.3.2.9 is now in Fedora 20 updates testing. Please test and give karma. This release fixes everything except https://fedorahosted.org/389/ticket/47629 random crash in send_ldap_search_entry_ext(), which, in my testing, appears to be related to syncrepl, and therefore imo should not hold up the release of 1.3.2.9 into Fedora 20. > >>>> >>>> One option is to fix 1.3.2.x as quickly as possible. >>>> >>>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and >>>> release it as quickly as possible. >>>> >>>> The problem with downgrade to 1.3.1.x is that it requires manual >>>> change in dse.ldif file. You have to disable 'content >>>> synchronization' (syncrepl) and 'whoami' plugins which are not in >>>> 1.3.1.x packages but were added and enabled by 1.3.2.x packages. >>>> >>>> In our tests, the downgraded DS server starts and works after >>>> manual dse.ldif correction (but be careful - we didn't test >>>> replication). >>>> >>>> Here is the main problem: >>>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is >>>> not way how to replace it there. It means that somebody can do >>>> F19->F20 upgrade from ISO and *then* upgrade from repos will break >>>> his DS configuration (because of new plugins...). >>>> >>>> Simo thinks that this is a reason why 'downgrade package' with >>>> 1.3.1.x inevitably needs automated script which will purge two >>>> missing plugins from dse.ldif. >>>> >>>> Nathan, is it manageable before Christmas? One or either way? Is >>>> you think that the downgrade is safe from data format perspective? >>>> (I mean DB format upgrades etc.?) >>>> >>> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Wed Dec 18 08:16:27 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Dec 2013 09:16:27 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1387288453.1948.95.camel@localhost.localdomain> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> <52AF2AD9.2080500@redhat.com> <1387213296.1948.76.camel@localhost.localdomain> <52B00D0F.5010505@redhat.com> <1387288453.1948.95.camel@localhost.localdomain> Message-ID: <52B159DB.6070501@redhat.com> On 17.12.2013 14:54, Nathaniel McCallum wrote: > On Tue, 2013-12-17 at 09:36 +0100, Jan Cholasta wrote: >> ipalib/plugins/otptoken.py:230: [E0602(undefined-variable), >> otptoken_add.pre_callback] Undefined variable 'owner') >> ipalib/plugins/otptoken.py:232: [E0602(undefined-variable), >> otptoken_add.pre_callback] Undefined variable 'owner') >> >> (just put a "owner = entry_attrs.get('ipatokenowner')" line somewhere in >> there) > > Fixed, with: owner = entry_attrs.get('ipatokenowner', None) That is not necessary, None is the default for the second argument of get. ACK. -- Jan Cholasta From pviktori at redhat.com Wed Dec 18 09:04:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Dec 2013 10:04:42 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <52B159DB.6070501@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> <5270BBDF.5050506@redhat.com> <1384457033.1822.51.camel@localhost.localdomain> <52A85967.1020601@redhat.com> <1386964218.1948.12.camel@localhost.localdomain> <1386965729.1948.13.camel@localhost.localdomain> <52AF2AD9.2080500@redhat.com> <1387213296.1948.76.camel@localhost.localdomain> <52B00D0F.5010505@redhat.com> <1387288453.1948.95.camel@localhost.localdomain> <52B159DB.6070501@redhat.com> Message-ID: <52B1652A.20201@redhat.com> On 12/18/2013 09:16 AM, Jan Cholasta wrote: > On 17.12.2013 14:54, Nathaniel McCallum wrote: >> On Tue, 2013-12-17 at 09:36 +0100, Jan Cholasta wrote: >>> ipalib/plugins/otptoken.py:230: [E0602(undefined-variable), >>> otptoken_add.pre_callback] Undefined variable 'owner') >>> ipalib/plugins/otptoken.py:232: [E0602(undefined-variable), >>> otptoken_add.pre_callback] Undefined variable 'owner') >>> >>> (just put a "owner = entry_attrs.get('ipatokenowner')" line somewhere in >>> there) >> >> Fixed, with: owner = entry_attrs.get('ipatokenowner', None) > > That is not necessary, None is the default for the second argument of get. > > ACK. Pushed to master: 397b2876e2f9bf1c5b3ad3e2874a92715ccda599 -- Petr? From jcholast at redhat.com Wed Dec 18 11:50:53 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Dec 2013 12:50:53 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52A8A0C0.2050404@redhat.com> References: <52A712BC.2090109@redhat.com> <52A88D45.60706@redhat.com> <52A8A0C0.2050404@redhat.com> Message-ID: <52B18C1D.9020902@redhat.com> On 11.12.2013 18:28, Petr Viktorin wrote: > On 12/11/2013 05:05 PM, Petr Viktorin wrote: >> On 12/10/2013 02:10 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >> >> These look great, thanks! Just a couple of questions/nicpicks. >> >> 213: ACK >> 214: ACK >> 215: ACK >> 216: ACK >> 217: ACK >> 218: ACK >> >> 219: >> Does the new method guarantee 'attributetypes' are updated before >> 'objectclasses'? >> I can move the logic to schemaupdate if needed. That won't be necessary, fixed. >> >> Why is OnlyOneValueAllowed not raised any more? It should be, since the >> method assumes get_single_value() gives correct information. Fixed. >> >> Why is MOD_REPLACE no longer used when no old values are retained? Or >> (MOD_DELETE, a, None) when the new set is empty? Fixed. However, I am not convinced if this guessing is the right approach. I think we can do better, by either not guessing: del entry[attr] -> delete attribute entry[attr] = value -> replace attribute entry[attr][index] = value -> delete old value, add new value or by guessing better, to minimize the size of the modify request. >> >> >> 220: ACK >> >> 221: >> An ancient comment in ldapupdate still has a reference to orig_data in, >> can you remove the comment as well? Sure. >> >> 222: ACK >> 223: ACK >> 224: ACK > > I spoke too soon, NACK. This line: > > > -from ipaserver.plugins import ldap2 > > is important, please put it back. Without it api.Backend.ldap2 will not > be available and upgrades will fail with AttributeError. > > (Yes, I know.) Fixed. (But it's retarded.) > > >> I noticed that IPASimpleLdapObject.convert_result's docstring is >> obsolete, could you update/shorten it? Sure. Also fixed some more issues I noticed. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-213.1-Rename-LDAPEntry-method-commit-to-reset_modlist.patch Type: text/x-patch Size: 1237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-214.1-Use-old-entry-state-in-LDAPClient.update_entry.patch Type: text/x-patch Size: 4718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-215.1-Move-LDAPClient-method-get_single_value-to-IPASimple.patch Type: text/x-patch Size: 3089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-216.1-Make-IPASimpleLDAPObject.get_single_value-result-ove.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-217.1-Use-LDAPClient.update_entry-for-LDAP-mods-in-ldapupd.patch Type: text/x-patch Size: 4389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-218.1-Reduce-amount-of-LDAPEntry.reset_modlist-calls-in-ld.patch Type: text/x-patch Size: 1976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-219.1-Add-LDAPEntry-method-generate_modlist.patch Type: text/x-patch Size: 5983 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-220.1-Remove-unused-LDAPClient-methods-get_syntax-and-get_.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-221.1-Remove-legacy-LDAPEntry-properties-data-and-orig_dat.patch Type: text/x-patch Size: 4015 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-222.1-Store-old-entry-state-in-dict-rather-than-LDAPEntry.patch Type: text/x-patch Size: 4471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-223.1-Do-not-crash-on-bad-LDAP-data-when-formatting-decode.patch Type: text/x-patch Size: 1003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-224.1-Use-raw-LDAP-data-in-ldapupdate.patch Type: text/x-patch Size: 3242 bytes Desc: not available URL: From awnuk at redhat.com Thu Dec 19 01:50:18 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 18 Dec 2013 17:50:18 -0800 Subject: [Freeipa-devel] FreeIPA as external Puppet CA Message-ID: <52B250DA.4050606@redhat.com> I have been exploring the possibilities of using FreeIPA CA as an external Puppet CA with the requirement that Puppet will stay unmodified. Here are some notes: http://www.freeipa.org/page/IPA_as_external_Puppet_CA Thank you, Andrew From purpleidea at gmail.com Thu Dec 19 02:04:05 2013 From: purpleidea at gmail.com (James) Date: Wed, 18 Dec 2013 21:04:05 -0500 Subject: [Freeipa-devel] FreeIPA as external Puppet CA In-Reply-To: <52B250DA.4050606@redhat.com> References: <52B250DA.4050606@redhat.com> Message-ID: Cool, FWIW, I manage FreeIPA _with_ Puppet. This isn't related directly, but I figured I'd mention it if you're into Puppet. The code is here: https://github.com/purpleidea/puppet-ipa BTW, I like the idea of using FreeIPA for the PuppetCA. That is something I should look into doing too. Cheers, James On Wed, Dec 18, 2013 at 8:50 PM, Andrew Wnuk wrote: > I have been exploring the possibilities of using FreeIPA CA as an external > Puppet CA with the requirement that Puppet will stay unmodified. > Here are some notes: http://www.freeipa.org/page/IPA_as_external_Puppet_CA > > Thank you, > Andrew > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tbabej at redhat.com Thu Dec 19 16:00:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Dec 2013 17:00:23 +0100 Subject: [Freeipa-devel] [PATCH 0135] Fix incorrect path in error message on sysrestore failure In-Reply-To: <52AABBFA.7030903@redhat.com> References: <52A9C211.6090600@redhat.com> <52AABBFA.7030903@redhat.com> Message-ID: <52B31817.9040207@redhat.com> Yes, this is planned as part of https://fedorahosted.org/freeipa/ticket/4052 NACKs are welcome! It's a valid point, so I guess be fixing it now here wouldn't hurt. Updated patch attached. Tomas On 12/13/2013 08:49 AM, Petr Spacek wrote: > On 12.12.2013 15:02, Tomas Babej wrote: >> On sysrestore failure, user is prompted out to remove the sysrestore >> file. However, the path to the sysrestore file mentioned in the >> sentence is not correct. >> >> https://fedorahosted.org/freeipa/ticket/4080 >> >> -- >> Tomas Babej >> >> >> freeipa-tbabej-0135-Fix-incorrect-path-in-error-message-on-sysrestore-fa.patch >> >> >> >> From eac993e153c243b6359f57a7c051d3f373a9add0 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Thu, 12 Dec 2013 15:01:14 +0100 >> Subject: [PATCH] Fix incorrect path in error message on sysrestore >> failure >> >> On sysrestore failure, user is prompted out to remove the sysrestore >> file. However, the path to the sysrestore file mentioned in the >> sentence is not correct. >> >> https://fedorahosted.org/freeipa/ticket/4080 >> --- >> install/tools/ipa-server-install | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/install/tools/ipa-server-install >> b/install/tools/ipa-server-install >> index >> 458ebba550d0fe7675bd874e23c7d730c53297e6..718fcee45550b9f65a17ecddc599fb4489f7ab3c >> 100755 >> --- a/install/tools/ipa-server-install >> +++ b/install/tools/ipa-server-install >> @@ -534,7 +534,10 @@ def uninstall(): >> rv = 1 >> >> if has_state: >> - root_logger.error('Some installation state has not been >> restored.\nThis may cause re-installation to fail.\nIt should be safe >> to remove /var/lib/ipa/sysrestore.state but it may\nmean your system >> hasn\'t be restored to its pre-installation state.') >> + root_logger.error('Some installation state has not been >> restored.\n' >> + 'This may cause re-installation to fail.\n' >> + 'It should be safe to remove >> /var/lib/ipa/sysrestore/sysrestore.state but it may\n' > > (I know that this is bold ...) NACK. > > A path used in the error message should be extracted/shared with the > code. It will prevent inconsistencies like this in the future. > > Petr^2 Spacek > >> + 'mean your system hasn\'t be restored to >> its pre-installation state.') >> >> # Note that this name will be wrong after the first uninstall. >> dirname = >> dsinstance.config_dirname(dsinstance.realm_to_serverid(api.env.realm)) > > _______________________________________________ > 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: freeipa-tbabej-0135-2-Fix-incorrect-path-in-error-message-on-sysrestore-fa.patch Type: text/x-patch Size: 3295 bytes Desc: not available URL: From simo at redhat.com Thu Dec 19 21:24:45 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Dec 2013 16:24:45 -0500 Subject: [Freeipa-devel] krbpwdpolicypreference issues Message-ID: <1387488285.19564.339.camel@willson.li.ssimo.org> I have been looking at how we deal with krbpwdpolicypreference as we found issues with AD synced users, which get no password policy :/ I found out that we do not rely on CoS anymore for setting the attribute (origin of this bug I would guess), but instead explicitly set the policy on user objects. Why is that ? Also I still see in bootstrap-template.ldif that we create a Password Policy object in cn=accounts in theory, but I do not have this object on my server, what happens to it, what removes it ? Why ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 20 09:11:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 10:11:56 +0100 Subject: [Freeipa-devel] [PATCH 0136] Remove enumeration index from dynamic role hosts when In-Reply-To: <52A9DC8A.7040903@redhat.com> References: <52A9DC8A.7040903@redhat.com> Message-ID: <52B409DC.6040606@redhat.com> On 12/12/2013 04:55 PM, Tomas Babej wrote: > Hi, > > When exporting test configuration, do not append indexes to dynamic > role definitions as this is not expected form of input. > > https://fedorahosted.org/freeipa/ticket/4081 The problem is that this approach would limit us to only one host per dynamic role. Conceptually a host's "role" refers mainly to the set of packages installed on the host. [0] Also, the distinction between dynamic and static is just a detail of the envvar configuration. In the future we might want to test with e.g. several legacy clients, or several replicas without a "ipa-server-ca" package, so we'll want the config system to allow more hosts per role. Since the ticket is not time-critical, and to prevent conflicts, I'll add a patch for it to the next revision of my YAML patchset. [0] "Master" is an unfortunate exception. -- Petr? From pviktori at redhat.com Fri Dec 20 09:22:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 10:22:38 +0100 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <1387488285.19564.339.camel@willson.li.ssimo.org> References: <1387488285.19564.339.camel@willson.li.ssimo.org> Message-ID: <52B40C5E.4020308@redhat.com> On 12/19/2013 10:24 PM, Simo Sorce wrote: > I have been looking at how we deal with krbpwdpolicypreference as we > found issues with AD synced users, which get no password policy :/ > > I found out that we do not rely on CoS anymore for setting the attribute > (origin of this bug I would guess), but instead explicitly set the > policy on user objects. > > Why is that ? > > Also I still see in bootstrap-template.ldif that we create a Password > Policy object in cn=accounts in theory, but I do not have this object on > my server, what happens to it, what removes it ? Why ? I don't see it in any update file. Was your server installed before this was added (2009-10-02)? -- Petr? From pviktori at redhat.com Fri Dec 20 12:06:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 13:06:44 +0100 Subject: [Freeipa-devel] [PATCHES] 213-224 Use old entry state in LDAP mods In-Reply-To: <52B18C1D.9020902@redhat.com> References: <52A712BC.2090109@redhat.com> <52A88D45.60706@redhat.com> <52A8A0C0.2050404@redhat.com> <52B18C1D.9020902@redhat.com> Message-ID: <52B432D4.3090804@redhat.com> On 12/18/2013 12:50 PM, Jan Cholasta wrote: > On 11.12.2013 18:28, Petr Viktorin wrote: >> On 12/11/2013 05:05 PM, Petr Viktorin wrote: >>> On 12/10/2013 02:10 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> . >>>> >>>> Honza >>> >>> These look great, thanks! Just a couple of questions/nicpicks. >>> >>> 213: ACK >>> 214: ACK >>> 215: ACK >>> 216: ACK >>> 217: ACK >>> 218: ACK >>> >>> 219: >>> Does the new method guarantee 'attributetypes' are updated before >>> 'objectclasses'? >>> I can move the logic to schemaupdate if needed. > > That won't be necessary, fixed. > >>> >>> Why is OnlyOneValueAllowed not raised any more? It should be, since the >>> method assumes get_single_value() gives correct information. > > Fixed. > >>> >>> Why is MOD_REPLACE no longer used when no old values are retained? Or >>> (MOD_DELETE, a, None) when the new set is empty? > > Fixed. > > However, I am not convinced if this guessing is the right approach. I > think we can do better, by either not guessing: > > del entry[attr] -> delete attribute > entry[attr] = value -> replace attribute > entry[attr][index] = value -> delete old value, add new value > > or by guessing better, to minimize the size of the modify request. > >>> 220: ACK >>> >>> 221: >>> An ancient comment in ldapupdate still has a reference to orig_data in, >>> can you remove the comment as well? > > Sure. > >>> >>> 222: ACK >>> 223: ACK >>> 224: ACK >> >> I spoke too soon, NACK. This line: >> >> > -from ipaserver.plugins import ldap2 >> >> is important, please put it back. Without it api.Backend.ldap2 will not >> be available and upgrades will fail with AttributeError. >> >> (Yes, I know.) > > Fixed. (But it's retarded.) > >> >> >>> I noticed that IPASimpleLdapObject.convert_result's docstring is >>> obsolete, could you update/shorten it? > > Sure. > > Also fixed some more issues I noticed. It would be nice to write unit tests for issues as you notice them. > Updated patches attached. I now have a failing test in test_permission_rollback. Let's think about this case for a moment: The permission system has "rollback": if an ACI update fails, the entry is rolled back. Currently it works (for ipapermlocation changes) like this: - The old entry is retreived - A new entry is populated (NB, the framework's mod operation does not retrieve the entry it modifies; rather it builds an entirely new entry with *only* the data that's changed, and relies on generate_modlist doing MOD_REPLACE when orig data is missing). - update is called on the new entry - The ACI is updated, and this fails (e.g. with SyntaxError) - update is called on the *old* entry retreived in the first step. Up to now this had restored the entry (since existing state was looked up before each mod), but with these patches it raises EmptyModlist since the object has not changed relative to its orig data. Obviously this approach is wrong given how entry is supposed to work now, and I'll be happy to change it it. But it's not clear what's the right way to do such rollback. I'd like to discuss in person after the holidays, so we sync our expectations of how ipaldap should work. -- Petr? From pviktori at redhat.com Fri Dec 20 13:34:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 14:34:01 +0100 Subject: [Freeipa-devel] [PATCH] 231 Prevent garbage from readline on standard output of dogtag-ipa-retrieve-agent In-Reply-To: <52AEF659.8040502@redhat.com> References: <52AEF659.8040502@redhat.com> Message-ID: <52B44749.3010004@redhat.com> On 12/16/2013 01:47 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Looks good, thanks, ACK, pushed to master: 1357eade4c5086e6c837a49f3008616317f88e5f -- Petr? From simo at redhat.com Fri Dec 20 13:46:31 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Dec 2013 08:46:31 -0500 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <52B40C5E.4020308@redhat.com> References: <1387488285.19564.339.camel@willson.li.ssimo.org> <52B40C5E.4020308@redhat.com> Message-ID: <1387547191.19564.347.camel@willson.li.ssimo.org> On Fri, 2013-12-20 at 10:22 +0100, Petr Viktorin wrote: > On 12/19/2013 10:24 PM, Simo Sorce wrote: > > I have been looking at how we deal with krbpwdpolicypreference as we > > found issues with AD synced users, which get no password policy :/ > > > > I found out that we do not rely on CoS anymore for setting the attribute > > (origin of this bug I would guess), but instead explicitly set the > > policy on user objects. > > > > Why is that ? > > > > Also I still see in bootstrap-template.ldif that we create a Password > > Policy object in cn=accounts in theory, but I do not have this object on > > my server, what happens to it, what removes it ? Why ? > > I don't see it in any update file. Was your server installed before this > was added (2009-10-02)? Actually it is indeed possible, but then why there was no update file with the change ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 20 13:59:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 14:59:34 +0100 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <1387547191.19564.347.camel@willson.li.ssimo.org> References: <1387488285.19564.339.camel@willson.li.ssimo.org> <52B40C5E.4020308@redhat.com> <1387547191.19564.347.camel@willson.li.ssimo.org> Message-ID: <52B44D46.9090708@redhat.com> On 12/20/2013 02:46 PM, Simo Sorce wrote: > On Fri, 2013-12-20 at 10:22 +0100, Petr Viktorin wrote: >> On 12/19/2013 10:24 PM, Simo Sorce wrote: >>> I have been looking at how we deal with krbpwdpolicypreference as we >>> found issues with AD synced users, which get no password policy :/ >>> >>> I found out that we do not rely on CoS anymore for setting the attribute >>> (origin of this bug I would guess), but instead explicitly set the >>> policy on user objects. >>> >>> Why is that ? >>> >>> Also I still see in bootstrap-template.ldif that we create a Password >>> Policy object in cn=accounts in theory, but I do not have this object on >>> my server, what happens to it, what removes it ? Why ? >> >> I don't see it in any update file. Was your server installed before this >> was added (2009-10-02)? > > Actually it is indeed possible, but then why there was no update file > with the change ? Maybe Rob can tell us a reason. It was added in commit dac224c2. Most likely it's a bug, please file a ticket. -- Petr? From simo at redhat.com Fri Dec 20 14:07:38 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Dec 2013 09:07:38 -0500 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <52B44D46.9090708@redhat.com> References: <1387488285.19564.339.camel@willson.li.ssimo.org> <52B40C5E.4020308@redhat.com> <1387547191.19564.347.camel@willson.li.ssimo.org> <52B44D46.9090708@redhat.com> Message-ID: <1387548458.19564.353.camel@willson.li.ssimo.org> On Fri, 2013-12-20 at 14:59 +0100, Petr Viktorin wrote: > On 12/20/2013 02:46 PM, Simo Sorce wrote: > > On Fri, 2013-12-20 at 10:22 +0100, Petr Viktorin wrote: > >> On 12/19/2013 10:24 PM, Simo Sorce wrote: > >>> I have been looking at how we deal with krbpwdpolicypreference as we > >>> found issues with AD synced users, which get no password policy :/ > >>> > >>> I found out that we do not rely on CoS anymore for setting the attribute > >>> (origin of this bug I would guess), but instead explicitly set the > >>> policy on user objects. > >>> > >>> Why is that ? > >>> > >>> Also I still see in bootstrap-template.ldif that we create a Password > >>> Policy object in cn=accounts in theory, but I do not have this object on > >>> my server, what happens to it, what removes it ? Why ? > >> > >> I don't see it in any update file. Was your server installed before this > >> was added (2009-10-02)? > > > > Actually it is indeed possible, but then why there was no update file > > with the change ? > > Maybe Rob can tell us a reason. It was added in commit dac224c2. > Most likely it's a bug, please file a ticket. Ok, anyway this part was not interesting, I am more interested in why we explicitly add krbpwdpolicypreference to the user object and do not use CoS for the default ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 20 14:16:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 15:16:12 +0100 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <1387548458.19564.353.camel@willson.li.ssimo.org> References: <1387488285.19564.339.camel@willson.li.ssimo.org> <52B40C5E.4020308@redhat.com> <1387547191.19564.347.camel@willson.li.ssimo.org> <52B44D46.9090708@redhat.com> <1387548458.19564.353.camel@willson.li.ssimo.org> Message-ID: <52B4512C.3030600@redhat.com> On 12/20/2013 03:07 PM, Simo Sorce wrote: > On Fri, 2013-12-20 at 14:59 +0100, Petr Viktorin wrote: >> On 12/20/2013 02:46 PM, Simo Sorce wrote: >>> On Fri, 2013-12-20 at 10:22 +0100, Petr Viktorin wrote: >>>> On 12/19/2013 10:24 PM, Simo Sorce wrote: >>>>> I have been looking at how we deal with krbpwdpolicypreference as we >>>>> found issues with AD synced users, which get no password policy :/ >>>>> >>>>> I found out that we do not rely on CoS anymore for setting the attribute >>>>> (origin of this bug I would guess), but instead explicitly set the >>>>> policy on user objects. >>>>> >>>>> Why is that ? >>>>> >>>>> Also I still see in bootstrap-template.ldif that we create a Password >>>>> Policy object in cn=accounts in theory, but I do not have this object on >>>>> my server, what happens to it, what removes it ? Why ? >>>> >>>> I don't see it in any update file. Was your server installed before this >>>> was added (2009-10-02)? >>> >>> Actually it is indeed possible, but then why there was no update file >>> with the change ? >> >> Maybe Rob can tell us a reason. It was added in commit dac224c2. >> Most likely it's a bug, please file a ticket. > > Ok, anyway this part was not interesting, I am more interested in why we > explicitly add krbpwdpolicypreference to the user object and do not use > CoS for the default ? I found some discussion at https://fedorahosted.org/freeipa/ticket/51. For further questions I guess you'll need to wait for Rob. -- Petr? From simo at redhat.com Fri Dec 20 14:59:38 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Dec 2013 09:59:38 -0500 Subject: [Freeipa-devel] krbpwdpolicypreference issues In-Reply-To: <52B4512C.3030600@redhat.com> References: <1387488285.19564.339.camel@willson.li.ssimo.org> <52B40C5E.4020308@redhat.com> <1387547191.19564.347.camel@willson.li.ssimo.org> <52B44D46.9090708@redhat.com> <1387548458.19564.353.camel@willson.li.ssimo.org> <52B4512C.3030600@redhat.com> Message-ID: <1387551578.19564.354.camel@willson.li.ssimo.org> On Fri, 2013-12-20 at 15:16 +0100, Petr Viktorin wrote: > On 12/20/2013 03:07 PM, Simo Sorce wrote: > > On Fri, 2013-12-20 at 14:59 +0100, Petr Viktorin wrote: > >> On 12/20/2013 02:46 PM, Simo Sorce wrote: > >>> On Fri, 2013-12-20 at 10:22 +0100, Petr Viktorin wrote: > >>>> On 12/19/2013 10:24 PM, Simo Sorce wrote: > >>>>> I have been looking at how we deal with krbpwdpolicypreference as we > >>>>> found issues with AD synced users, which get no password policy :/ > >>>>> > >>>>> I found out that we do not rely on CoS anymore for setting the attribute > >>>>> (origin of this bug I would guess), but instead explicitly set the > >>>>> policy on user objects. > >>>>> > >>>>> Why is that ? > >>>>> > >>>>> Also I still see in bootstrap-template.ldif that we create a Password > >>>>> Policy object in cn=accounts in theory, but I do not have this object on > >>>>> my server, what happens to it, what removes it ? Why ? > >>>> > >>>> I don't see it in any update file. Was your server installed before this > >>>> was added (2009-10-02)? > >>> > >>> Actually it is indeed possible, but then why there was no update file > >>> with the change ? > >> > >> Maybe Rob can tell us a reason. It was added in commit dac224c2. > >> Most likely it's a bug, please file a ticket. > > > > Ok, anyway this part was not interesting, I am more interested in why we > > explicitly add krbpwdpolicypreference to the user object and do not use > > CoS for the default ? > > I found some discussion at https://fedorahosted.org/freeipa/ticket/51. > For further questions I guess you'll need to wait for Rob. Alexander found the commit, and had a pretty explanatory message. I opened a bug because the reason that prompted that change is actually no more. We'll discuss after the holidays break how to best address the whole issue. Thanks for digging up stuff :) Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Dec 20 15:01:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 16:01:47 +0100 Subject: [Freeipa-devel] [PATCH] chenxiaolong-001 Use /usr/bin/python2 Message-ID: <52B45BDB.8000803@redhat.com> On some platforms, "/usr/bin/python" is Python 3. We require Python 2 so we should explicitly use /usr/bin/python2. Xiao-Long, who owns FreeIPA in Arch Linux's AUR [0], wrote a patch for this issue. I've just updated the patch to current master (so any breakage this causes is my fault). https://fedorahosted.org/freeipa/ticket/3438 [0] https://aur.archlinux.org/packages/freeipa -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-chenxiaolong-0001-Use-usr-bin-python2.patch Type: text/x-patch Size: 25951 bytes Desc: not available URL: From pviktori at redhat.com Fri Dec 20 15:06:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Dec 2013 16:06:19 +0100 Subject: [Freeipa-devel] [PATCH 0135] Fix incorrect path in error message on sysrestore failure In-Reply-To: <52B31817.9040207@redhat.com> References: <52A9C211.6090600@redhat.com> <52AABBFA.7030903@redhat.com> <52B31817.9040207@redhat.com> Message-ID: <52B45CEB.8010306@redhat.com> On 12/19/2013 05:00 PM, Tomas Babej wrote: > Yes, > > this is planned as part of https://fedorahosted.org/freeipa/ticket/4052 Yeah, the path also appears in client-install and a dozen other files. Let's leave it to that ticket. > NACKs are welcome! It's a valid point, so I guess be fixing it now here > wouldn't hurt. > > Updated patch attached. > > Tomas Thanks for the patch! I could think of a less redundant name than SYSRESTORE_DIR_PATH, but that's an insignificant nitpick. ACK, pushed to master: 2a2f5ac4e68ed9a819ddc3de1d35366b2e2b58c7 > On 12/13/2013 08:49 AM, Petr Spacek wrote: >> On 12.12.2013 15:02, Tomas Babej wrote: >>> On sysrestore failure, user is prompted out to remove the sysrestore >>> file. However, the path to the sysrestore file mentioned in the >>> sentence is not correct. >>> >>> https://fedorahosted.org/freeipa/ticket/4080 >>> >>> -- >>> Tomas Babej >>> >>> >>> freeipa-tbabej-0135-Fix-incorrect-path-in-error-message-on-sysrestore-fa.patch >>> >>> >>> >>> From eac993e153c243b6359f57a7c051d3f373a9add0 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Thu, 12 Dec 2013 15:01:14 +0100 >>> Subject: [PATCH] Fix incorrect path in error message on sysrestore >>> failure >>> >>> On sysrestore failure, user is prompted out to remove the sysrestore >>> file. However, the path to the sysrestore file mentioned in the >>> sentence is not correct. >>> >>> https://fedorahosted.org/freeipa/ticket/4080 >>> --- >>> install/tools/ipa-server-install | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/install/tools/ipa-server-install >>> b/install/tools/ipa-server-install >>> index >>> 458ebba550d0fe7675bd874e23c7d730c53297e6..718fcee45550b9f65a17ecddc599fb4489f7ab3c >>> 100755 >>> --- a/install/tools/ipa-server-install >>> +++ b/install/tools/ipa-server-install >>> @@ -534,7 +534,10 @@ def uninstall(): >>> rv = 1 >>> >>> if has_state: >>> - root_logger.error('Some installation state has not been >>> restored.\nThis may cause re-installation to fail.\nIt should be safe >>> to remove /var/lib/ipa/sysrestore.state but it may\nmean your system >>> hasn\'t be restored to its pre-installation state.') >>> + root_logger.error('Some installation state has not been >>> restored.\n' >>> + 'This may cause re-installation to fail.\n' >>> + 'It should be safe to remove >>> /var/lib/ipa/sysrestore/sysrestore.state but it may\n' >> >> (I know that this is bold ...) NACK. >> >> A path used in the error message should be extracted/shared with the >> code. It will prevent inconsistencies like this in the future. >> >> Petr^2 Spacek >> >>> + 'mean your system hasn\'t be restored to >>> its pre-installation state.') >>> >>> # Note that this name will be wrong after the first uninstall. >>> dirname = >>> dsinstance.config_dirname(dsinstance.realm_to_serverid(api.env.realm)) >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr? From abokovoy at redhat.com Mon Dec 23 09:54:35 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Dec 2013 04:54:35 -0500 (EST) Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <52AB8E08.5000102@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> Message-ID: <923551694.401659.1387792475165.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Pal" > To: freeipa-devel at redhat.com > Sent: Saturday, December 14, 2013 12:45:28 AM > Subject: Re: [Freeipa-devel] FreeIPA OTP End-to-End > > On 12/13/2013 03:57 PM, Nathaniel McCallum wrote: > > This is an email to track the status of the OTP project as we push > > toward completion. I'm also attempting to get all the pieces in play so > > that they are testable. > > > > RPMs > > Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > > These currently contain the CLI and UI patches, but exclude the DS > > plugin patch. I will merge this last patch in when submitted to the > > list. > > > > OTP CLI > > All of the patches are merged except npmccallum-0024, which is > > undergoing active review. > > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html > > > > OTP UI > > Thanks to Petr Vobornik for his set of patches implementing the UI. They > > can be found rebased on top of my otp changes here: > > https://github.com/npmccallum/freeipa/commits/otpui > > > > Authentication methods and RADIUS proxy support seems to be fully > > functional and I have not encountered any bugs. I'm not currently able > > to get the OTP UI to show up at all (I may well be doing something > > wrong). > > > > I believe Petr plans to clean these up and resubmit them to the list. > > > > One additional patch will be required for the token sync extop. > > > > DS PLUGIN > > I am nearing completion on the DS plugin providing support for deletion > > protection and the token sync extop. This should hit the list next week. > > > > OTHER > > Am I missing anything? > > Did you update the wiki page? I think it was one of the outstanding items. > Any unit tests? > Any way to include some testes for Continues Integration? > Anything SELinux related? > Default configuration of locations and names of sockets and files? > Things like that. I've fixed Web UI and have it working now. Patch attached. Additionally, there are two AVCs that need to be fixed on Fedora 20: type=AVC msg=audit(1387751773.915:1221): avc: denied { write } for pid=3 361 comm="krb5kdc" name="DEFAULT.socket" dev="dm-0" ino=276499 scontext=sys tem_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tc lass=sock_file type=AVC msg=audit(1387751773.915:1221): avc: denied { connectto } for p id=3361 comm="krb5kdc" path="/var/kerberos/krb5kdc/DEFAULT.socket" scontext =system_u:system_r:krb5kdc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass =unix_stream_socket they are fixed with following rules: allow krb5kdc_t init_t:unix_stream_socket connectto; allow krb5kdc_t krb5kdc_conf_t:sock_file write; We need to fix documentation now that the comand set is called otptoken-*, also help messages in ipalib/plugins/otptoken.py need update. When both password and otp are enabled for the user, only a password authentication is working. What does not yet work is end-to-end kinit without armoured ccache. This also is the case for PAM-based logins through SSSD. Armoured ccache works: [root at master ~]# kinit -k [root at master ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_vTaHGz9 Default principal: host/master.ipa.test at IPA.TEST Valid starting Expires Service principal 12/23/2013 11:40:02 12/24/2013 11:40:02 krbtgt/IPA.TEST at IPA.TEST [root at master ~]# kinit -T KEYRING:persistent:0:krb_ccache_vTaHGz9 ab at IPA.TEST Enter OTP Token Value: [root at master ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: ab at IPA.TEST Valid starting Expires Service principal 12/23/2013 11:40:59 12/24/2013 11:40:45 krbtgt/IPA.TEST at IPA.TEST What I would like to see is either automated armouring or use of fully anonymous principal for armouring. We have PKI anchors set by default for all FreeIPA clients already, so making possible to obtain a ticket as a WELLKNOWN/ANONYMOUS at REALM principal purely for armouring would be great. Additionally, FreeOTP QR-code capture seems to treat Galaxy S4 mini's camera wrongly, I see the viewfinder mirrored -- up is down and left is right. This makes almost impossible to focus on the QR code in web UI. -- / Alexander Bokovoy -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-OTP-UI-use-otptoken-handle-since-the-IPA-commands-ar.patch Type: text/x-patch Size: 2988 bytes Desc: not available URL: From simo at redhat.com Mon Dec 23 15:11:27 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Dec 2013 10:11:27 -0500 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <923551694.401659.1387792475165.JavaMail.root@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> <923551694.401659.1387792475165.JavaMail.root@redhat.com> Message-ID: <1387811487.19564.386.camel@willson.li.ssimo.org> On Mon, 2013-12-23 at 04:54 -0500, Alexander Bokovoy wrote: > > ----- Original Message ----- > > From: "Dmitri Pal" > > To: freeipa-devel at redhat.com > > Sent: Saturday, December 14, 2013 12:45:28 AM > > Subject: Re: [Freeipa-devel] FreeIPA OTP End-to-End > > > > On 12/13/2013 03:57 PM, Nathaniel McCallum wrote: > > > This is an email to track the status of the OTP project as we push > > > toward completion. I'm also attempting to get all the pieces in play so > > > that they are testable. > > > > > > RPMs > > > Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > > > These currently contain the CLI and UI patches, but exclude the DS > > > plugin patch. I will merge this last patch in when submitted to the > > > list. > > > > > > OTP CLI > > > All of the patches are merged except npmccallum-0024, which is > > > undergoing active review. > > > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html > > > > > > OTP UI > > > Thanks to Petr Vobornik for his set of patches implementing the UI. They > > > can be found rebased on top of my otp changes here: > > > https://github.com/npmccallum/freeipa/commits/otpui > > > > > > Authentication methods and RADIUS proxy support seems to be fully > > > functional and I have not encountered any bugs. I'm not currently able > > > to get the OTP UI to show up at all (I may well be doing something > > > wrong). > > > > > > I believe Petr plans to clean these up and resubmit them to the list. > > > > > > One additional patch will be required for the token sync extop. > > > > > > DS PLUGIN > > > I am nearing completion on the DS plugin providing support for deletion > > > protection and the token sync extop. This should hit the list next week. > > > > > > OTHER > > > Am I missing anything? > > > > Did you update the wiki page? I think it was one of the outstanding items. > > Any unit tests? > > Any way to include some testes for Continues Integration? > > Anything SELinux related? > > Default configuration of locations and names of sockets and files? > > Things like that. > I've fixed Web UI and have it working now. Patch attached. > > Additionally, there are two AVCs that need to be fixed on Fedora 20: > > type=AVC msg=audit(1387751773.915:1221): avc: denied { write } for pid=3 > 361 comm="krb5kdc" name="DEFAULT.socket" dev="dm-0" ino=276499 scontext=sys > tem_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tc > lass=sock_file > type=AVC msg=audit(1387751773.915:1221): avc: denied { connectto } for p > id=3361 comm="krb5kdc" path="/var/kerberos/krb5kdc/DEFAULT.socket" scontext > =system_u:system_r:krb5kdc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass > =unix_stream_socket > > they are fixed with following rules: > > allow krb5kdc_t init_t:unix_stream_socket connectto; Shouuldn't systemd assign a different label to the socket instead ? > allow krb5kdc_t krb5kdc_conf_t:sock_file write; Is krb5kdc_conf_t actually the right label ? Doesn't look like. > We need to fix documentation now that the comand set is called otptoken-*, > also help messages in ipalib/plugins/otptoken.py need update. > > When both password and otp are enabled for the user, only a password authentication is working. > > What does not yet work is end-to-end kinit without armoured ccache. Isn't this by design ? We can only trust OTP to send clear text credentials if you can use FAST and encrypt the channel. > This also is the case for PAM-based logins through SSSD. Do you have FAST enabled in SSSD ? > Armoured ccache works: > [root at master ~]# kinit -k > [root at master ~]# klist > Ticket cache: KEYRING:persistent:0:krb_ccache_vTaHGz9 > Default principal: host/master.ipa.test at IPA.TEST > > Valid starting Expires Service principal > 12/23/2013 11:40:02 12/24/2013 11:40:02 krbtgt/IPA.TEST at IPA.TEST > [root at master ~]# kinit -T KEYRING:persistent:0:krb_ccache_vTaHGz9 ab at IPA.TEST > Enter OTP Token Value: > [root at master ~]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: ab at IPA.TEST > > Valid starting Expires Service principal > 12/23/2013 11:40:59 12/24/2013 11:40:45 krbtgt/IPA.TEST at IPA.TEST > > What I would like to see is either automated armouring or use of fully anonymous principal for armouring. Automated canont be done if you are a regular user unless PKINIT is configured on the KDC. Unfortunately although I did 90% of the work to enable pkinit by default years ago, we never merged it in because we cannot yet generate the required profile to release the certificate to the KDC. > We have PKI anchors set by default for all FreeIPA clients already, so making possible to obtain a ticket > as a WELLKNOWN/ANONYMOUS at REALM principal purely for armouring would be great. > > Additionally, FreeOTP QR-code capture seems to treat Galaxy S4 mini's camera wrongly, > I see the viewfinder mirrored -- up is down and left is right. This makes almost impossible > to focus on the QR code in web UI. Time to open a bug on https://fedorahosted.org/freeotp :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Dec 23 16:07:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Dec 2013 11:07:27 -0500 (EST) Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <1387811487.19564.386.camel@willson.li.ssimo.org> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> <923551694.401659.1387792475165.JavaMail.root@redhat.com> <1387811487.19564.386.camel@willson.li.ssimo.org> Message-ID: <1086834488.587593.1387814847524.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Simo Sorce" > To: "Alexander Bokovoy" > Cc: dpal at redhat.com, freeipa-devel at redhat.com > Sent: Monday, December 23, 2013 5:11:27 PM > Subject: Re: [Freeipa-devel] FreeIPA OTP End-to-End > > On Mon, 2013-12-23 at 04:54 -0500, Alexander Bokovoy wrote: > > > > ----- Original Message ----- > > > From: "Dmitri Pal" > > > To: freeipa-devel at redhat.com > > > Sent: Saturday, December 14, 2013 12:45:28 AM > > > Subject: Re: [Freeipa-devel] FreeIPA OTP End-to-End > > > > > > On 12/13/2013 03:57 PM, Nathaniel McCallum wrote: > > > > This is an email to track the status of the OTP project as we push > > > > toward completion. I'm also attempting to get all the pieces in play so > > > > that they are testable. > > > > > > > > RPMs > > > > Available here: http://npmccallum.fedorapeople.org/freeipa-otp/rpms/ > > > > These currently contain the CLI and UI patches, but exclude the DS > > > > plugin patch. I will merge this last patch in when submitted to the > > > > list. > > > > > > > > OTP CLI > > > > All of the patches are merged except npmccallum-0024, which is > > > > undergoing active review. > > > > https://www.redhat.com/archives/freeipa-devel/2013-December/msg00102.html > > > > > > > > OTP UI > > > > Thanks to Petr Vobornik for his set of patches implementing the UI. > > > > They > > > > can be found rebased on top of my otp changes here: > > > > https://github.com/npmccallum/freeipa/commits/otpui > > > > > > > > Authentication methods and RADIUS proxy support seems to be fully > > > > functional and I have not encountered any bugs. I'm not currently able > > > > to get the OTP UI to show up at all (I may well be doing something > > > > wrong). > > > > > > > > I believe Petr plans to clean these up and resubmit them to the list. > > > > > > > > One additional patch will be required for the token sync extop. > > > > > > > > DS PLUGIN > > > > I am nearing completion on the DS plugin providing support for deletion > > > > protection and the token sync extop. This should hit the list next > > > > week. > > > > > > > > OTHER > > > > Am I missing anything? > > > > > > Did you update the wiki page? I think it was one of the outstanding > > > items. > > > Any unit tests? > > > Any way to include some testes for Continues Integration? > > > Anything SELinux related? > > > Default configuration of locations and names of sockets and files? > > > Things like that. > > I've fixed Web UI and have it working now. Patch attached. > > > > Additionally, there are two AVCs that need to be fixed on Fedora 20: > > > > type=AVC msg=audit(1387751773.915:1221): avc: denied { write } for pid=3 > > 361 comm="krb5kdc" name="DEFAULT.socket" dev="dm-0" ino=276499 scontext=sys > > tem_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tc > > lass=sock_file > > type=AVC msg=audit(1387751773.915:1221): avc: denied { connectto } for p > > id=3361 comm="krb5kdc" path="/var/kerberos/krb5kdc/DEFAULT.socket" scontext > > =system_u:system_r:krb5kdc_t:s0 tcontext=system_u:system_r:init_t:s0 tclass > > =unix_stream_socket > > > > they are fixed with following rules: > > > > allow krb5kdc_t init_t:unix_stream_socket connectto; > > Shouuldn't systemd assign a different label to the socket instead ? We didn't assign specific label, we have bug https://bugzilla.redhat.com/show_bug.cgi?id=970169 for that but it is still under development by SELinux team. > Is krb5kdc_conf_t actually the right label ? Doesn't look like. > > > We need to fix documentation now that the comand set is called otptoken-*, > > also help messages in ipalib/plugins/otptoken.py need update. > > > > When both password and otp are enabled for the user, only a password > > authentication is working. > > > > What does not yet work is end-to-end kinit without armoured ccache. > > Isn't this by design ? We can only trust OTP to send clear text > credentials if you can use FAST and encrypt the channel. What I mean is that we should make the client to use FAST automatically by itself when PKI anchors are set and KDC answers with request for pre-auth. Sure, we need to fix our part too, ticket https://fedorahosted.org/freeipa/ticket/521, but right now we don't have any choice for users who switched to 2FA -- they have no method to create armoured ccache at all. > > This also is the case for PAM-based logins through SSSD. > > Do you have FAST enabled in SSSD ? Yes, and it is broken: https://fedorahosted.org/sssd/ticket/2186 > > Armoured ccache works: > > [root at master ~]# kinit -k > > [root at master ~]# klist > > Ticket cache: KEYRING:persistent:0:krb_ccache_vTaHGz9 > > Default principal: host/master.ipa.test at IPA.TEST > > > > Valid starting Expires Service principal > > 12/23/2013 11:40:02 12/24/2013 11:40:02 krbtgt/IPA.TEST at IPA.TEST > > [root at master ~]# kinit -T KEYRING:persistent:0:krb_ccache_vTaHGz9 > > ab at IPA.TEST > > Enter OTP Token Value: > > [root at master ~]# klist > > Ticket cache: KEYRING:persistent:0:0 > > Default principal: ab at IPA.TEST > > > > Valid starting Expires Service principal > > 12/23/2013 11:40:59 12/24/2013 11:40:45 krbtgt/IPA.TEST at IPA.TEST > > > > What I would like to see is either automated armouring or use of fully > > anonymous principal for armouring. > > Automated canont be done if you are a regular user unless PKINIT is > configured on the KDC. Unfortunately although I did 90% of the work to > enable pkinit by default years ago, we never merged it in because we > cannot yet generate the required profile to release the certificate to > the KDC. I'd say making it complete is a prerequisite for real use of our OTP. > > Additionally, FreeOTP QR-code capture seems to treat Galaxy S4 mini's > > camera wrongly, > > I see the viewfinder mirrored -- up is down and left is right. This makes > > almost impossible > > to focus on the QR code in web UI. > > Time to open a bug on https://fedorahosted.org/freeotp :-) Done. -- / Alexander Bokovoy From simo at redhat.com Mon Dec 23 16:30:00 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Dec 2013 11:30:00 -0500 Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <1086834488.587593.1387814847524.JavaMail.root@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> <923551694.401659.1387792475165.JavaMail.root@redhat.com> <1387811487.19564.386.camel@willson.li.ssimo.org> <1086834488.587593.1387814847524.JavaMail.root@redhat.com> Message-ID: <1387816200.19564.387.camel@willson.li.ssimo.org> On Mon, 2013-12-23 at 11:07 -0500, Alexander Bokovoy wrote: > > > > > What I would like to see is either automated armouring or use of fully > > > anonymous principal for armouring. > > > > Automated canont be done if you are a regular user unless PKINIT is > > configured on the KDC. Unfortunately although I did 90% of the work to > > enable pkinit by default years ago, we never merged it in because we > > cannot yet generate the required profile to release the certificate to > > the KDC. > I'd say making it complete is a prerequisite for real use of our OTP. I agree. Simo. > > > Additionally, FreeOTP QR-code capture seems to treat Galaxy S4 mini's > > > camera wrongly, > > > I see the viewfinder mirrored -- up is down and left is right. This makes > > > almost impossible > > > to focus on the QR code in web UI. > > > > Time to open a bug on https://fedorahosted.org/freeotp :-) > Done. TY. simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Mon Dec 23 17:53:08 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Dec 2013 12:53:08 -0500 Subject: [Freeipa-devel] [PATCH 0026] Enable building in C99 mode In-Reply-To: <52B059CB.5080108@redhat.com> References: <1387228349.1948.83.camel@localhost.localdomain> <52AFFAED.50105@redhat.com> <1387287487.1948.86.camel@localhost.localdomain> <52B059CB.5080108@redhat.com> Message-ID: <1387821188.18952.4.camel@localhost.localdomain> On Tue, 2013-12-17 at 15:03 +0100, Jan Cholasta wrote: > On 17.12.2013 14:38, Nathaniel McCallum wrote: > > On Tue, 2013-12-17 at 08:19 +0100, Jan Cholasta wrote: > >> Hi, > >> > >> On 16.12.2013 22:12, Nathaniel McCallum wrote: > >>> Patch attached. > >> > >> Care to elaborate? There's no ticket or explanation why this is > >> beneficial or necessary. > > > > It enables compiling with C99 features, which I personally find very > > beneficial. I am using these features (incomplete initializers and > > for-loop declarations) in my DS plugin code. It is 2014 after all, and > > most recent compilers support C11 at this point (certainly all the ones > > we care to support)... > > > > Nathaniel > > > > Can you put something like this explanation in the commit message please? Attached. However, I had to disable -Werror. This breaks the standard C99 autoconf test (AC_PROG_CC_C99). We probably shouldn't be distributing releases with -Werror. But at the least, we definitely shouldn't be running autoconf with it. The typical way to do this in autotools land is to add it in the Makefile only after autoconf runs and only if you are not building the release (make dist). Suggestions? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0026-2-Enable-building-in-C99-mode.patch Type: text/x-patch Size: 2007 bytes Desc: not available URL: From npmccallum at redhat.com Mon Dec 23 17:54:31 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Dec 2013 12:54:31 -0500 Subject: [Freeipa-devel] [PATCH 0027] Add config.h.in~ and rpmbuild to git ignore Message-ID: <1387821271.18952.5.camel@localhost.localdomain> Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0027-Add-config.h.in-and-rpmbuild-to-git-ignore.patch Type: text/x-patch Size: 647 bytes Desc: not available URL: From npmccallum at redhat.com Mon Dec 23 17:56:35 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Dec 2013 12:56:35 -0500 Subject: [Freeipa-devel] [PATCH 0027] Add OTP last token plugin Message-ID: <1387821395.18952.7.camel@localhost.localdomain> This plugin prevents the deletion or deactivation of the last valid token for a user. This prevents the user from migrating back to single factor authentication once OTP has been enabled. Thanks to Mark Reynolds for helping me with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0028-Add-OTP-last-token-plugin.patch Type: text/x-patch Size: 40830 bytes Desc: not available URL: From abokovoy at redhat.com Tue Dec 24 11:55:48 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Dec 2013 06:55:48 -0500 (EST) Subject: [Freeipa-devel] FreeIPA OTP End-to-End In-Reply-To: <923551694.401659.1387792475165.JavaMail.root@redhat.com> References: <1386968251.1948.25.camel@localhost.localdomain> <52AB8E08.5000102@redhat.com> <923551694.401659.1387792475165.JavaMail.root@redhat.com> Message-ID: <263989647.790938.1387886148274.JavaMail.root@redhat.com> Alexander Bokovoy wrote: > What does not yet work is end-to-end kinit without armoured ccache. > This also is the case for PAM-based logins through SSSD. This one is fixed now. There was a bug in SSSD's processing of a response from a krb5_child process in case FAST is activated -- SSS_OTP message was the last one returned and SSSD erroneously thought it is a malformed packet. I now have 2FA logons working with PAM-based apps (including SSH) using following configuration in sssd.conf: ---------------------------------- [domain/`domain`] .... krb5_use_fast = try krb5_fast_principal = host/`hostname` .... ---------------------------------- Patch for https://fedorahosted.org/sssd/ticket/2186 is on the SSSD development list. -- / Alexander Bokovoy